Genetic Algorithms as a Recovering Traceability Links Method between Feature Models and Source Code of Product Variants
Journée Lignes de Produits, 2012
Hamzeh Eyal-Salman, Abdelhak-Djamel Seriai, Christophe Dony and Ra’fat Al-msie’deen
November, 2012
What is product variants?
Migration from product variants to software product line Traceability in software engineering
− Traceability in traditional software engineering
− Traceability in software product line engineering
Our approach
Experimental results and evaluation Conclusions
Future perspectives References
Outlines
Software product variants are a set of similar products that are developed by copy-paste-modify technique not by software product line (SPL) strategy.
− For example: when companies have to release a new product that is similar, yet not identical, to existing ones.
Software product variants represent a starting point to build software product line (SPL) [4].
Software Product Variants
When number of product variants and features grow many problems will appear such as :
We must maintain each product variant separately.
It becomes difficult to adapt and trace features for reuse in new products.
Software comprehension and impact analysis will be more complicated.
Software Product Variants [Cont.]
Reengineering software product variants into (SPL) represents an ideal solution for previous problems.
− Analyzing existing product variants to migrate them into product variants.
SPL is “a set of software-intensive systems sharing a common, managed set of features that satisfies 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” [11].
Software Product Variants Migration
There are three issues that must be considered to reengineering product variants into SPL [1]:
− How to extract Feature Model (FM) of software product variants.
− How to build SPL core assets (Domain engineering artefacts).
− How to establish traceability links between SPL artefacts (for systematic reuse).
Software Product Variants Migration [Cont.]
Feature models are tree-like graph of features and relationships among them.
FMs in SPLE are used to represent commonality and variability of SPL members at different levels of abstraction [1].
FMs represent a set of configurations where each configuration represents particular product.
Feature Model Extraction [Cont.]
In our work we will assume that FM of product variants can be provided by:
− System’s developers and domain experts who accompanied and contributed product variants evolution.
− Software products variants description and documentation [2].
Feature Model Extraction [Cont.]
SPL core assets are a collection of all reusable artefacts that must be reused in systematic way (
requirement artefacts, design artefacts, realization artefacts, testing artefacts and so on)[1].
Software product variants provide many resources that can be used to build SPL core assets: requirements, design models, source code and test cases.
Product variants resources must be connected for systematic reuse.
− Traceability links between product variants resources must be identified.
Building SPL Core Assets
Traceability is the ability to describe and follow the life cycle of an artifact (requirements, source code, test cases, etc.) in both forward and backward directions [7].
Traceability relations can refer to [7]:
− Overlap relation.
− Dependency relation.
− Evolution relation.
− Generalization/refinement relation.
Dimensions of traceability [7]
− Traditional software engineering has two dimensions of traceability:
1. Vertical:
relationships among artefacts at the same level of abstraction (e.g.
between related requirements).
2. Horizontal:
relationships among artefacts at different levels of abstraction (e.g.
from requirements to design to implementation).
Traceability in Traditional Software engineering
SPLE introduces a third dimension of traceability to deal with variability and commonality [7].
Traceability links in SPLE are required to relate variation points and variants with all corresponding low level artefacts (requirements, design, source code and test cases artefacts) [7].
Traceability in SPLE [Cont.]
Messages (VP)
SMS (V1) MMS (V2)
Requirements Design Implementation Test cases
? ? ?
?
In SPLE there are three types of traceability links [1]:
1. Traceability links between domain engineering artefacts.
2. Traceability links between application engineering artefacts.
3. Traceability links between domain and application engineering artefacts
Traceability in SPLE [Cont.]
SPLE Framework [1]
Traceability links between domain engineering artefacts[1].
− Ensure the consistent definition of the commonality and the variability of the software product line throughout all domain artefacts.
− Facilitate systematic and consistent reuse.
Traceability links among application engineering artefacts are needed to [1]:
− Ensure the correct binding of variability throughout all application artefacts.
Traceability links between domain and application engineering artefacts are needed to [1]:
− Facilitate products derivation process.
− Support the evolution of the product line. For example, if a domain artefact is changed, the application artefacts affected by this change can be easily determined.
Traceability in SPLE [Cont.]
Traceability difficulties in SPLE
Variability is scattered over all SPL core assets artefacts.
There is a large number of SPL core assets artefacts.
SPL core assets are composed of various kinds and different structure of artefacts.
Traceability in SPLE [Cont.]
The relationship between the features and their corresponding implementation is rarely documented.
Our work aims to Identify traceability links between products features and artefacts that realize those features.
Traceability Links between FM and Source Code of Product Variants(1/6)
Recovering traceability links between FM and O.O.Source code of software product variants aims to:
Automate products derivation process such that source code artefact can be automatically configured for a product according to the features selection from the feature model.
Refactoring the code into product line representation that facilitate reuse.
Traceability links can be exploited to detect dependncy between features.
The identified traceability links represent a starting point to trace commonality varaibility in another level of abstraction like architecture.
Facilitate program comprehension.
Make the process of maintenance and evolution of a system less dependent on individual experts.
Traceability Links between FM and Source Code of Product Variants(2/6)
There are several ways to implement features we assume that functional features are implemented at the programming language level [12].
Mandatory features are realized by object-oriented building elements (OOBE) (i.e. packages, classes, methods and so on) that are shared by all product variants.
Optional features are realized by variable elements that appear only in some variants.
In an object oriented source code, there are four levels of variation: Package variation, class variation, method variation and attribute variation.
Traceability links between FM and Source code of product variants (3/6)
Traceability links between FM and Source code of product variants(4/6)
Source Code Variations
Traceability links between FM and Source code of product variants(5/6)
Feature to source code elements mapping model
The main building unit of any object oriented language is class.
In our work we considered variation at package level where features are implemented as a set of classes.
Traceability links between FM and Source code of product variants(6/6)
The inputs of our approach consist of the following elements:
Feature model
: FM provides useful information that can be used as constraints.− mandatory features.
− XOR-Group of features
− OR-Group of features.
− Cross tree constrains (require and exclude)
Products configuration:
refers to mandatory and optional features that are included in some product.O.O.Source code of software product variants.
Our approach for recovering traceability links
Our approach to recovery traceability links consists of two phases:
Phase 1: identifying common and variable classes in all product variants
− Source code of product variants is analyzed by Eclipse’s JDT Java parser to extract all classes.
− Common classes and variable classes are extracted by conducting a lexical matching between extracted classes.
− We assumed that the product variants use the same vocabularies to name packages, classes and so on.
Our approach for recovering traceability links [Cont.]
Phase 2: Applying genetic algorithms (GAs) as a recovering traceability links method.
Our approach for recovering traceability links [Cont.]
To apply GAs we must consider two issues:
1. Modelling our solution as a chromosome
− In our case chromosome is a partition as shown.
− Partition is a set of clusters.
− Each cluster is composed of a set of classes that correspond to some feature.
− Any cluster represents a gene (in GAs terminology)
− Number of clusters in each partition refers to number of all product variants features.
− Union of all clusters gives all software product variants classes.
Our approach for recovering traceability links [Cont.]
[1,5,7] [2,4] [6,8,3] [11] [10,11] [13,14,10] [12,15] [17]
Chromosome or Partition
F2
F1 F3 F4 F5 F6 F7 F8
Gene or Cluster Mandatory Features
1. Modelling our solution as a chromosome (Cont.)
− Common and variable classes are indexed with integer numbers starting from 1.
− Gene’s contents are selected randomly from these integer values.
− Features are arranged in the fixed order where mandatory features are located in the front of the partition while variable features are located in the back.
− In the initial population mandatory features are be mapped to the common classes
Our approach for recovering traceability links [Cont.]
[1,5,7] [2,4] [6,8,3] [11] [10,11] [13,14,10] [12,15] [17]
Chromosome or Partition
F2
F1 F3 F4 F5 F6 F7 F8
Gene or Cluster Mandatory Features
2. Building a fitness function that exploits all available information provided by the FM and products configuration to guide GAs to the best solution
− All features are atomic (AF): Any partition containing a cluster of classes that partially are included in some product will be rejected.
− Number of features and classes must be satisfied for all products (NFC): Any partition doesn’t cover all classes and features in each product will be rejected.
− Two different features have different implementations (FI).
− Each product must have all mandatory primitives features (MF).
− Each product must have just one member of XOR- group (XOR).
− Each product must have at least one member of OR-group (OR).
− Exclude constraint must be satisfied (EX).
− Require constraint must be satisfied (RE).
Our approach for recovering traceability links [Cont.]
F=AF+NFC+FI+MF+XOR+OR+EX+RE
The fitness value of the worst partition equals zero (a partition doesn’t meet all the above constraints).
The fitness value of the best partition equals eight (a partition meets all above constraints).
Our approach for recovering traceability links [Cont.]
Recovering Traceability Links Process [Cont.]
Our Approach Overview.
To validate our approach we considered a FM of a mobile phone product line.
Feature model of a mobile phone product line.
Experimental Results and Evaluation [Cont.]
Three configurations were selected to realize three products.
These configurations consist of (8) features and realized by (11) classes
Experimental Results and Evaluation [Cont.]
Products Configuration.
We will assume that each feature is implemented with certain classes as shown in the table below.
Experimental Results and Evaluation [Cont.]
Real Implementation
# Features Implemented by
1 Calls VoiceVedioCalls, call
2 MMS MMSService
3 SMS SMSService, SMSService
4 Basic Basic
5 HighResolution HighResolution
6 GPS GPSService
7 Camera Camera, MediaCamera
8 MP3 MediaMP3
Table in the bottom represents all possible obtained classes for each feature by applying GAs as a recovering traceability links method.
According to this table
− mandatory features are mapped to all common classes.
− Real implementation for each optional feature is a subset of obtained classes
Experimental Results and Evaluation [Cont.]
Features Obtained Classes
Calls
MMSService, SMSService, VoiceVedioCalls, Call, SMSService
MMS SMS
Basic MediaMP3, Basic
HighResolution HighResolution, Camera, MediaCamera
GPS GPSService
Camera HighResolution, Camera, MediaCamera
MP3 MediaMP3, Basic
GAs results
GAs gives one partition or solution for each run (execution) so number of runs that must be executed to find all possible classes for each feature is unknown.
In our case, we executed the GAs (6 times) with best fitness value zero in each time because we have the real implementation for each feature.
When number of features and classes grows, number of possible
implementations for each variable feature grows exponentially and search space for common features will become very large.
Experimental Results and Evaluation [Cont.]
GAs can determine approximately in small scale products the implementation of each feature.
GAs are not scalable as a recovering traceability links method in large scale products.
GAs generate just one solution for each run so number of runs that must be executed to determine all possible classes for each feature is unknown.
Conclusions
1. We will use GAs with all information provided by FM as a complementary part with other method.
2. We will consider other variation points in object oriented source code.
Future Perspectives
1. Pohl,K., Böckle, G. and Linden, F. 2005. Software Product Line Engineering:
Foundations, Principles and Techniques. Springer-Verlag New York, Inc., Secaucus, NJ, USA.
2. Acher, M., Cleve, A., Perrouin, G., Heymans, P., Vanbeneden, C., Collet, P. and Lahire, P. 2012. On extracting feature models from product descriptions. InProceedings of the Sixth International Workshop on Variability Modeling of Software-Intensive Systems (VaMoS '12). ACM, New York, NY, USA, 45-54.
3. Marcus, A. and Maletic, J. 2003. Recovering documentation-to-source-code traceability links using latent semantic indexing. In Proceedings of the 25th International Conference on Software Engineering (ICSE '03). IEEE Computer Society, Washington, DC, USA, 125-135.
4. Figueiredo, E., Cacho, N., Sant'Anna, C., Monteiro, M., Kulesza, U., Garcia, A., Soares, S., Ferrari, F., Khan, S., Filho, F. and Dantas, F. 2008. Evolving software product lines with aspects: an empirical study on design stability. In Proceedings of the 30th international conference on Software engineering (ICSE '08). ACM, New York, NY, USA, 261-270.
5. Benavides, D., Segura, S. and Ruiz-Cort, A. 2010. Automated analysis of feature models 20 years later: A literature review. Inf. Syst. 35, 6 (September 2010), 615-636.
6. Spanoudakis, G. and Zisman, A., Software Traceability: A Roadmap, in Handbook of Software Engineering and Knowledge Engineering, Chang, S. K., Ed. World Scientific Publishing Co, 2005, pp. 395-428.
References
7. Nicolas Anquetil, Kulesza, Ralf Mitschke, Ana Moreira, Jean-Claude Royer, Andreas Rummler, and Andr\&\#233; Sousa. 2010. A model-driven traceability framework for software product lines. Softw. Syst. Model. 9, 4 (September 2010), 427-451.
8. Kang, K., Kim, S., Lee, J., Kim, K., Shin, E., and Huh, M. (1998). FORM: a feature oriented reuse method with domain-specific reference architectures. Annals of Software Engineering, 5(1):143–168.
9. Binkley, D. and Lawrie, D. 2010. Information Retrieval Applications in Software Maintenance and Evolution. In Encyclopedia of Software Engineering (P. Laplante, ed.), Taylor & Francis LLC. 454-463.
10. Marcus, A. and Maletic, J. 2003. Recovering documentation-to-source-code traceability links using latent semantic indexing. In Proceedings of the 25th International Conference on Software Engineering (ICSE '03). IEEE Computer Society, Washington, DC, USA, 125-135.
11. Clements, P. and Northrop, L. 2001. Software product lines: practices patterns. Addison- Wesley Longman Publishing Co., Boston, MA, USA.
12. Beuche, D., Papajewski, H. Wolfgang and Preikschat, S. 2004. Variability management with feature models. Sci. Comput. Program. 53(3): 333-352.
