An Approach to Recover Feature Models From Object-Oriented Source Code

1. AN APPROACH TO RECOVER FEATURE MODELS FROM
OBJECT-ORIENTED SOURCE CODE
R. AL- Msie’deen, A. Djamel Seriai, M. Huchard, C. Urtado, S.
Vauttier, and H. S. Eyal Salman

2. Outlines:
 INTRODUCTION.
 SOFTWARE PRODUCT LINE ENGINEERING (SPLE).
 FEATURE AND FEATURE MODEL (FM).
 FORMAL CONCEPT ANALYSIS (FCA).
 INFORMATION RETRIEVAL (IR) & LATENT SEMANTIC INDEXING (LSI).
 MOTIVATIONS.
 APPROACH OVERVIEW => THE MAPPING MODEL + FEATURE EXTRACTION PROCESS.
 OBJECT-ORIENTED SOURCE CODE VARIATIONS.
 OBJECT-ORIENTED BUILDING ELEMENTS (OBE).
 COMMONALITY AND VARIATION IDENTIICATION USING FCA.
 ATOMIC BLOCK OF VARIATIONS (FEATURE) IDENTIFICATION USING LSI AND FCA.
 RELATED WORK.
 CONCLUSION.
 FUTURE WORK.
 REFERENCES.
2

3. Introduction:
Software product variants are a set of similar products that are developed by
copy-paste-modify technique not by software product line (SPL) strategy.
Copy - paste - modify
Software product variants represent a starting point to build software product line
(SPL) [FIG 08]
3

4. Software Product Line [SPL]:
A SPL 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 are developed from a
common set of core assets in a prescribed way" [CLE 01]
Products Features
Domain
Core Assets Production Plan
4

5. Software Product Line Engineering [SPLE]:
SPLE consists in two major steps: [CLE 01]
1. Domain Engineering: Core Assets + Feature Model.
2. Application Engineering: Product Configurations.
5

6. Feature and Feature Model:
The Feature is a system property relevant to some stakeholder used to capture commonalities or
discriminate [variations] among systems in a family [CZA 00]
Feature models FMs 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 [POH 10]
Feature
Feature Models
Optional Feature Mandatory Feature
6

7. Feature and Feature Model:
Text editing system 1 FM
Text Editing System
File Management
Basic
Help
Edit
Basic Edit Select All
Resize Case conversion
Clear
Read Only Font ColorSearch Split
Require
ExcludeAND
OR
XOROptional Feature
Mandatory Feature
Legend
Change Display Settings
Replacement
Unsplit AllHorizontal Vertical
require
exclude
1 http://www.lirmm.fr/TextEditingSystemSPL 7

8. Formal Concept Analysis (FCA):
FCA is a mathematical method that provides a way to identify "meaningful groupings of objects
that have common attributes“ [LOE 07]
A formal context is a triple K = (O, A, R) where O and A are sets (objects and attributes,
respectively) and R is a binary relation, i.e., R ⊆ O × A.
Galois lattices [BAR 70] and concept lattices [GAN 99] are core structures of a data analysis
framework (Formal Concept Analysis, or FCA for short) for extracting an ordered set of concepts
from a dataset, called a Formal Context, composed of objects described by attributes.
8

9. Formal Concept Analysis (FCA):
Class (Open) Class (Close) Class (Edit) Class ( Print) Class (Select All) Class (Red) Class (Green) Class (Blue) Class (Black)
Product 1 x x x x x x
Product 2 x x x x x
Product 3 x x x x x x
Product 4 x x x x x x
Product 5 x x x x x x
A formal context describing product variants by Source code elements
The concept lattice for the formal context of Table above
Common Concept
Concept shared by two Products
Concept specific for one product
9

10. Information Retrieval (IR) & Latent Semantic Indexing (LSI):
INFORMATION RETRIEVAL (IR) has proven useful in many disciplines such as software
maintenance and evolution, image extraction, speech recognition and horizontal search
engines like Google. Furthermore feature location is one of the most common applications of IR
in software engineering [DAV 11]
LATENT SEMANTIC INDEXING (LSI) assumed that there are some implicit relationships among
the words of documents that always appear together even if they do not share any terms; that is
to say, there are some latent semantic structures in free text [DAV 11]
The effectiveness of IR methods is measured using IR METRICS: RECALL and PRECISION.
10

11. Latent Semantic Indexing (LSI):
In our work, we consider the most widely used threshold for cosine similarity that equals to 0.70
[MAR 03]
In LSI all information must be manipulated and normalized to become suitable as input of LSI.
This preprocessing step include: all capital letters must be transformed into lower case letters,
removing stop words (such as: numbers, etc.), all Documents must be split into terms and
performing word stemming.
Similarity between Documents is described by similarity matrix. The similarity is computed based
on cosine similarity.
11

