Concept lattices: a representation space to structure software variability

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


Table 3. A formal context describing bank systems by construction primitives.

CreatePackage(bs) … … … … … … … CreateAttribute(cons,Bank)

Product1Bank x … … … … … … … x

Product2Bank 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.


22


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.


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


• 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


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

Concept lattices: a representation space to structure software variability

Software

Transcript of Concept lattices: a representation space to structure software variability