concept lattices: a representation space to structure software variability
DESCRIPTION
Concept lattices: a representation space to structure software variabilityTRANSCRIPT
Concept lattices: a representation space to structure software variability
R. AL-msie’deen1, M. Huchard1, A.-D. Seriai1, C. Urtado2, S. Vauttier2and A. Al-Khlifat3 1LIRMM / CNRS & Montpellier 2 University, Montpellier, France
{al-msiedee, huchard, seriai}@lirmm.fr2LGI2P / Ecole des Mines d’Al`es, Nˆımes, France
{Christelle.Urtado, Sylvain.Vauttier}@mines-ales.fr3Al-Balqa’ Applied University Salt, Jordan
{amak n}@hotmail.com
1
2
Introduction
• Software variants– Are similar software
• Share some features, called common features, and differ in others, called optional features (variability)
• Software product Line (SPL)– SPL supports efficient development of related software
products (software family) .– Manages common and optional features (variability
management).– Central and unique to SPLE is the management of
variability
3
The context
• Variability in SPL is an assumption about how members of a
family may differ from each other.
• Variability may be identified from different viewpoints.
• Feature model is presently the most popular technique to
model variability.
• Software Product Line – Feature model (FM)
• Is a tree-like graph of features and relationships among them (constraints)
• Used to represent commonality and variability of SPL members at different levels of abstraction
The context
5
Software Product Line Engineering (SPLE):
• A software product line (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” [Clements, 2001].
Version 1 Version 2 Version 3
6
Software Product Line Engineering (SPLE):
Domain Engineering Application Engineering
e.g., Source code
Core
As
sets
FM
F1 F0
Feature Model
F2
Reengineering existing software variants into a software product line.
Copy-paste-modify (delete, add, modify)
8
SPLE: Variability• Central and unique to SPLE is the management of variability. It is one of the
fundamental principles to successful SPLE. Variability management of a product family is the core aspect of SPLE [Al-Msie’deen, 2013].
Product Gamma
Product AlfaProduct Beta
The common source code elements among all software product variants
The shared source code elements between Alfa and Beta products
source code elements unique to product Beta
9
SPLE: Feature Model
Fig. 1. Cell Phone SPL Feature Model (using FeatureIDE plugin).
RequiresExcludes
1. Group of features constraints : or + Xor
2. Cross-tree constraints
10
Issue• Software variants
– Difficulties for : • Reuse• Maintenance • Comprehension • Impact analysis
• Software Product Line – Design from scratch is a hard task (domain engineering)
Software_A
I1 I1I2 I3
Implementation Space
? ?
Software_B
F1 F1F2 F3
Feature Space
Our Goal• Reengineering existing software variants into a
software product line.
A
C
B
3
AB
3 B
C
A
Variability
FCAFormal concept analysis
12
Introduction: Formal Concept Analysis
• Formal Concept Analysis (FCA) is a theoretical framework which structures a set of objects described by properties.
• Formal Concept Analysis is a classification technique that takes data sets of objects and their attributes, and extracts relations between these objects according to the attributes they share.
• FCA is a methodology for: (application) 1 - data analysis, data mining. 2- knowledge representation.
13
Formal Concept Analysis: Formal Context
• 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.⊆
flying nocturnal feathered migratory with crest with membrane
flying squirrel x X
bat X X X
ostrich X
flamingo X X X
chicken X X X
Table 1: A formal context for describing animals.
objects
attributes
14
Formal Concept Analysis: Formal Concept
• Formal Concept: Given a formal context K = (O, A, R), a
formal concept is a pair (E, I) composed of an object set E ⊆
O and an attribute set I A. E = {o O| a I, (o, a) R} is ⊆ ∈ ∀ ∈ ∈
the extent of the concept, I = {a A| o E, (o, a) R} is the ∈ ∀ ∈ ∈
intent of the concept.
Intent
Extent
15
Formal Concept Analysis: Concept Lattice
• Let CK be the set of all concepts of a formal context K. This set
of concepts provided with the specialization order (CK, ≤s) has a
lattice structure, and is called the concept lattice associated with
K.
Concept : maximal group of entities sharing characteristics.
Concept lattice : concepts with a partial order relation.
16
Top Concept
Bottom Concept
Intent
Extent
Formal Concept
Figure 1: The concept lattice for the formal context of Table 1.
More general concept
More specific concept
17
Formal Concept Analysis: AOC-poset
• In our approach, we will consider the AOC-poset (without empty
concepts).
• The AOC-poset (for Attribute-Object-Concept poset) is the sub-order
of (CK, ≤s) restricted to object-concepts and attribute-concepts.
For our example, it would correspond to the concept lattice of Figure 1 deprived of
Concept_0, Concept_4 and Concept_5 (cf. Figure 2). Tools (rename).
Cont ….
Figure 2. The AOC-poset for the formal context of Table 1.
19
Concept Lattice & AOC-poset
• There is a drastic difference of complexity between the two
structures, because the concept lattice may have 2min(|O|,|A|)
concepts, while the number of concepts in the AOC-poset is
bounded by |O|+|A|.
• Algorithms for building AOC-posets are introduced in [Ganter,
1997].
• Extents and intents are presented in a simplified form, removing
top-down inherited attributes and bottom- up included objects.
20
SPL reverse engineering approaches
• Ziadi et al. [Ziadi, 2012] proposed semi-atomic approach to identify feature from OO
source code.
• Their approach takes as input the source code of a set of product variants.
• They propose an ad hoc algorithm to identify the feature candidates of a given set of
products.
• Their algorithm gathers all construction primitives that common to all product variants
as one feature (base feature).
• For the construction primitives that unique to a single product or common to two or
more products but not all products their algorithm gathers these construction
primitives as one feature.
Feature Identification from the Source Code of Product Variants
21
SPL reverse engineering approaches
Table 3. A formal context describing bank systems by construction primitives.
CreatePackage(bs) … … … … … … … CreateAttribute(cons,Bank)
Product1Bank x … … … … … … … x
Product2Bank x … … … … … … …
Product3Bank x … … … … … … … x
Product4Bank x … … … … … … …
Product5Bank x … … … … … … … x
Product6Bank x … … … … … … …
Product7Bank x … … … … … … … x
Product8Bank x … … … … … … …
First, a formal context, where objects are product variants and attributes are construction primitives (Table 3), is defined. The corresponding AOC-poset is then calculated.
Feature Identification from the Source Code of Product Variants
22
SPL reverse engineering approaches
In the AOC-poset, the intent of each concept represents construction primitives common to two or more products.
As concepts of AOC-posets are ordered, the intent of the most general (top) concept gathers primitives that are common to all products. They constitute the mandatory features.
The intents of all remaining concepts are block of variation (variability). They gather sets of primitives common to a subset of products and correspond to the implementation of one or more features. The extent of each of these concepts is the set of products having these primitives in common.
Feature Identification from the Source Code of Product Variants
23Figure 5. Concept Lattice of formal context in Table 3.
Common featuresOr
Mandatory features
Variable features
Empty Concept
24Figure 6. The AOC-poset for the FC of Table 3.
Excludes
Requires
25
SPL reverse engineering approaches
• Acher et al. [Acher, 2012] present an procedure (semi-automatic procedure) to
synthesize FM based on the product descriptions.
• Their approach takes as input product description for a collection of product
variants to build the FM.
• Products are described by characteristics (language, license) with different patterns
on values (many-valued, one-valued).
• Product descriptions are interpreted to build as much FMs as there are products.
• Finally, the FMs of the products are merged, producing a new FM that compactly
represents valid combinations of features supported by the set of products.
Extracting Feature Models From Product Descriptions
SPL reverse engineering approaches
Table 4. A formal context describing wiki systems by characteristics.
License Unicode RSS … … LicenseCostFree Community
Confluence x x x … …
Pbwiki x x x … …
MoinMoin x x x … …
DokuWiki x x x … …
PmWiki x x x … …
DrupalWiki x x x … …
Twiki x x x … … x
MediaWiki x x x … …
26
The formal context, where objects are wiki variants and attributes are characteristics (Table 4), is defined. The corresponding AOC-poset is then calculated.
Extracting Feature Models From Product Descriptions
27Figure 5. Concept Lattice of formal context in Table 3.
Common features
feature Language_PHP requires feature Licence_GPL2
Atomic set of features10,1,3
feature storage _files excludes feature LCF_Differeent License
requires
Cell phone SPL feature model
Excludes
Requires
29
SPLE: Software Configurations
Cell_Phone Wireless Infrared Bluetooth Accu_Cell Strong Medium Weak Display Games Multi_Player Single_Player Artificial_OpponentP1 x x x x x x xP2 x x x x x x xP3 x x x x x x xP4 x x x x x x x x xP5 x x x x x x x xP6 x x x x x x x x x xP7 x x x x x x x x xP8 x x x x x x x xP9 x x x x x x x x x xP10 x x x x x x x x xP11 x x x x x x x xP12 x x x x x x x x x xP13 x x x x x x x x xP14 x x x x x x x x x xP15 x x x x x x x x xP16 x x x x x x x x x x x
Table 2. product-by-feature matrix (i.e., formal context) of cell phone SPL.
30Figure 3. The AOC-poset for the FC of Table 2.
SPLE: Restructuring Variability in SPLs using Concept Analysis of Product Configurations
Mandatory features
requires
Root feature
31
Tools:
• Erca plugin.
• Erca is a framework that eases the use of Formal and Relational Concept Analysis, a neat clustering technique.
• Link: https://code.google.com/p/erca/
32
Conclusion
• In this paper, we focused on concept structures and the opportunities they offer for structuring variability.
• Concept structures can be seen a summary of known data (artifacts, features, etc.) for a set of products.
• In this paper, we revisit two papers (to show some illustrative example) from the literature of the software product line domain. We point to key contributions and limits of the representation of variability by concept lattices, with illustrative examples. We present tools to implement the approach and open a discussion.
33
Future Direction 1/2
• Reverse engineering feature models (FM) from software variants source code (object-oriented).
• Feature location in collection of software product variants (functional feature == source code implementation).
• Split source code elements of each concept into a set of features based on the lexical similarity (based on LSI method).
34
Future Direction 2/2
S/F F_1 F_2 F_3
S_1 x x
S_2 x x
S_3 x x
Reverse Engineering
Source code Configurations
Product-by-feature matrix
Feature model
Forward Engineering
Build systems
Reverse Engineering FMs
SynthesisFeature location & documentation
variant 1 variant 2
variant N
Product configurations
Configuration files
Requirements
35
References
• [Ganter, 1997] B. Ganter and R. Wille, Formal Concept Analysis: Mathematical Foundations, 1st ed. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 1997.
• [Clements, 2001] P. C. Clements and L. M. Northrop, Software product lines: practices and patterns. Addison-Wesley, 2001.
• [Al-Msie’deen, 2013] R. Al-Msie’deen, A. Seriai, M. Huchard, C. Urtado, S. Vauttier, and H. E. Salman, “Feature location in a collection of software product variants using formal concept analysis,” in ICSR. Springer, 2013, pp. 302–307.
• [Ziadi, 2012] T. Ziadi, L. Frias, M. A. A. da Silva, and M. Ziane, “Feature identification from the source code of product variants,” in CSMR, 2012, pp. 417–422.
• [Acher, 2012] M. Acher, A. Cleve, G. Perrouin, P. Heymans, C. Vanbeneden, P. Collet, and P. Lahire, “On extracting feature models from product descriptions,” in VaMoS, 2012, pp. 45–54.
36
Thank You For Your Attention
37
Concept lattices: a representation space to structure software variability
R. AL-msie’deen1, M. Huchard1, A.-D. Seriai1, C. Urtado2, S. Vauttier2and A. Al-Khlifat3 1LIRMM / CNRS & Montpellier 2 University, Montpellier, France
{al-msiedee, huchard, seriai}@lirmm.fr2LGI2P / Ecole des Mines d’Al`es, Nˆımes, France
{Christelle.Urtado, Sylvain.Vauttier}@mines-ales.fr3Al-Balqa’ Applied University Salt, Jordan
{amak n}@hotmail.com
ICICS 2014