12. Motivations:
Many companies at first develop a number of similar software products without explicitly
planning for strategic reuse. Once released, if the product is SUCCESSFUL and meets the market,
similar products are to be developed [JOH 09]
INDIVIDUAL SYSTEMS
A B C D E F G
A B V G O J L
A B F D E R X
A B C D E F G
A B V G
A B F D E
SOFTWARE PRODUCT LINE
12

13. Motivations:
Creating manually a feature model for an existing system is time-consuming, error-prone, and
requires substantial effort from a modeler [SHE 11]
13

14. Motivations:
REVERSE ENGINEERING FM from source code aims to improve product maintenance, ease
system migration [CHI 90], and the extracted feature model may lead to the production of
new products.
Feature Model
P1
P2
Product Variants
REVERSE ENGINEERING FM
14

15. Motivations:
The general OBJECTIVE of our approach is to EXTRACT INITIAL FM which model common and
variable features of product variants. We present IN THIS PAPER the part concerning about
FEATURE IDENTIFICATION from the OO source code of product variants using FCA and LSI.
We Assumed in this paper That The Product
Variants Use The Same Vocabulary To Name
Packages, Classes, Attributes And Methods
In Its Source Code.
15

16. Motivations:
Reverse engineering a feature model from source code for a set of product variants make
system features and dependencies explicit and clear.
There are needs to extract feature models, especially from source code the most important
source of information, where features and dependencies are hidden.
16

17. Approach Overview:
Optional Feature
Product Variants
Product
Source code elements
Package
Source code
Source code variation Block of variations
1..*
Has a 1
Class
Attribute
Method
1..*
1..*
Atomic block of variations
Feature
1..*
1..*
1..*
1
1
correspond
Feature Model
1..*
Mandatory Feature
1..*
1..*
1..*
A. The Mapping Model:
To identify features we rely on a mapping model between these features and object-oriented
building elements (OBE).
Object-oriented source code variations
17

18. Approach Overview:
For object-oriented source code, the mandatory features are realized by OBE that are common
to all product variants.
The optional features are realized by variable OBE that can appear in some product variants or
in single product but not all product variants.
We consider that a feature corresponds to one and only one set (group) of OBE. This means
that a feature always has the same implementation in all products where it is present.
18

19. Approach Overview:
As a feature corresponds to one and only one set of OBE, then an optional feature is
implemented by the same set of Variables OBE (VOBE) in all products where it is present.
We define a block of variations (BV) as a set of VOBE which are always associated (i.e., which are
always identified together in all the products in which they appear).
The subsets of VOBE that belong to a BV and represent one and only one feature are called
Atomic Blocks Of Variations (ABV). A BV is composed of set of ABVs. To determine its various
parts (sub-groups), we rely on the clustering of the closest VOBEs considering the similarity
measures that are related to LSI method.
19

20. Approach Overview: An illustrative example:
20

21. Approach Overview:
B. Feature extraction process:
The approach that we propose is illustrated in Figure below. Feature extraction process consists
of the following steps:
1. OO Source code is analyzed to extract object-oriented building elements (packages, classes,
methods, attributes) for all product variants.
2. Commonalities and variations are extracted for all product variants using FCA. “Blocks of
variations are given by using FCA”
3. Blocks of variations are divided into atomic blocks of variations. Each atomic block of
variations corresponds to one and only one feature. “using LSI and FCA“
21

22. Object-oriented source code variations:
Package Variation
Package Set Variation Package Content Variation
Class Variation
Class Content Variation
Class Signature Variation
Attributes Set Variation
Methods Set Variation
Method Variation
Signature Body
Attribute Variation ( Access Level, Data Type. etc.)
1:
2:
3:
4:
(Name)
(Name)
Relationship
Public , Private, ...Access Level
Access Level
Returned Data Type
Parameters List order & data type
Exception
Local Variable
Invocation
Access
22

23. Object-oriented source code variations example:
Package Set Variation
Package Content Variation
23

24. Object-oriented building elements OBE:
in our case each product variant PN is abstracted as a set of OBE as follow:
OBE for PN ={
Package (name);
Class (name, owner);
Attribute (name, owner);
Method (name, owner);
Parameter (name, owner);
Local Variable (name, owner);
Method Invocation (name, accessed in, owner);
Method Exception (name, owner)}.
24

25. Commonality and variation identification using FCA:
Formal context describing text editing systems by object-oriented building elements (OBE)
In the Formal context
products constitute the
rows of the Table.
In the Formal context OBE constitute the columns of the Table.
25

26. Commonality and variation identification using FCA:
The concept lattice for the formal context of previous Table.
The common block
Block of Variations
26

27. Atomic block of variations (feature) identification using LSI and FCA:
To identify the atomic block of variations that represent a single feature from a block of
variations, we consider LSI and FCA to recover all atomic block of variations.
27

28. Atomic block of variations (feature) identification using LSI and FCA:
In our case, each line in the block of variations represents a single document and at the same
time represents a query.
.
.
1 0.70
0.70 1
10 0
0
0
x x
x x
x0 0
0
0
The Similarity Matrix
The Context (Similarity Matrix) For θ= 0.70
28

29. Atomic block of variations (feature) identification using LSI and FCA:
Concept lattice shows three atomic blocks of variations extracted from one block of variations.
29

30. Related Work:
Ziadi et al. [ZIA 12] propose an automatic approach for feature identification from source code
for a set of product variants.
30
Their approach only investigates products in which the variability is represented in the name of
classes, methods and attributes, without considering a product lines in which the variability is
mainly represented in the body of methods

31. Related Work:
Ziadi approach gather all common features as a single mandatory feature under title base
feature.
We use FCA to extract commonalities and variations from product variants and distinguish
between the mandatory features by using LSI and FCA based on the lexical similarity, and
extracts all optional features and constraints such as: "and" and "require".
31

32. Conclusion:
In this paper, we proposed an approach based on FCA and LSI to extract a features from the
object-oriented source code of software system variants.
FCA can be used to extract common block and blocks of variations.
LSI is used with FCA to recover atomic blocks of variations that represent a single feature, using
the textual similarity.
32

33. Future Work:
We will use both textual and semantic similarity to determine more precisely each feature
implementation from the OO source code .
We will organize the extracted features as a feature model including all cross-tree constraints
and group of feature constraints, using the information contained in the concept lattice.
We will Integrate our approach with the linguistic matching techniques; in case product variants
use different vocabulary to names packages, classes, attributes, and methods.
33

34. [ZIA 12] ZIADI T., FRIAS L., DA SILVA M. A. A., ZIANE M., “Feature Identification from the Source Code of Product Variants”, MENS T.
CLEVE A. F. R., Ed., Proceedings of the 15th European Conference on Software Maintenance and Reengineering, Los Alamitos, CA, USA, 2012,
IEEE, p. 417–422.
[CLE 01] CLEMENTS P. C., NORTHROP L. M., Software product lines: practices and patterns, Addison-Wesley, 2001.
[JOH 09] JOHN I., EISENBARTH M., “A decade of scoping: a survey”, Proceedings of the 13th International Software Product Line
Conference, Pittsburgh, PA, USA, 2009, Carnegie Mellon University, p. 31–40.
[FIG 08] FIGUEIREDO E., CACHO N., SANT’ANNA C., MONTEIRO M., KULESZA U., GARCIA A., SOARES S., FERRARI F., KHAN S.,
CASTOR FILHO F., DANTAS F., “Evolving software product lines with aspects: an empirical study on design stability”, Proceedings of the 30th
international conference on Software engineering, ICSE ’08, New York, NY, USA, 2008, ACM, p. 261-270.
[CZA 00] CZARNECKI K., EISENECKER U. W., Generative programming: methods, tools, and applications, ACM Press/Addison-Wesley
Publishing Co., New York, NY, USA, 2000.
[POH 10] POHL K., BCKLE G., VAN DER LINDEN F. J., Software Product Line Engineering: Foundations, Principles and Techniques,
Springer Publishing Company, Incorporated, 1stedition, 2010.
[LOE 07] LOESCH F., PLOEDEREDER E., “Restructuring Variability in Software Product Lines using Concept Analysis of Product
Configurations”, KRIKHAAR R. L. VERHOEF C. L. G. A. D., Ed., Proceedings of the 11th European Conference on Software Maintenance and
Reengineering, Amsterdam, Netherlands, March 2007, IEEE, p. 159–170.
[GAN 99] GANTER B., WILLE R., Formal Concept Analysis, Mathematical Foundations, Springer-Verlag, 1999.
[BAR 70] BARBUT M., MONJARDET B., Ordre et Classification: Algèbre et combinatoire, vol. 2, Hachette, 1970.
[DAV 11] DAVID B., LAWRIE D., “Information Retrieval Applications in Software Maintenance and Evolution”, In Encyclopedia of Software
Engineering, 2011, p. 454-463.
[SHE 11] SHE S., LOTUFO R., BERGER T., WASOWSKI A., CZARNECKI K., “Reverse engineering feature models”, ICSE, 2011, p. 461-470.
[MAR 03] MARCUS A., MALETIC J. I., “Recovering documentation-to-source-code traceability links using latent semantic indexing”,
Proceedings of the 25th International Conference on Software Engineering, ICSE ’03, Washington, DC, USA, 2003, IEEE Computer Society, p.
125–135.
References:
34

35. 35

36. Banking systems example: