Embed Size (px)
Citation preview
Lille, le 6 novembre 2012
! i
"#$%&!'&(!)#"*&+&(!!"#$%&#'(,,,-,,,,,,,,,,,,-,,,,,,,,,,,,,,,,,,,,,,,,,,,---..!)&*'+#,'$#%+,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,---,,--,...!!!"#$%&"'(()"*+&,$-(.+/0+-"1(+$2(3%4&5+6"(76%28/&(9,$"1(+/0123/!'.!4/56/,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,---------------------------------7!!3"11,%$():&6%;<$-:$,"6,"(!!"#$%&"'()"*$+,+-#$+.*',&./'$0"'1.%&-"'2.)"'.,'3&.)%-$'4#&+#*$5''"189.:!;.<=.>!%?@!A2.<5>!)<2B/5!#?2CD./!#D61.=<!'<!(.DE<!13!).:<D!;.<F1,,,,,,,,,-G!!6"*"$+-' 789.&+$0/5' #5' :"-.;"&+*9' <&#-"#=+8+$>' ?+*@5' A"$0.)' ="$B""*' !"#$%&"'A.)"85'#*)'1.%&-"'2.)"'.,'3&.)%-$'4#&+#*$5!!H<6@1I!&J<DK(<D6<F>!#0=1DI<:!(12.<.>!4I2.53/LI1!'/FJ!13!+<MA<3!#DK)5.1M'11F,,,,--N!!7*'#CC&.#-0'$.'&"-.;"&',"#$%&"'/.)"85',&./'.=D"-$E.&+"*$")'5.%&-"'-.)"!!+<MA<3! #DK)5.1M'11F>! #0=1DI<:! (12.<.>! )<2.<FF1! H?BI<2=>! 4I2.531DD1! O23<=/>! (JDE<.F!P<?33.12!13!H<6@1I!&J<D!(<D6<F,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,-7Q!!3"11,%$(=%2:*,1+&,%$("&(>6/?,&"/&86"(!A.)"88+*9';#&+#=+8+$>'%5+*9'24?F'7'5$"C'=>'5$"C'$%$.&+#8!RC2S61!%1!T/.2>!UD.E.12!$<2<.5>!R/V/!$/5B/!A1221.2<!A.DI/>!R1<FK)<2B!RC@CW?1D!13!)<3I.1?!#BI12,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,-GX!!:"8#$+.*50+C5'+*'4#&+#=+8+$>'A.)"8+*9'7CC&.#-0"5G'7'1%&;">'#*)'28#55+,+-#$+.*!!(31LI1F!42199!13!R/YD!4I<6L1<?!,,--,,,,,,,,,,,,,,,,,,,,,,,,,,,,NQ!!+19<B3/2.FZ![2/B155!9/2!(/938<21![2/=?B3!%.F1!#2BI.31B3?21!'15.ZF!A2<FB.5B<!%/5<E./>!U5B<2!U2=<@>!T.B/D1!%1EJ!13!#F3I/FJ!$<./33/,,,,,,,,,,,,---\X!!3"11,%$(@%$4,-86+&,%$(!4"&5')"5'+*$"&,#-"5'9&#C0+H%"5',8"I+=8"5')"'-.*,+9%&#$+.*5'(.6/F!O2D.>!]?.DD<?61![121@>!H1J316!;.3/?F>!).21.DD1!$D<JKA/2F<2.F/>![I.D.LL1!4/DD13!13![I.D.LL1!+1F1E.12K]/F.F,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,--Q^!!4"&5')"5'J.&@,8.B5'2.*,+9%&#=8"5'"$'1$#*)#&)+5K5'G'3&"/+L&"5'MICK&+"*-"5!!_?1F3.F!$/?BI12>!R<BW?15!AD<6<F=>!)<2B!"I?F.551F!13!R1<FK4I2.53/LI1!'1L21@,,,,X7!!4"&5'%*'N%$+8')"'OKC8.+"/"*$'C.%&'8"5'P%#9"5''4DC61F3!_?.F3/F!13!%<?21FB1!'?BI.1F,,,,,,,,,,,,,,,,,,,,,,,,,,,`N!
! ii
"#$%&'$()!!!!
!%*+,!-.,!/0,!1.2+3,!45567!-/!8!9*+:0;.!)3<0.,!1.!=:*1+3>,!?!:/,,.@A-.!301+,>:3.-,!.>!/B/1;@3C+.,!D:/0B*2E*0.,!/+>*+:!1.!B.>>.!>E;@/>3C+.F!)/!G*+:0;.!)3<0.,!1.!=:*1+3>,!.,>!*:</03,;.!.0!45H4!2/:!$0:3/!)3--.!I!J*:1!"+:*2.7!-KL03M.:,3>;!)3--.!H!NB3.0B.,!.>!%.BE0*-*<3.,!.>!-.!)$O)!LP'!6544!QJ'NF!!!!Q.>>.!/00;.7!0*+,! ,*@@.,! :/M3,!1R/BB+.3--3:!'*A.:>*!#3!Q*,@*!.0! B*0D;:.0B3.:!30M3>;7!C+3!*+M:3:/!-/!G*+:0;.!,+:!-/!:.-/>3*0!.0>:.!-.,!<.,>3*00/3:.,!1.!2/BS/<.,!.>!-.,!-3<0.,!1.!2:*1+3>,F!!!!(! B.>>.! 30>:*1+B>3*0! ,R/G*+>.0>! T! 2:;,.0>/>3*0,7! A/,;.,! ,+:! 1.,! /:>3B-.,!,;-.B>3*00;,! BE/B+0! 2/:! 1.+U!@.@A:.,! 1+! B*@3>;! 1.! 2:*<:/@@.F! ).,! >:/M/+U!/30,3! BE*3,3,! B*+M:.0>! -R.0,.@A-.! 1+! BVB-.! 1.! M3.! 1.,! -3<0.,! 1.! 2:*1+3>,7! 1.! -/!:;>:*I30<;03.:3.! W! -/! B*0D3<+:/>3*0! .0! 2/,,/0>! 2/:! -/! @*1;-3,/>3*0! .>!-R/:BE3>.B>+:.F!!!Q.,! >:/M/+U! ,*0>! /+,,3! 13M.:,! 1/0,! -.+:! 0/>+:.7! B/:! .0! 2-+,! 1.,! 2:;,.0>/>3*0,!8!B-/,,3C+.,!?7!-.!2:*<:/@@.!B*@2:.01!+0!>+>*:3/-!1R+0.!E.+:.!,+:!QX)!2:;,.0>;!2/:! 9;:Y@.! ).! J*3:! Z%E/-.,[! /30,3! C+.! -/! 2:;,.0>/>3*0! 1R+0! /:>3B-.! 8/BB.2>;!/3--.+:,!?7! .0! -R*BB+::.0B.! W! -/! B*0D;:.0B.! QNP'\"'(! 45H47! 2/:! %.]D3S! ^3/13!Z)$=_[F!!!
!!!!
)/+:.0B.!#+BE3.07!=/>:3BS!`.V@/0,7!a3--.,!=.::*+30!.>!Q-;@.0>!b+30>*0!
! iii
"#$%&'(%)'"&!
!!
!!
!"#$%&'$()*"'+,+!*+,-./0.!1234'5&6!*'7*6!'/-8+6!2/89.-:8;<!*8==.!>6!7-+/0.!!
?+;-80@!45AB%&(6!?#.3'(56!2/89.-:8;<!C.!&+D,-6!E.=F8G,.!!
$8==.:!?5##"2'&6!7&#(6!?#.3'(56!2/89.-:8;<!C.!&+D,-6!E.=F8G,.!!3=<D./;!H2'&)"&6!*'7*6!'/-8+6!2/89.-:8;<!*8==.!>6!7-+/0.!
!-./&(0+1)+2".#"$//)+,+!
I+98.-!E*%&36!*+E#'6!2/89.-:8;<!C.!EJ-C.+,K!'6!7-+/0.!!?L8=8MM.!3"**5)6!'N(6!2/89.-:8;<!C.!&80.!(JML8+O%/;8MJ=8:6!7-+/0.!!
$+,;L8.-!7%&B2A6!%1&6!?+-8:6!7-+/0.!!
B+-8+//.!4234%#16!*'#BB6!2/89.-:8;<!C.!BJ/;M.==8.-!P6!7-+/0.!!Q.+/OB+-0!Q5R5H25*6!'#'(%6!'/-8+6!2/89.-:8;<!C.!#.//.:!>6!'#'(%6!7-+/0.!!
Q+0G,.:!S*5'&6!(/)6!2/89.-:8;<!C.!*,K.DTJ,-F6!*,K.DTJ,-F!!1+/8.=!*5!E5##56!3#'*6!2/89.-:8;<!CU%-;J8:6!*./:6!7-+/0.!!
A9.:!*51#26!*'$6!2/89.-:8;<!$-./JT=.!>6!7-+/0.!!
1+/8.=!*23%(O4'#)R6!5I'E#'6!#.//.:6!7-+/0.!#+,=!B+VJ6!3#'6!2/89.-:8;<!?+-8:!>!W!?+/;L<J/!(J-TJ//.6!7-+/0.!!
Q.+/O3=+,C.!#"A5#6!*'&%6!'/-8+6!50J=.!C.:!!B8/.:!&+/;.:6!7-+/0.!!?+;-80@!)5(('5#6!*+TJ-+;J8-.!*'(56!35%!(+0=+X6!7-+/0.!!
3+D8==.!(%*'&5('6!3#'6!2/89.-:8;<!?+-8:!>!W!?+/;L<J/!(J-TJ//.6!7-+/0.!
!3$44."()*"'+56()"%)'+,+!
3L-8:;JML.-!4</+-C6!!!E</<C80;.!*.F-+/C!
Keynote: Relating packages and Software Prod-uct Lines
Roberto Di Cosmo
Université Paris Diderot,
Inria,
Irill
ABSTRACT. Component based systems are ubiquitous today, and several abstraction are in use
to master the complexity that arises from the steady growth of the software landscape. Among
these, packages are very popular in the Free and Open Source Software world, and Software
Product Lines are being swiftly adopted in industry. In this talk we will show that it is possible
to encode some SPLs as package repository, thus paving the way to reusing some of the results
and tools developed over the past years for package repositories.
1
Feature Identification from the Source Code
of Product Variants 1
Tewfik Ziadi*, 2 — Luz Frias** — Marcos Aurélio Almeida da Silva* ,Mikal Ziane*
* UMR CNRS 7606, LIP6-MoVe 4 Place Jussieu, Paris, France
{prenom.nom}@lip6.fr
** Indra Sistemas Avenida de Bruselas, 35 Alcobendas, Madrid 28108 Spain
ABSTRACT. In order to migrate software products which are deemed similar into a product line,
it is essential to identify the common features and the variations between the product variants.
This can however be tedious and error-prone as it may involve browsing complex software and a
lot of more or less similar variants. Fortunately, if artefacts of the product variants (source code
files and/or models) are available, feature identification can be at least partially automated. In
this paper, we thus propose a three-step approach to feature identification from source code of
which the first two steps are automated.
KEYWORDS: Product Lines; Features; reverse engineering
1. This paper was published in CSMR/ERA 20122. Contact Author
2
Soumission à JLP 2012, le 29 October 2012
Genetic Algorithms as Recovering Traceability Links Method between Feature Models and Source Code of Product Variants
Une Approche Basée sur un Algorithme Génétique pour l'identification de la Traçabilité entre le Modèle des Caractéristiques et le Code Source de Variantes de Produits
H. Eyal Salman*, A. Djamel Seriai*, C. Dony*, R. Al-Msiedeen* * LIRMM (CNRS and Univ. Montpellier 2), Montpellier, France,
RÉSUMÉ. Les variantes d'un même produit obtenues souvent par un processus de modification, de mises à jour ou d'évolution constituent le point de départ pour la construction d'une ligne de produits. Ainsi, pour transformer ces variantes en une ligne de produits, il est nécessaire d'identifier les liens de traçabilité entre ses différents artefacts par rapport à la variabilité. L'identification de cette traçabilité constitue une différence majeure entre un processus de développement classique et un autre orienté vers les lignes de produits. Le traçage de la variabilité permet de mieux comprendre les systèmes dérivés d'une ligne de produits, d'automatiser le processus de sélection de ces produits et de faciliter leur maintenance et leur évolution. Ce papier présente un algorithme génétique permettant l'identification des liens de traçabilité entre le modèle de caractéristiques (feature model) et les codes sources d'un ensemble de variantes de produits logiciels.
ABSTRACT. Usually software product variants, developed by clone-and-own approach, form often a starting point for building Software Product Line (SPL). To migrate software products that deemed similar into a product line, it is essential to trace variability among software artifacts. Variability tracing is used to support conversion from traditional software development into software product line development and that leads to automate products derivation process such that core assets can be automatically configured for a product according to the features selection from the feature model. Tracing and maintaining interrelationships between artifacts within a software system also are needed to facilitate program comprehension, make the process of maintaining the system less dependent on individual experts. This paper presents genetic algorithms (GAs) as a recovering traceability links method between object-oriented source code of product variants and their feature model.
MOTS-CLÉS : traçabilité, modèle de caractéristiques (feature model), code source, orienté objet, variabilité, ligne de produit logiciel, algorithme génétique.
KEYWORDS: Traceability links, feature models, source code, object oriented,
variability, software product line, Genetic Algorithms.
3
1. Introduction
Software product line (SPL) aims to reduce development cost and time by producing a family of software products rather than one product in each time. According to software engineering institute (SEI) definition, a 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” [CLE 01]. In reality, software product variants form a starting point for building SPL, when companies have to release a new product that is similar, yet not identical, to existing ones.
Usually, developers use clone-and-own approach to build a new product variant from existing ones. As a consequence when number of features and product variants grows, such ad hoc reuse technique causes critical problems such as: we must maintain each product variant separately from others and it also becomes difficult to find and trace features for reuse in new products.
As these problems accumulate, it became necessary to re-engineering product variants into a SPL for systematic reuse. There are three issues that must be considered to reengineering product variants into SPL: extraction of a FM for product variants, building SPL core assets and mapping between FM as a representative of variability model in software product line engineering (SPLE) and SPL artifacts [POH 05].
In SPLE, FM is considered as the key factor that distinguishes SPL development from other software development strategies [CLE 01]. FM of product variants can be provided by system’s developers and domain experts who accompanied and contributed product variants evolution. FM also can be reverse engineered from documentations of products variants [ACH 12]. Regarding building SPL core assets, the development team can utilize and use available reusable elements such as: source code, design documents, test cases, etc. to build the required SPL core assets.
These parts (FM and SPL core assets) must be connected to exploit them during SPL life cycle [POH 05]. Where source code artefact is an important part in SPL core assets, we propose an approach to identify traceability links between source code of product variants and their FM using genetic algorithms (GAs). These links connect each feature with its implementation as a set of source code elements. The traceability links can be used to generate partially SPL core assets, automate products derivation process by automatically configures all the assets for a product according to the features selection from the FM, find dependency between features, ensure consistency between extracted FM and source code, facilitate program comprehension process, make the process of maintaining the system less dependent on individual experts and recovery various architectural elements.
The remainder of the paper is organized as follows. Section 2 discusses background. Section 3 presents recovering traceability links as an optimization problem. Section 4 shows an overview about our recovering traceability link process. Section 5 presents GAs as recovering traceability links process. Section 6
4
shows the experimental results. Section describes related works. Finally, Section 8 introduces our conclusions and future work.
2. Background
In this section, we provide a brief explanation of some key concepts, and how they are used in our approach: feature model, traceability and GAs.
2.1 Feature Model
Feature modeling is a method for describing commonalities and variabilities in software product line. Feature model was first introduced in the Feature-Oriented Domain Analysis (FODA) method by Kang in 1990 [KAN 90]. Since then, many researches have been done to suggest improvement over feature model. A feature model consists of a feature diagram and other information such as rationale, constraint, and dependency rule. A feature diagram is a graphical tree-like representation depicting the hierarchical structure of features [BEN 10]. The root of the tree represents the complete system.
In FODA, variability can be represented in several ways. Mandatory features
must be selected when its parent is selected. An optional feature may or may not be selected when its parent is selected. Features can be organized into feature groups. XOR-Group refers to exactly one member of the group must be selected if its parent is selected. OR-Group means that one or more members must be selected if its parent is selected and AND-Group means that entire group must be selected if its parent selected [BEN 10]. Fig.1 represents a FM of mobile software. Features are represented as rectangles. Optional features are denoted by an empty circle. Mandatory features described by a filled circle. A XOR-Group is specified with a clear arc while an OR-Group with filled arc. An AND-Group is described without arc. An edge between features refers to a dependency where a solid line is used to present the feature tree and a dashed line show a cross-tree edge. Cross-tree edges represent exclude or require constraints.
Figure1. Mobile software feature model [BEN 10]. 2.2 Traceability
Software artifact traceability is the ability to describe and follow the life cycle of an artifact (requirements, design models, source code, etc.) created during the
5
software life cycle in both forward and backward directions (e.g., from requirements to the software architecture and to the implementation and vice-versa) [GOT 94].
Traceability relations can refer to overlap, satisfiability, dependency, evolution,
generalization/refinement, conflict or rationalization associations between various software artifacts [RAM 01]. In general, traceability relations can be classified as horizontal traceability or vertical traceability. The former type refers to relationships between different levels of abstraction (e.g. from requirements to design to implementation) and the latter type refers to relationships among artefacts at the same level of abstraction (e.g. among related requirements) [LIN 96, SPA 05].
SPLE introduces a third dimension of traceability to deal with variabilities and
commonalities. Traceability links in SPLE are needed to relate variation points and variants with all corresponding low level artefacts (requirements, design models, source code and test cases artefacts) [LIN 96].
2.3 Genetic algorithms (GAs)
GAs has been a very interesting area of study in many disciplines since it was published for the first time. Researches are growing rapidly regarding either the behavior or the application of GAs for a particular purpose. Some applications of GAs are optimization, automatic programming, economics, immune systems, ecology, population genetics, evolution and learning, and social systems [MIT 96].
The steps of a simple GAs is given in algorithm 1 below. The algorithm works
like this: a population is created with a group of individuals created randomly (line 1). The individuals in the population are then evaluated (line 2). The evaluation function is provided by the programmer and gives the individuals a score based on how well they perform at the given task. Two individuals are then selected based on their fitness (line 4) where the higher fitness, the higher chance of being selected. These individuals then reproduce by applying crossover and mutation operators to create one or more offspring (line 5). The algorithm will iterate until the population has evolved to form a solution to the problem, or until a maximum number of iterations have occurred (line 6).
Algorithm1: Simple Genetic Algorithm
1 initialize population; 2 evaluate population; 3 while termination criterion not reached 4 select solutions for next population; 5 perform crossover and mutation; 6 evaluate population;
6
3. Recovering traceability links as an optimization problem
FM consists of two types of constraints: Firstly, cross tree constraints that include require and exclude constraints. Secondly, constraints on a group of features include AND, XOR and OR group constraints. Whenever both types of constraints are projected onto a set of classes that represent all software product variants, we can find exactly or approximately a set of classes that correspond to a feature. So these constraints can be used to guide an optimization technique like GAs during the search space to find a solution.
In section 5, we will discuss how both types of constraints can be modeled in
order to use them as a guide during the search space to find each feature implementation.
4. Recovering Traceability Links: An Overview
This section describes our approach to recovering traceability links between product variants implementation and their FM, and explains our mapping model to associate each feature with its implementation.
4.1 Feature versus Object-Oriented Elements: The mapping Model
The goal of our approach is to identify traceability links between a FM which model common and variable features of software product variants, and its implementation. We rely on the following definition of the feature: a feature is a prominent or distinctive user-visible aspect, quality, or characteristic of a software system or systems [KAN 90]. We consider that a feature represents an aspect valuable to the customer. It is represented by a single term. We adhere to the classification given by [RIE 03] which distinguishes three categories of features: firstly, functional features express the behavior or the way users may interact with a product; secondly, interface features express the product's conformance to a standard or a subsystem and thirdly parameter features express enumerable, listable environmental or non-functional properties. In our work, we consider only functional features.
As there are several ways to implement features [BEU 04], we assume that the
functional features are implemented at the programming language level. Thus, the elements of the source code can reflect these features. For object-oriented source code, the mandatory features are realized by object-oriented building elements (OOBE) (i.e. packages, classes, methods and so on) that shared by all product variants. However, the optional features are realized by variable elements that may 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.
7
In Package variation, the variability is implemented at the class level by two ways: packages set and content variation. Packages set variation means a set of packages that appear in some products but not all products. Packages content variation means that all product variants have the same packages in term of packages names but with different content in term of classes. Variation at the class level can be detected at class signature, attributes set and methods set. Class variation means two or more classes have the same name in all products variants but with different signature such as: different relations, and with different methods and attributes set. Variation at the method level can appear in the method signature and body, e.g. two methods with same name but with different access level, returned data type, parameters list, method exception and body. Variation at Attribute level can be seen in attribute declaration namely in the access level, data type.
According to our mapping model (Fig.2), features either optional or mandatory
can be implemented by a set of source code elements of product variants: package, class, method and attribute. Where the main building unit of any object oriented language is class, in this paper we consider variation at package level. This means that features are implemented as a set of classes.
Fig.3 illustrates the traceability recovery process of our approach. The inputs of
this process are FM of software product variants, features description and object-oriented source code of product variants. By considering our mapping model, a feature is implemented by a set of classes. In the case of mandatory features, these classes are common to all product variants. However, in the case of optional features, these classes are variables (belong to some product variants).
Figure 2.Feature to source code elements mapping model. To identify the classes associated with each feature, we rely on a two-phase
process. The first phase, identify common and variable classes in all product variants. The second phase, establish traceability links between features and their classes using GA.
8
Source code of product variants is analyzed by the code analysis system in order to extract all classes (1). Common classes and variable classes are extracted by conducting a lexical matching between extracted classes (2). We assumed that the product variants use the same vocabularies to name packages, classes, attributes and methods in its source code.
After identifying common and variable class in all product variants, GAs will use
products configuration with all constraints that are provided by FM to identify traceability links between FM features and its implementation (3). Products configuration and FM’s constraints are used to build a fitness function. In section 5, we will explain in more about GAs as a recovering traceability links method.
Figure 3. Our approach for recovering traceability links.
5. GAs as recovering traceability links method
In order to deal with GAs as a recovering traceability links method, we must consider two issues. Firstly, we must model our solution as a chromosome. In our case, the chromosome is a partition as shown in fig.4. The 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 refers to number of all product variants features. Union of all clusters gives all software product variants classes.
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 as shown in fig. 4. In order to improve the search space, mandatory features in the initial population must be mapped to the common classes. For example in fig.4, the mandatory features (F1 to f3) are mapped to common classes (1 to 8).
9
Figure 4. An example of a chromosome structure.
Secondly, building a fitness function that exploits all available information
provided by the FM in addition to products configuration to guide GAs to the best solution. Information that is provided by a FM includes: mandatory features, XOR-Group of features, OR-Group of features and cross tree constraints (require and exclude constraints). We designed a fitness function by considering the following constraints. 1. All features are atomic (AF): Any partition containing a cluster of classes that
partially are included in some product will be rejected.
2. 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.
3. Two different features have different implementations (FI).
4. Each product must have all mandatory primitive features (MF).
5. Each product must have just one member of mandatory XOR- group (XOR).
6. Each product must have at least one member of mandatory OR-group (OR).
7. Exclude constraint must be satisfied (EX).
8. Require constraint must be satisfied (RE).
These constraints are based on information provided by FM and software product
variants configurations in order to reserve the partition or reject it. Any partition which doesn’t satisfy all above constraints at the same time for all software product variants will be rejected. The remained partitions represent all possible solutions that can be used to determine approximately or exactly the implementation of each feature where each cluster represents a possible implementation for a particular feature.
Equation 1 represents the fitness function according to the above constraints. The
fitness value for each partition is computed based on the number of constraints that are satisfied by the partition. The worst partition has a fitness value 0 (a partition doesn’t meet all the above constraints) and the best one has fitness value 8 (meets all above constraints). F=AF+NFC+FI+MF+XOR+OR+EX+RE ……………………………..……. (EQ1).
10
6. Experimental results
In order to validate GAs as traceability links recovering method between source code and feature model, we will consider simple mobile phone software to test GAs. Fig.1, in the background section; represent a feature model for mobile phone software. We apply GAs with parameters values that are mostly used [MIT 96, LIN 00].
In fig.1, Calls, SMS and MMS are mandatory features, while GPS is optional feature. Screen is alternative feature. Media is OR-group feature. This FM contains two types of cross tree constraints: dashed line represents exclude constraint between Basic and GPS while solid line represents require constraint between Camera and Highresolution. Three configurations were selected to realize three products. These configurations consists of (8) features and realized by (11) classes as shown in table 1 and table 2 respectively. Classes of these features are written by using Eclipse as not executable classes (just as interfaces and prototypes).
We will assume that each feature is implemented with certain classes as shown in the table 2 below. For example, Calls feature is implemented by !"#$%!%&#"'())*+,'()),!"#$$%$&'(&)*%&+,-&./&
Table 1. Set of products variants.
Products Configuration
Product#1 Calls MMS SMS Basic MP3
Product#2 Calls MMS SMS HighResolution Camera
Product#3 Calls MMS SMS HighResolution GPS Camera
Table 2. Features 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 3 represents all possible classes for each feature according to GAs. The
first column represents all features and the second column represents obtained classes for each feature by applying GAs. This table shows that this method can determine approximately the implementation for some features while it can
11
determine exactly for other features, for example, HighResolution feature can be implemented by HighResolution class , Camera class , MediaCamera class or any combination among them while GPS feature just implemented by GPSService class.
To validate our results, we compared table 4 with table 3 that represents real implementation for each feature. The comparison refers to that the real implementation for each feature except GPS feature is a subset of obtained classes of corresponding feature while the GPS feature exactly is implemented by GPSService class. Table 3. GAs Results.
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 gives one partition or solution for each run (execution) so how many number of runs that must be done to find all possible classes for each feature? 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 but in other case study, the required number of runs that must be executed with fitness value (zero) is unknown. Related works
Many researchers attempted to establish traceability link via information retrieval (IR) approach. IR-based approaches assume that all software artifacts are in textual format. Then, they compute textual similarity between two software artifacts using cosine similarity, e.g., a class and a requirement. The three IR methods which commonly used in traceability generation are probabilistic method (PM), vector space method (VSM) and LSI [ANT 02].
Marcus et al. [MAR 03] used LSI to establish traceability links between source code files and manual sections. A set of experiments was conducted and experimental results proved that LSI performs at least as well as Antoniol’s methods using PM and VSM with low processing of source code and documentation.
Ghanam et al. [GHA 10] assumed that there are traceability links between FM and source code for a given system and as systems evolve, the traceability links become broken or outdated so this work presented an approach to keep the already existing traceability links up to date by using executable acceptance tests (EAT). EAT refers to English-like specifications (such as: scenario tests and story tests) that represents
12
the specifications of a given feature and can be executed against the system to test the correctness of its behaviour.
Ziadi et al. [ZIA 12] proposed an approach to automate feature identification from the source code of similar products variants. This approach assumes that product variants use the same vocabulary to name packages, classes, attributes and methods; it treats the source code as a set of construction primitives and then applies an algorithm to identify features. However this approach cannot identify the separated mandatory features because it gathers all common construction primitives for all products as a single mandatory feature.
7. Conclusions and perspectives
This paper presents GAs as a recovering traceability links method between object-oriented source code of product variants and their feature model to support conversion from traditional software development into SPL. This method establishes the traceability links by exploiting all available information in the FM.
GAs can determine approximately and sometime exactly the implementation of
each feature however 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. Also, GAs are not scalable as a recovering traceability method because 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. This reason prohibits me to consider a real case study.
As future work, we will use GAs with all information provided by FM as a
complementary part with other approach like information retrieval (IR). We will consider other variation points in the source code. We have used IR namely latent semantic indexing (LSI) to establish traceability links between source code of software product variants and their FM and this work was published. Also, we will try to use formal concept analysis (FCA) with LSI find dependency between features because FCA visualizes implicit relationships between concepts (features).
4. References [ACH 12] Acher, M., Cleve, A., Perrouin, G., Heymans, P., Vanbeneden, C., Collet, P. and
Lahire, P. “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,2012, 45-54.
[BEN 10] Benavides, D., Segura, S. and Ruiz-Cort, A. “Automated analysis of feature models 20 years later: A literature review”. Inf. Syst. 35, 6 (September 2010), 615-636.
[BEU 04] Beuche, D., Papajewski, H. Wolfgang and Preikschat, S. 2004. Variability management with feature models. Sci. Compute. Program. 53(3): 333-352.
[CLE 01] Clements, P. and Northrop, L. 2001. Software product lines: practices patterns. Addison-Wesley Longman Publishing Co., Boston, MA, USA,
13
[GHA 10] Ghanam, Y. and Maurer, F.”Linking feature models to code artifacts using executable acceptance tests”. In Proceedings of the 14th international conference on Software product lines: going beyond (SPLC'10), Jan Bosch and Jaejoon Lee (Eds.). Springer-Verlag, Berlin, Heidelberg,2010, 211-225.
[GOT 94] Gotel, O. and Finkelstein, C.”An analysis of the requirements traceability problem”. In Proceedings of 1st International Conference on Requirements Engineering (Colorado Springs, CO). IEEE Computer Society Press, Los Alamitos, CA,2004, 94–101.
[KAN 90] Kang, K., Cohen,S., Hess, J., Novak, W., and Peterson, A. 1990. Feature-Oriented Domain Analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR-21, Carnegie Mellon University.
[LIN 00] Lin, J. and Yeh, P. “Using genetic algorithms for test case generation in path testing”. In Proceedings of the 9th Asian Test Symposium (ATS '00). IEEE Computer Society, Washington, DC, USA,2000, 241-250.
[LIN 96] Lindvall, M. and Sandahl, K. 1996. “Practical implications of traceability”. Softw. Pract. Exper. 26, 10 (October 1996), 1161-1180.
[MAR 03] Marcus, A. and Maletic, J. “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,2003,125-135.
[MIT 96] Mitchell M., “An Introduction to Genetic Algorithms”, Cambridge, London: Massachusetts Institute of Technology, 1st edition, 1996.
[POH 05] Pohl,K., Böckle, G. and Linden, F.”Software Product Line Engineering: Foundations, Principles and Techniques”. Springer-Verlag New York, Inc., Secaucus, NJ, USA,2005.
[RAM 01] Ramesh, B. and Jarke, M. “Toward Reference Models for Requirements Traceability”. IEEE Trans. Softw. Eng. 27, 1 (January 2001), 58-93.
[RIE 03] Riebisch, M. 2003. “Towards a more precise definition of feature models,” in Modelling Variability for Object-Oriented Prod- uct Lines, M. Riebisch, J. O. Coplien, and D. Streitferdt, Eds. Norderstedt: BookOnDemand Publ. Co, pp. 64–76.
[SCH 06] Schobbens, P.Y, Heymans, P. and Trigaux, J.C. “Feature Diagrams: A Survey and a Formal Semantics”. In Proceedings of the 14th IEEE International Requirements Engineering Conference (RE '06). IEEE Computer Society, Washington, DC, USA,2006, 136-145.
[SPA 05] 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.
[ZIA 12] Ziadi, T., Frias, L., Silva, M. and Ziane, M. “Feature Identification from the Source Code of Product Variants. 16th European Conference on Software Maintenance and Reengineering”,2012, 417-422.
14
An approach to recover feature models fromobject-oriented source code
R. AL-Msie’deen* , A. Djamel Seriai* , M. Huchard* , C. Urtado** ,S. Vauttier** , and H. S. Eyal Salman*
* LIRMM (CNRS and Univ. Montpellier 2), Montpellier, France,** LGI2P / Ecole des Mines d’Alès, Nîmes, France
ABSTRACT. Software Product Line (SPL) is a development paradigm that targets the creation of
software system variants that belong to the same domain. Usually software system variants,
developed with clone-and-own approach, form a starting point for building SPL. To migrate
software systems which are deemed similar to a product line, it is necessary to detect the com-
mon features and variations between a set of software system variants. Reverse engineering the
feature model (FM) of an existing system is a challenging activity. FM describes the common
and variable characteristics of a product line. In recent years, a lot of work has addressed the
extraction of FM from different artefacts. Little work addressed extraction of FM from source
code. This paper proposes a general approach to extract initial FM from the object-oriented
(OO) source code of a set of software system variants in order to support the migration pro-
cess from conventional software development to software product line engineering (SPLE). We
present an approach to extract features of FM from the analysis of object-oriented source code
for a set of software product variants. This approach is based firstly on the definition of the
mapping model between object-oriented elements (OOE) and those of FM. Secondly; it uses an
identification process exploiting on the one hand Formal Concept Analysis (FCA) as a method
for clustering OOE corresponding to the implementation of features and on the other hand La-
tent Semantic Indexing (LSI) to define a similarity measure on which is based this clustering.
KEYWORDS: Software product line engineering; feature identification; feature model; source code
variation; OO source code reverse engineering; software system variants; Formal Concept
Analysis; Latent Semantic Indexing.
1re soumission à JLP 2012, le October 26, 2012.
15
2 1re soumission à JLP 2012.
1. Introduction
Several definitions of SPLs can be found in the literature; according to Clementsand Northrop [CLE 01] a SPL is "a set of software intensive systems sharing a com-mon, managed set of features that satisfy the specific needs of a particular marketsegment or mission and are developed from a common set of core assets in a pre-scribed way". A SPL is usually characterized by two sets of features: the featuresthat are shared by all products in the family, called the SPL’s commonalities, and, thefeatures that are shared by some, but not all, products in the family, called the SPL’s
variability. These two sets define the mandatory and optional parts of the SPL.
In order to provide a more subtle description of the possible combinations of op-tional features (e.g., some optional feature might exclude another and require a thirdone), SPLs are usually described with a defacto standard formalism called feature
model [ACH 12]. A feature model characterizes the whole software family. It de-fines all the valid feature sets or configurations. Each valid configuration representsa specific product (either it be an existing product or a valid product-to-be). Featuremodelling is a method for describing commonalities and variabilities in software prod-uct line. Feature model was first introduced in the Feature-Oriented Domain Analysis(FODA) method by [KAN 90].
Software product line engineering (SPLE) is the process to both model the soft-ware family (also called domain engineering) and develop a software that sticks tothe software family definition (also called application engineering) [CLE 01]. Wheninvestigating the actually practiced development methods, it appears that the need fora disciplined SPLE process appears after the development of several product variants[DUS 11]. These variants are developed using ad hoc techniques such as copy, paste,modify without explicit plan or strategy for reuse. Once released, if the products meettheir market, similar products are to be developed [JOH 09] and it becomes too com-plex to develop and maintain them and too costly without switching to SPLE.
Manual analysis of the existing products and manual feature model reverse engi-neering for the existing software family is time-consuming and error-prone, and re-quires substantial effort. Automating the reverse engineering of a feature model fromsource code would be of great help. Expected benefits are to improve product mainte-nance, ease system migration, and discover new valid configurations that may lead tothe production of new software products [CHI 90]. We use FCA and IR to get theseobjectives.
We use Formal Concept Analysis to extract commonalities and variabilities for aset of product variants. FCA is a mathematical method that provides a way to identify"meaningful groupings of objects that have common attributes"[LOE 07]. Informationretrieval (IR) has proven useful in many disciplines such as software maintenanceand evolution, image extraction, speech recognition and horizontal search engines likeGoogle. Furthermore feature location is one of the most common applications of IRin software engineering [DAV 11]. IR methods sort the documents against queriesby extracting information about the occurrences of terms within them. The extracted
16
Reverse Engineering Feature Models 3
information is used to find similarity between queries and documents. LSI assumedthat there are some implicit relationships among the words of documents that alwaysappear together even if they do not share any terms; that is to say, there are some latentsemantic structures in free text [DAV 11].
In recent years, a lot of work on reverse engineering has addressed the extraction offeature models from different artefacts[ZIA 12, RYS 11]. Few works have addressedthe problem of identification of FM from the source code of product variants [ZIA 12](see Section 7).
The main goal of our work is to recover the features from OO source code basedon FCA to extract commonalities and variations from product variants and integrateLatent Semantic Indexing (LSI) with FCA to recover the features.
The remainder of this paper is organized as follows. Section 2 shows an overviewof the approach and the variation-feature mapping model, and presents our proposedfeature model extraction process from object-oriented building elements (OBE). Sec-tion 3 discusses source code variability identification from OO source code for a setof product variants. Section 4 explains the extraction process for commonalities andvariations using FCA. Section 5 explains the extraction process for the atomic blockof variations (feature) from block of variations using LSI and FCA. Section 6 dis-cusses the implementation. Section 7 discusses related work that addressed reverseengineering feature models from different artefacts. Finally, we conclude and drawperspectives for this work in Section 8.
2. Approach Overview
In this section, we will explain the main concepts of our approach and how theseconcepts can be used to apply our approach.
2.1. Features versus object-oriented elements: the mapping model
The general objective of our approach is to extract FM which model commonand variable features of software product variants. We present in this paper the partconcerning features identifications. We rely on the following definition of the feature:"a feature is a prominent or distinctive and user-visible aspect, quality, or characteristicof a software system or systems" [KAN 90]. We consider that a feature representsan aspect valuable to the customer. It is represented by a single term. We adhere tothe classification given by [KAN 90] which distinguishes three categories of features:Functional, operational, and presentation features. To identify features we rely on themapping model between these features and object-oriented building elements (OBE)(see Fig. 1).
As there are several ways to implement the features [BEU 04], we assume that thefeatures are implemented at the programming language level. Thus, the elements ofthe source code can reflect these features. For object-oriented source code, the manda-
17
4 1re soumission à JLP 2012.
Figure 1. Variation-feature mapping model
tory features are realized by object-oriented building elements (OBE) (i.e. packages,classes, etc.) that are shared by all product variants. However, the optional features arerealized by variable elements that appear only in some variants. We consider that afeature corresponds to one and only one set (group) of OBE. This means that a featurealways has the same implementation in all products where it is present.
An optional feature is implemented by variable object-oriented building elements
(VOBE) in all products where it is present. So we define a block of variations (BV) asa set of (VOBE) which are always associated (i.e., which are always identified togetherin all the products in which they appear).
It is clear that a VOBE cannot occur in a product unless accompanied by all theVOBE that are part of the implementation of the corresponding feature. This is also thecase for VOBE that belong to interdependent features (linked via "and" or "require"constraints). Therefore, a VOBE implements an optional feature that necessarily be-longs to one and only one BV. Following our approach a BV can gather VOBE thatrepresent one or more features linked by "and" or "require" constraints. The BV arefound thanks to FCA.
The subsets of VOBE that belong to a BV and represent one and only one featureare called atomic blocks of variations (ABV). A BV is composed of set of ABVs. Todetermine its sub-parts, we rely on the clustering of the closest VOBEs consideringthe similarity measures that are related to LSI method.
The mandatory features are implemented by common object-oriented building ele-
ments (COBE) in all product variants. In the same way as for the identification of ABV,
18
Reverse Engineering Feature Models 5
Figure 2. Illustrative example.
we rely on the clustering of the closest OBE in the common block (CB) to determinethe parts of this partition. Each part will be considered as a mandatory feature.
Fig. 2 shows an example of a set of product variants (3 products). This is an abstractexample to show the main concepts that exist in the variation-feature mapping model.
2.2. Feature model extraction process
The approach that we propose is illustrated in Fig. 3. Feature model extractionprocess consists of the following steps:
Figure 3. Feature model extraction process
- OO Source code is analyzed to extract object-oriented building elements (packages,
classes, methods, attributes) for all product variants.
- Commonalities and variations are extracted for all product variants using FCA.
19
6 1re soumission à JLP 2012.
Blocks of variations are given by using FCA.
- Blocks of variations are divided into atomic blocks of variations. Each atomic block
of variations corresponds to one and only one feature. In this step, we use LSI and
FCA to identify features based on the textual similarity.
3. Identification of source code variability: OO source code analysis
Any OO source code can hold four levels of variations: package variation, classvariation, attribute variation, method variation (see Fig. 4). Package variation showsvariation on two levels: package set variation (set of packages that appear in someproducts but not all products), and package content variation (means all product vari-ants have the same packages but with different contents). Variation at the class levelcan appear in the class signature, attribute set and method set. Class signature varia-tion means that two or more classes have the same name in many packages but de-clare different relations, or different access levels. Method and attribute set variationcaptures the differences between product variants in term of provided functionalities.Attribute variation can be found in attribute declarations such as: access level, datatype, etc. Method variation can appear in the method signature (access level, returneddata type, parameter list, parameter list order and method exception) and in the bodyof the method (local variable, method invocation, access).
Figure 4. Object-oriented source code variations.
4. Commonality and variation identification using FCA
We use FCA to extract commonalities and variabilities for a set of product variants.In the concept lattice the upper concept represents all source code elements that areshared by all products (common block), while other concepts reflect variability among
20
Reverse Engineering Feature Models 7
this family (variabilities) and contain all source code variations shared by some prod-ucts but not all products (block of variations). In the formal context, products con-stitute the rows while source code elements (packages, classes, methods, attributes)constitute the columns (see Table 1).
Table 1. Part of the formal context describing text editing systems by source code
elements
Pa
cka
ge
(Na
me:
um
.lir
mm
.tex
ted
ito
r.ch
an
ged
isp
lay
sett
ing
s)
Cla
ss(N
am
e:C
rea
te,
ow
ner
:um
.lir
mm
.tex
ted
ito
r.fi
lem
an
ag
emen
t.fi
le)
Cla
ss(N
am
e:P
DF
,ow
ner
:um
.lir
mm
.tex
ted
ito
r.fi
lem
an
ag
emen
t.p
rin
t)
Cla
ss(N
am
e:V
iew
Hel
p,
ow
ner
:um
.lir
mm
.tex
ted
ito
r.v
iew
hel
p)
Cla
ss(N
am
e:S
ave,
ow
ner
:um
.lir
mm
.tex
ted
ito
r.fi
lem
an
ag
emen
t.sa
vefi
le)
Cla
ss(N
am
e:S
elec
tAll
,ow
ner
:um
.lir
mm
.tex
ted
ito
r.fi
lem
an
ag
emen
t.ed
it)
Met
ho
d(N
am
e:S
elec
tAll
,ow
ner
:Sel
ectA
ll)
Cla
ss(N
am
e:R
esiz
e,ow
ner
:um
.lir
mm
.tex
ted
ito
r.ch
an
ged
isp
lay
sett
ing
s.re
size
)
Cla
ss(N
am
e:C
lea
r,ow
ner
:um
.lir
mm
.tex
ted
ito
r.fi
lem
an
ag
emen
t.cl
ear)
Cla
ss(N
am
e:R
ead
On
ly,
ow
ner
:um
.lir
mm
.tex
ted
ito
r.fi
lem
an
ag
emen
t.re
ad
on
ly)
Cla
ss(N
am
e:U
nS
pli
t,ow
ner
:um
.lir
mm
.tex
ted
ito
r.ch
an
ged
isp
lay
sett
ing
s.u
nsp
lita
ll)
Cla
ss(N
am
e:H
ori
zon
tal,
ow
ner
:um
.lir
mm
.tex
ted
ito
r.ch
an
ged
isp
lay
sett
ing
s.sp
lit)
)
Cla
ss(N
am
e:V
erti
cal,
ow
ner
:um
.lir
mm
.tex
ted
ito
r.ch
an
ged
isp
lay
sett
ing
s.sp
lit)
Met
ho
d(N
am
e:se
tVer
tica
l,ow
ner
:Ver
tica
l)
Lo
cal
Va
ria
ble
(Na
me:
Ver
tica
l,ow
ner
:set
Ver
tica
l)
Met
ho
dIn
vo
cati
on
(Na
me:
pri
nt,
Acc
esse
d-i
n:[
Ver
tica
l],
ow
ner
:set
Ver
tica
l)
TextEditingSystem1 ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
TextEditingSystem2 ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
TextEditingSystem3 ! ! ! ! ! ! ! ! ! ! ! ! ! !
TextEditingSystem4 ! ! ! ! !
TextEditingSystem5 ! ! ! ! ! ! !
TextEditingSystem6 ! ! ! ! ! ! ! ! ! ! ! !
TextEditingSystem7 ! ! ! ! ! ! ! ! !
TextEditingSystem8 ! ! ! ! ! ! ! ! ! ! ! !
The concept lattice is presented in Fig. 5. The common block contains all thesource code elements that implement mandatory features. The source code elementsthat are shared by more than one product are called a block of variations. A Block ofvariations contains source code elements that appeared every times together to imple-ment a set of features for some product.
5. Atomic block of variations (feature) identification using LSI and FCA
To identify the atomic block of variations that represent a single feature from ablock of variations, we consider LSI and FCA to recover all atomic block of variations.In our case, each line in the block of variations represents a single document and atthe same time represents a query.
21
8 1re soumission à JLP 2012.
Figure 5. The concept lattice for the formal context of Table 1
Most of the existing tools about FCA are referenced from the web page of UtaPriss 1. For this paper, we used the eclipse eRCA platform 2 and Concept Explorer 3.
All information in the block of variations must be manipulated and normalized tobecome suitable as input of LSI. This preprocessing step includes: all capital lettersmust be transformed into lower case letters, removing stop-words (such as articles,punctuation marks, numbers, etc.), all lines must be split into terms and performingword stemming.
Similarity between lines is described by a similarity matrix. In the similarity matrixcolumns represent lines vectors and rows represent lines vectors also. LSI uses eachline in the block of variations as a query to retrieve all lines that have similarity with it,according to cosine similarity. In our work, we consider the most widely used thresh-old for cosine similarity that is equals to 0.70 [DAV 11]. We use the similarity matrix(see Table 2) (LSI result) as input for the FCA to group the similar elements togetherbased on the lexical similarity; after that, we ignore any document that has similaritywith itself only (see Table 4). Table 3 shows the formal context of the similarity matrix(threshold for cosine similarity equals to 0.70). So we take the interchanged contextas input for FCA; FCA identifies the meaningful groupings of objects that have com-mon attributes. In our case, the concept lattice (see Fig. 6) shows two atomic block
1.2.3.
22
Reverse Engineering Feature Models 9
of variations. Each atomic block represents one and only one feature. Note that eachdocument (Doc
!i) represents a line from a block of variations.
Table 2. The similarity matrix (SimMat).Doc 1 Doc 2 Doc 3 Doc 4 Doc 5 Doc 6 Doc 7 Doc 8
Doc 1 1 0.70 0 0 0 0.70 0 0Doc 2 0.70 1 0 0 0 0.70 0 0Doc 3 0 0 1 0 0 0 0 0Doc 4 0 0 0 1 0.70 0 0 0Doc 5 0 0 0 0.70 1 0 0 0Doc 6 0.70 0.70 0 0 0 1 0 0Doc 7 0.70 0.70 0 0 0 0.70 1 0Doc 8 0.70 0.70 0 0 0 0.70 0 1
Table 3. The context (SimMat) for != 0.70.Doc 1 Doc 2 Doc 3 Doc 4 Doc 5 Doc 6 Doc 7 Doc 8
Doc 1 x x xDoc 2 x x xDoc 3 xDoc 4 x xDoc 5 x xDoc 6 x x xDoc 7 x x x xDoc 8 x x x x
Table 4. The interchanged (SimMat) context.Doc 1 Doc 2 Doc 6 Doc 4 Doc 5
Doc 1 x x xDoc 2 x x xDoc 4 x xDoc 5 x xDoc 6 x x xDoc 7 x x xDoc 8 x x x
6. Approach implementation
To validate our approach, we used a text editing software product line 4 as a casestudy. A text editor is a computer program that lets a user enter, change, store, and usu-ally print text, and provide the basic operations that satisfy the end user. This familyhas eight product variants. Each product implements a simple text editing application.Features are collected in what it is called a FM to specify the variations between theseproducts. The feature model of the text editing system is shown in Fig. 7; the featureswith white circles on top are optional features while all features with black circles ontop are mandatory features. Fig. 5 shows small part of the concept lattice for theseproducts. We extract the common block that contains all common (mandatory) fea-tures, and a set of blocks of variations that contain source code elements for optional
4.
23
10 1re soumission à JLP 2012.
Figure 6. The concept lattice for the formal context of Table 4.
Figure 7. Text editing system FM.
features. Each block of variations has at least one atomic block of variations that rep-resents a single optional feature. In the text editing system, the concept lattice showsthat unsplit, split horizontal, and split vertical features all times appear together in thesame block of variations. After applying LSI with FCA on this block we recover threeatomic blocks of variations (each one represent a single feature) based on the textualsimilarity. Concept lattice (see Fig. 8) shows the recovered features from this block.
7. Related work
Ziadi et al. [ZIA 12] propose an automatic approach for feature identification fromsource code for a set of product variants. Their approach only investigates productsin 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 inthe body of methods. The recovered feature model contains only one mandatory fea-ture, and optional features. The extracted feature model has only one level of hierar-chy, without distinction between the mandatory features, without any feature groupand group constraints, and without cross tree constraints. We use FCA to extract com-monalities and variations from product variants and distinguish between the manda-tory features by using LSI and FCA based on the lexical similarity, and extracts alloptional features and constraints such as: "and" and "require".
24
Reverse Engineering Feature Models 11
Figure 8. Concept lattice shows three atomic blocks of variations extracted from one
block of variations.
Ryssel et al. [RYS 11] propose an approach to extract feature diagrams using FCAfrom an incidence matrix that contains matching relation as input. It shows the partsof a set of function- block oriented models that describe different controllers of aDC motor. They introduce an automatic approach to recognize variants in a set ofmodels and identify the variation points and their dependencies within variants. Inour approach the incidence matrix contains source code elements for a set of productvariants, and we use FCA to extract commonalities and variations for these productvariants.
Our approach focuses on recovering an initial feature model from a set of productvariants to support the migration process from conventional software development tosoftware product line engineering.
8. Conclusion
In this paper, we proposed an approach based on FCA and LSI to extract a featuremodel from the object-oriented source code of software system variants. FCA can beused to extract variations blocks. Then LSI is used with FCA to recover atomic blocksof variations that represent a single feature, using the textual similarity.
25
12 1re soumission à JLP 2012.
As future work, we will apply a clustering algorithm on the commonality andvariability blocks to determine more precisely each feature implementation based onboth textual and semantic similarity. For the semantic similarity, we rely on all avail-able information and links that exists between variable object-oriented building ele-ments such as: inheritance (which class inherits from which class), invocations (whichmethod invokes which method). Also we will try to organize the extracted features asa feature model including all cross-tree constraints, using information contained in theconcept lattice.
9. References
[ACH 12] ACHER M., HEYMANS P., MICHEL R., “Next-generation model-based variabilitymanagement: languages and tools”, Proceedings of the 16th International Software Product
Line Conference, vol. 2 of SPLC ’12, New York, NY, USA, 2012, ACM, p. 276–277.
[BEU 04] BEUCHE D., PAPAJEWSKI H., SCHRÖDER-PREIKSCHAT W., “Variability manage-ment with feature models”, Sci. Comput. Program., vol. 53, num. 3, 2004, p. 333–352,Elsevier North-Holland, Inc.
[CHI 90] CHIKOFSKY E. J., CROSS II J. H., “Reverse Engineering and Design Recovery: ATaxonomy”, IEEE Software, vol. 7, num. 1, 1990, p. 13–17, IEEE.
[CLE 01] CLEMENTS P. C., NORTHROP L. M., Software product lines: practices and pat-
terns, Addison-Wesley, 2001.
[DAV 11] DAVID B., LAWRIE D., “Information Retrieval Applications in Software Mainte-nance and Evolution”, In Encyclopedia of Software Engineering, 2011, p. 454-463.
[DUS 11] DUSZYNSKI S., KNODEL J., BECKER M., “Analyzing the Source Code of MultipleSoftware Variants for Reuse Potential”, p. 303-307, IEEE Computer Society, Los Alamitos,CA, USA, 2011.
[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, CarnegieMellon University, p. 31–40.
[KAN 90] KANG K. C., COHEN S. G., HESS J. A., NOVAK W. E., PETERSON A. S.,“Feature-Oriented Domain Analysis (FODA) Feasibility Study”, November 1990.
[LOE 07] LOESCH F., PLOEDEREDER E., “Restructuring Variability in Software ProductLines using Concept Analysis of Product Configurations”, KRIKHAAR R. L. VER-HOEF 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.
[RYS 11] RYSSEL U., PLOENNIGS J., KABITZSCH K., “Extraction of feature models fromformal contexts”, Proceedings of the 15th International Software Product Line Conference,
Volume 2, Munich, Germany, 2011, ACM, p. 4:1–4:8.
[ZIA 12] ZIADI T., FRIAS L., DA SILVA M. A. A., ZIANE M., “Feature Identification fromthe 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.
26
Modelling Variability Using CVL:A Step-By-Step Tutorial
Jérôme Le Noir *** — Olivier Barais ** — Joao Bosco Ferreira Filho* — Mathieu Acher ** — Jean-Marc Jézéquel **
* INRIA
Campus universitaire de Beaulieu35042 Rennes cedex, France
** IRISA, Université Rennes 1
Campus universitaire de Beaulieu35042 Rennes cedex, France
{barais, macher, jezequel}@irisa.fr
*** Thales Research and Technology
Campus de Polytechnique
1 avenue Augustin Fresnel
91767 Palaiseau Cedex, [email protected]
ABSTRACT. The Common Variability Language (CVL) provides a well-structured mechanism to
express and relate variability to any MOF-compliant model. Using variation points, it is pos-
sible to express and manipulate the links between a variability abstraction model and a base
model. CVL also allows users to define the materialization of a given CVL resolution/configu-
ration. The goal of this short tutorial is to present the outcome of the work done for CVL issued
by the Object Management Group. The tutorial will give an overview of the CVL language and
preliminary tooling done by Thales and the INRIA Triskell team for CVL. In particular, we will
focus on the extensibility of the CVL tooling. Indeed, the meaning of a given variation point
can vary according to the semantics of each base model. For example, a variation point that
excludes an element in the base model can lead to further operations, like excluding other ele-
ments which were associated to the deleted element, or even to reassign references to another
model element. Therefore, it is necessary to address this semantic variability in order to align
the materialization semantics to the base model semantics. The last part of this tutorial will
show how Kermeta or Scala can be used to easily implement and customize the semantics of
the CVL’s variation points, according to the semantics of the base model. The audience for this
tutorial can be experienced product line (PL) engineers as well as beginners in the field of PL
engineering. It will be an advantage if the participant has some experience in modeling (e.g.
with SysML or UML) but this is not a strict requirement.
KEYWORDS: Variability Modelling, CVL, Language, Tutorial, Kermeta, Tools
27
1. Topic and Goal of the Tutorial
In many domains, software organisations produce and maintain multiple similarsoftware products (variants), exploiting their common properties and managing whatvaries among them. The paradigm of Software Product Line (SPL) engineering hasemerged and aims at providing processes, tool-supported techniques and languagesto support their development. The complexity induced by the variability of software-intensive products raises new challenges for practitioners and researchers.
To abstract from complexity, a traditional yet critical task in SPL engineering is tomodel variability. Numerous approaches for variability modeling have been proposed(e.g., see [POH 05, PER 08, HEI 10, CZA 05, ACH 12a, APE 09, CLA 10, CZA 06,ZIA 06, VOE 07]) and are evolving towards comprehensively supporting the SPL life-cycle – not only the domain modeling.
The Common Variability Language (CVL) has emerged as an effort to standardizeand promote variability modeling. CVL has just been submitted to OMG for evalua-tion 1. The overall objective of this tutorial is to provide the fundamentals of CVL formodelling variability. In particular, the goals are:
– To show how this fully generic language can be used through simple examples ;
– To present the CVL language as it is now specified ;
– To explain the CVL language semantics and illustrate how it can be extended ;
– To solicit feedback from tutorial participants on the CVL in order to make theCVL even more suitable for the SPL community ;
– To present an EMF-based implementation based on the CVL specification pro-vided by Thales and INRIA that encourages pluggable implementations of tools basedon the CVL specification.
2. Content of the Tutorial
In this section, we give an overview of the tutorial content that will be used toachieve the goals presented above. We first present some basics of CVL. Then wejustify why it is necessary to customize the semantics of these variation points and wepresent two different mechanisms. Finally we discuss two additional CVL extensionswe recently introduced in our workbench.
2.1. CVL in a Nutshell
CVL is a domain-independent language for specifying and resolving variabilityover any instance of any MOF-compliant metamodel. CVL has a Variability Abstrac-tion Model (VAM), which is the part of CVL in charge of expressing the variability
1. The submitters of the CVL Revised Submission have decided to publicize the proposalopenly, and you may find it at http://variabilitymodeling.org on the home pageunder the News. Note that no decisions have been taken regarding CVL by the OMG, yet.
28
Semantic 1 Semantic 2 Customized Semantics
Base Model
yes!yes!
no!VSpecResolutions VSpecs
Variation Points
CVL Model
Figure 1: Overview of CVL
in terms of a tree-based structure (roughly, VAM can be seen as a feature model or adecision model).
The core concepts of the VAM are the variability specifications (VSpecs). TheVSpecs are nodes of the VAM and can be divided into three kinds: Choices, Variablesand Classifiers. Each kind of VSpec has its own type of resolution (VSpecResolutions).The Choices are VSpecs that can be resolved to yes or no (through ChoiceResolution),Variables are VSpecs that require a value for being resolved (VariableValue) and Clas-sifiers are VSpecs that imply the creation of instances and then providing per-instanceresolutions (VInstances). In this paper, we mainly use the Choices VSpecs, which canbe intuitively compared to features and can or cannot be selected during the productderivation (yes/no decision).
Besides the VAM, CVL also contains a Variability Realization Model (VRM). Thismodel makes possible to specify the changes in the base model implied by the VSpec
resolutions. These changes are expressed as variation points in the VRM. Variationpoints can mainly express three different types of semantics, which are following de-scribed.Existence. This type of variation point expresses whether an object (ObjectExistencevariation point) or a link (LinkExistence variation point) exists or not in the material-ized model.Substitution. This type of variation point expresses a substitution of a model objectby another (ObjectSubstitution variation point) or of a fragment of the model by an-other (FragmentSubstitution)Value Assignment. This type of variation point expresses that a given value is as-
signed to a given slot in a base model element (SlotAssignment variation point) or agiven link is assigned to an object (LinkAssignment variation point).
2.2. Customizing the Semantics for Your Domain Metamodel
Why semantics matter in the context of CVL
Using variation points leads to express and manipulate the links between the vari-ability abstraction model and the base model. However, the meaning of a given vari-ation point can vary according to the semantics of each domain. For example, a vari-ation point that excludes an element in the base model can lead to further operations,like excluding other elements which were associated to the deleted element, or even toreassign references to another model element. Then, considering the negative deriva-tion context, the ObjectExistence will exclude the binding model element if the relatedfeature is not selected. However, this semantics can vary according to the semanticsof the base-model domain. Excluding a class of a class diagram may not influence inthe existence of the classes related to it, on the other hand, excluding an activity ofan activity diagram may lead to break an activity flow. Therefore, it is necessary toaddress this semantic variability in order to align the materialization semantics to thebase model semantics.
Principles
CVL proposes a set of VP with a well-defined semantics and keeps one as an ex-tension point to implement its own semantics: Opaque Variation Point (OVP). TheOVP is a black box that can define an arbitrary behavior to execute during deriva-tion. This behavior is defined by using an expression defined in an action language.We currently propose an implementation that supports OVP definition in Groovy 2,JavaScript, Scala or in Kermeta. With these action languages, designers can modifythe base model directly.
The use of OVPs can be seen as a mechanism to propose a particular semanticfor the derivation engine. Besides the OVP, following our current CVL workbenchpropose two other mechanisms to customize the semantics of CVL. The first one is thestatic introduction of a new semantics and the second one is using the strategy pattern.In the two following paragraphs, we give some details about the two mechanisms.(These extension mechanisms are also presented in depth in [BOS 12].)
Static introduction of a new semantics in Kermeta
By using the built-in composition mechanisms of Kermeta, it is possible to stat-ically customize the semantics of a CVL variation point. Indeed, require provides alinearisation mechanism to weave aspect in an existing metamodel. It allows a DSLengineer to reopen a previously created metaclass to add new pieces of informationsuch as new methods, new properties or new constraints. It also allows engineers to
2. http://groovy.codehaus.org/
30
easily replace the behaviour of an existing method. Indeed, the operational semanticsweaved into CVL for building the derivation engine can be changed by requiring anew Kermeta file. This modification is static, modifying the types and requiring torecompile all the CVL’s Kermeta implementation.
This extension mechanism has two main drawbacks. First, Kermeta does not allowthe new implementation to call the previous aspect implementation, contrarily as wecan call the code of an operation contained in the super-class with the keyword super.Secondly, using this mechanism, the DSL engineer can change (and potentially break)completely the CVL implementation. Kermeta does not provide any checker to ensurethat a new implementation is a refinement of the previous implementation. The mainadvantages is the fact that the extension is modular and can be statically plugged orunplugged.
Strategy pattern
The basic semantics used in the default CVL implementation is the following.Each variation point can modify the model to change relationships between modelelements and can introduce new model elements. To remove a model element, eachvariation point acts on a context that contains a list toRemove of the model elementsthat must be removed. Removing elements of a base model is performed at the endof the derivation to avoid side-effects among variation points. With this behaviour,CVL combines positive variability and negative variability. The default semantics forthis remove implementation is the following. Each element contained (containmentrelationship) by an element that must be removed is also removed. All the referencesof an element that must be removed are set to null. All the elements, that referencean object that must be removed through a reference with a violation of the lower car-dinality are also removed, e.g. if a : A references b : B and A is associated exactlywith one B, if b is removed, a is also removed. This can already be seen as a semanticcustomization as it has an additional load of operations that must be performed for agiven variation point. Consequently, we introduce in the default semantics a strategypattern [GAM 94] to provide the ability of dynamically specializing the default se-mantics. The idea is that a domain expert can define a new CVL semantic extensionand can register it. During the derivation, when a model element has to be removed,all the registered extensions are called to determine the list of model elements to beremoved.
This extension mechanism provides several benefits. Firstly, it ensures that the de-fault semantics of the CVL variation point is respected. Indeed, domain engineers canonly refine the semantics in removing elements, and not directly in the variation point.It can be compared to the idea of post directives in Kompose [FLE 08]. Secondly, newstrategies can be registered or unregistered dynamically. Finally, each specializationcan be modularized in a distinct building block.
31
2.3. Extending the Relationship Between the Choice Models and the VariabilityRealization Model
In addition to the two mechanisms previously described to customize the semanticsof CVL, two other extensions have been introduced into the CVL language to improveits expressiveness.
The first one is a mapping language between the choices and the variation points.The goal is to propose complex mappings between choice models and variation points.By default, each variation point is linked to a set of choices. This variation points canbe executed if the bounded choices are set to true. This logical mapping can de-clare many to many relationships with logical expressions between choices and vari-ation points. An SPL designer can declare a mapping like "HasChoice myChoice1 or
HasChoice myChoice2 where myChoice1.valueassignement1 > 5" in the same vein asFeature Mapper [HEI 08, HEI 10].
The second extension introduces a partialExecutionOrder reference in the Varia-tion Point to declare a constraint on the execution order between two Variation Point.By default, the Variation Point execution order should not have any impact on theresulting product. However, in the case of Opaque Variation Point, an SPL designercan declare side-effect operations that can be influenced by the execution order. Thisnew relationship between the Variation Points provide a simple way to constrain thederivation control flow.
2.4. Ongoing Work
We are currently working to provide a customization of CVL for Software ProcessModelling Language [ROU 12]. We also plan to integrate management operations forCVL configuration unit inspired by FAMILIAR’s operators [ACH 13, ACH 12b].
3. Plan
The CVL language will be presented through intuitive examples using a model-based tooling environment built on top of EMF and Obeo designer. This tutorial willbe organized into four parts:
– Overview presentation (25 minutes) This part gives an overview presentationof the context of system engineering and variability modelling at Thales and illustratethe expected benefits in using CVL. We will come back on the main models availablein CVL (choice model, variability realization model, base model, resolution model) tocapture the variability and drive the product derivation.
– CVL editor workbench architecture (10 mn) This part will briefly present thetooling architecture and how it can be customized for a specific domain.
– CVL editor workbench (10 mn) On this part of the tutorial we will presentthe workbench we provide for building CVL model, creating reusable piece of CVLmodel, modelling the resolution and derive a set of products.
32
– Conclusion, discussions and feedbacks on CVL (15 mn) The last sequencewill solicit feedback from tutorial participants on the CVL in order to make the CVLeven more suitable for the SPL community.
Duration
The estimated length of the tutorial is typically one hour. However, the durationcould be reduced if necessary, for example, by focusing less on customization mech-anisms (see Section 2.2).
4. Background
4.1. Presenter’s Background
Jérôme Le Noir is a senior expert in model-driven engineering and service-orientedarchitecture. He has a Computer Science degree. His background mixes applied re-search, MDE tool development as well as software consulting and service activitiesin industry. As a research engineer at TRT / Software Research Group since 2002,he has been realising applied research in model-driven engineering tool integration inthe context of the Modelware and Modelplex project. Since 2009, he leads ThalesResearch & Technology activities related to model driven engineering enabling tech-nologies and his main research interests focus on MDE and more precisely, the multi-viewpoint approach and variability modelling. He is the Thales representative for theongoing Object Management Group standard called Common Variability Language.
4.2. Audience
Both academics and practitioners can benefit from the tutorial. They can be expe-rienced SPL engineers as well as beginners in the field of SPL (e.g., master or PhDstudents). The participant can have some experience in modeling (e.g. with SysMLor UML) but this is not a strict requirement. The presentation is also of interest forbuilders of modelling and analysis tools who would like to support or to know CVL.
Acknowledgments. This work is funded by the VaryMDE project (http://varymde.gforge.inria.fr/). VaryMDE is a bilateral collaboration between the Triskellteam at INRIA and the MDE lab at Thales Research & Technology.
5. References
[ACH 12a] ACHER M., COLLET P., GAIGNARD A., LAHIRE P., MONTAGNAT J., FRANCE
R. B., “Composing multiple variability artifacts to assemble coherent workflows”, Software
Quality Journal, vol. 20, num. 3-4, 2012, p. 689-734.
[ACH 12b] ACHER M., COLLET P., LAHIRE P., FRANCE R., “Separation of Concerns inFeature Modeling: Support and Applications”, Proceedings of the 11th International con-
ference on Aspect-Oriented Software Development (AOSD 2012), ACM, 2012, p. 1–12.
33
[ACH 13] ACHER M., COLLET P., LAHIRE P., FRANCE R., “FAMILIAR: A Domain-SpecificLanguage for Large Scale Management of Feature Models”, Science of Computer Program-
ming (SCP) – Special issue on programming languages (to appear), , 2013.
[APE 09] APEL S., KÄSTNER C., “An Overview of Feature-Oriented Software Develop-ment”, Journal of Object Technology (JOT), vol. 8, num. 5, 2009, p. 49–84.
[BOS 12] AO BOSCO FERREIRA FILHO J., BARAIS O., NOIR J. L., JEZEQUEL J.-M.,“Customizing the Common Variability Language Semantics for your Domain Models”,VARY’12, Innsbruck, Austria, 2012, IT University of Copenhagen.
[CLA 10] CLASSEN A., HEYMANS P., SCHOBBENS P.-Y., LEGAY A., RASKIN J.-F.,“Model checking lots of systems: efficient verification of temporal properties in softwareproduct lines”, ICSE’10, ACM, 2010, p. 335-344.
[CZA 05] CZARNECKI K., ANTKIEWICZ M., “Mapping Features to Models: A TemplateApproach Based on Superimposed Variants”, GPCE’05, vol. 3676 of LNCS, 2005, p. 422–437.
[CZA 06] CZARNECKI K., PIETROSZEK K., “Verifying feature-based model templatesagainst well-formedness OCL constraints”, GPCE’06, ACM, 2006, p. 211–220.
[FLE 08] FLEUREY F., BAUDRY B., FRANCE R., GHOSH S., “Models in Software Engineer-ing”, chapter A Generic Approach for Automatic Model Composition, p. 7–15, Springer-Verlag, Berlin, Heidelberg, 2008.
[GAM 94] GAMMA E., HELM R., JOHNSON R., VLISSIDES J. M., Design Patterns: Ele-
ments of Reusable Object-Oriented Software, Addison-Wesley Professional, 1994.
[HEI 08] HEIDENREICH F., KOPCSEK J., WENDE C., “FeatureMapper: Mapping Featuresto Models”, Companion Proceedings of the 30th International Conference on Software
Engineering (ICSE’08), New York, NY, USA, May 2008, ACM, p. 943–944.
[HEI 10] HEIDENREICH F., SANCHEZ P., SANTOS J., ZSCHALER S., ALFEREZ M., ARAUJO
J., FUENTES L., AMD ANA MOREIRA U. K., RASHID A., “Relating Feature Models toOther Models of a Software Product Line: A Comparative Study of FeatureMapper andVML*”, Transactions on Aspect-Oriented Software Development VII, Special Issue on A
Common Case Study for Aspect-Oriented Modeling, vol. 6210, 2010, p. 69–114, Springer.
[PER 08] PERROUIN G., KLEIN J., GUELFI N., JÉZÉQUEL J.-M., “Reconciling Automationand Flexibility in Product Derivation”, 12th International Software Product Line Confer-
ence (SPLC 2008), Limerick, Ireland, Sep. 2008, IEEE Computer Society, p. 339–348.
[POH 05] POHL K., BÖCKLE G., VAN DER LINDEN F., Eds., Software Product Line En-
gineering: Foundations, Principles and Techniques, Springer,Heidelberg, 2005.
[ROU 12] ROUILLÉ E., COMBEMALE B., BARAIS O., JEZEQUEL J.-M., TOUZET D.,“Leveraging CVL to Manage Variability in Software Process Lines”, APSEC, IEEE, 2012,To appear.
[VOE 07] VOELTER M., GROHER I., “Product Line Implementation using Aspect-Orientedand Model-Driven Software Development”, SPLC ’07: Proceedings of the 11th Interna-
tional Software Product Line Conference, Washington, DC, USA, 2007, IEEE ComputerSociety, p. 233–242.
[ZIA 06] ZIADI T., JÉZÉQUEL J.-M., “Software Product Line Engineering with the UML:Deriving Products”, KÄKÖLÄ T., DUEÑAS J. C., Eds., Software Product Lines, p. 557-588, Springer, 2006.
34
Relationships in Variability Modeling Approaches
A Survey and Classification
Stephen Creff — Joël Champeau
Lab-STICC, ENSTA Bretagne2, Rue F. Verny29806 Brest Cedex 9, FranceUEB, Brest, France
{stephen.creff,joel.champeau}@ensta-bretagne.fr
ABSTRACT. The Product Line Engineering (PLE) promotes reuse as intent to face new system de-velopment constraints like: increasing product quality, time-to-market enhancement, and pro-duction costs reduction. The modeling and management of variability and commonalities iscentral to the PLE and several techniques have been defined to cope with this issue. Modular-ization and Separation of Concerns (SoC) have been used as an effective solution to tackle thegrowing complexity of product lines. However, neither consensus about relational informationexpression, nor categories of relationships, has been defined. In this paper, we propose to con-sider the existing variability modeling approaches from the Domain Engineering and provide asurvey of the ones concerned with the explicit management of relationships. These approachesare classified by variability techniques and concerns to reveal categories of relationship. Aclosing discussion highlights some observations on the survey to reveal research perspectives.
RÉSUMÉ. L’Ingénierie des Lignes de Produits (ILdP) promeut la réutilisation pour faire face auxcontraintes de développement toujours plus fortes des systèmes, de qualité, de fiabilité et detemps de réalisation. La modélisation et la gestion de la variabilité est un point clé de l’ILdP, etde nombreuses techniques ont vues le jour. Modularité et séparation des préoccupations ont étémis en œuvre pour répondre à la complexité croissante du développement des LdPs. Cependant,il n’existe pas de consensus sur la manière de présenter l’information relationnelle, ni d’établirdes catégories de relations. Dans cet article, nous considérons les approches de modélisationde la variabilité existantes de l’Ingénierie du Domaine, et proposons une étude comparative desdifférentes approches proposant une gestion explicite des relations. Ces approches sont classéespar type de techniques de variabilité et préoccupations pour révéler des catégories de relations.Pour terminer, une discussion met en évidence les points clés de cette étude.
KEYWORDS: PLE, Variability Modeling Approaches, Relationships, Survey, Categories.
MOTS-CLÉS : ILdP, Approches de Modélisation de la Variabilité, Relations, Étude comparative.
35
2 JLdP. Volume 1 - n! JLdP/2012
1. Introduction
Product Line Engineering (PLE) [CLE 01] has emerged as a viable paradigm toaddress the following issues: increasing product quality, time-to-market enhancement,and production costs reduction. The basic philosophy of Product Lines (PLs) empha-sizes intra-organizational reuse through the explicitly planned exploitation of similar-ities among related products (core development assets [POH 05]). The explicit mod-eling and management of the variability and the commonality is a key point in PLE.Several techniques, and thus Domain Specific Languages (DSLs), have been definedto explicitly model the variability. Some classifications separate amalgamated tech-niques, e.g. [MOR 09] from separated techniques, e.g. [KAN 90, POH 05, HEI 08](the most popular being the Feature Model - FM [KAN 90]). Part of the latter is de-fined as orthogonal approaches, dealing with the variability as a separated viewpointconnected to core assets in order to automate the product derivation.
The variability models describe abstractions from core modeling artifacts relatedthrough variability mechanisms, and the relational information between these core ar-tifacts is sometimes represented into the variability modeling viewpoint. Moreover,efforts have been made to refine variability and separate concerns, even though some-times lacking some formalization in relating manipulated artifacts. The FORM method[KAN 98] reveals categories of features organized into layers (viz. “operating environ-ments”, “capabilities”, “domain technology” and “implementation techniques”). An-other approach from Bailin [BAI 93] distinguishes between some features being: op-erational, of the interfaces, functional, of performances, methodological, from the de-sign and the implementation. Riebisch [RIE 03] suggests categorizing into functional,interface and parameter features. Besides, the modularization issue has been pointedout by many authors, e.g. [REI 07, MET 07, BOT 08, HAR 09]. Griss et al. [GRI 98]introduce different views on feature models. Some authors, like [BOT 08], focus onvisual representation of complex FMs, including hierarchy possibilities and interre-lations. Furthermore, several authors focus on classifications for variability. Pohl etal. [POH 05] distinguish internal from external variability but do not provide anyinsight on relations between them. Metzger et al. [MET 07] make the distinction be-tween product line variability and software variability in separate models.
Modularization and Separation of Concerns (SoC) have been used as an effectivesolution to tackle the growing complexity of products and to enhance the understand-ability of software product line developments. It is interesting to notice that, despitethe fact that several efforts have been provided in variability modeling about the sep-aration of concerns and relations of variants, no consensus about relations and eventhough categories have been defined, and no survey of existing approaches have beenprovided. Several other surveys and classification studies addressing the PL variabilityhave been proposed, but they do not focus on relationships between concerns.
In this article, we propose a survey of the variability modeling approaches in theliterature that handle explicit relationships between variable elements. The presenceof explicit relationships in many existing approaches emphasizes their need. Theseselected approaches are classified by variability techniques and concerns and chrono-logical order of publication. In this context, it is important to address the following
36
Survey of Relationships in Variability Modeling Approaches 3
questions: RQ1. What are these relationships? RQ2. What concerns are they relating?RQ3. What is the degree of formality? The survey addresses these questions, and aclosing discussion highlights some categories of usage concerns and observations, andprovides motivations for future works. The classification provides a better understand-ing of the introduction of each relationship (rationales) and reveals some drawbacksand needs.
The remainder of this paper is organized as follows. In the second part, we give anoverview of the survey method. In the third section, we provide a classified list of thesurveyed approaches and for each one, a brief description. In the fourth section, wesynthesize the answers of the research questions and provide some observations. Thelast section draws our conclusion and narrows future work.
2. Survey Method
Variability modeling approaches in the literature that handle explicit relationshipsbetween variable elements are numerous and relate to distinct techniques. To build thesurvey, the research method followed the description briefly introduced in this section.
Research Questions:The survey addresses three questions, that are concerned with defining the what,
underlying the why (why separating concerns and relating them), and the how (howare these relationships implemented).
– RQ1. What are these relationships? The approaches make explicit the rela-tionships and give them a name.
– RQ2. What concerns are they relating? The concerns can be related to thecore assets artifacts, can concern the variability, or may concern various models.
– RQ3. What is the degree of formality? The relationships can be describedtextually, in a metamodel or with any mathematical language, defining variouslevel of precision in the description.
Survey Protocol:The survey protocol is divided into the classical following sequential steps:
– Defining of the material base: an online research of relevant paper was per-formed using Google and the libraries ACM Digital Library, SpringerLink,IEEE explore and Science Direct. The initial filtering is based on keywordsto search for relations, relationships, dependencies in product line or family ap-proaches, for feature or variability modeling approaches (using wild card andboolean operators).
– A filtering process: papers are manually reviewed to evaluate their relevance.Many papers were rejected as the keyword relation is quite common and vague.Then, papers that refer to relationships in an other technological space are leavedout the survey, e.g. propositional formulae, constraint programming. Due tospace limitation, Decision Modeling languages are kept out of this study. Inaddition, papers from the same authors extending on a non relationship related
37
4 JLdP. Volume 1 - n! JLdP/2012
concern a previous paper are eliminated, as well as paper from other authorsreferring explicitly to another previous work without enhancing it (adding rela-tionships or any kind of formalization or precision in the description), otherwisethe latter paper is preserved.
– A content analysis of the resulting material: each paper is analyzed to answerthe three research questions.
Survey Material:The survey covers papers published in workshops, conferences, journals, books
and technical reports from 1990 to 2011, with 27% of the papers published in 2008-2009, corresponding to the same period when many studies have been performed onFM consistency checking and regarding solvers. The table 1 provides a distribution ofthe papers by type of publication.
Table 1. Distribution of the papers.Conference, Journal or Report # PapersBooks 2Technical reports 2Journals 6Conferences (GPCE, ECMR, SPLC, ECBS, ICSR, SERP,VaMoS, RE, MoDELS, Net.ObjectDays, ICCET, SDL)
23 (SPLC - 10)
Worskhops (SPLC, ICSE, PFE, ECOOP) 4
The 37 selected papers are classified following the given categories: the model-ing technique relates to feature, or to other variability techniques; the feature case isrefined whether the approach relates specifically to intra-model relationships (depen-dencies, to visualization concerns), or to inter-model ones (relation between variabilitymodels and core artifacts, or variability modularization).
3. Classification of Variability Techniques Introducing Relationships
The classification is build upon the notions of metamodels and models. We distin-guish first approaches from different metamodels (FM and others), then at model level,a refinement is made with the intra and inter model criteria. The following descriptionspresent significant relationships from the selected approaches.
3.1. Relationships in Feature Modeling
Relationships are defined within FMs or relating them to other modeling artifacts.
3.1.1. Within a Single Feature Model
In the original FM, the FODA method [KAN 90] introduces the hierarchical consist-of relation and two composition rules (requires and mutex-with). Griss et al. [GRI 98]
38
Survey of Relationships in Variability Modeling Approaches 5
keep the same relations when adapting the method to RSEB.In the FORM methodology [KAN 98], the authors propose several categories of
features combined through aggregation, generalization/specialization and implemented-by relationships (between features from different layers), even though lacking someformalism. Logical operators and dependencies (requires and excludes - which isequivalent to the previous mutex-with) help structure the FM.
Czarnecki and Eisenecker [CZA 00] suggest the use of “vertical” dependency rulesbetween high level and low level features to deal with different FMs for different prod-uct types. In the approach, relationships between a feature and its subfeatures don’thave any predefined semantics(fully determined by the sub-features semantics).
Fey et al. [FEY 02] introduce a metamodel for FMs which focus on inter-featurerelations. Three different planes (or views) are defined to enhance the variability repre-sentation: hierarchy plan (the refine - similar to consist-of - and provided-by relationsare introduced to define graphs), dependency plane (consistency relations like requireand conflict, together with the provided-by one are used; and modify relations, e.g. ex-istence modify or value modify), and feature sets plane.
Riebish [RIE 03] and the Alexandria method depicts the refinement relations be-tween features as: is-a or part-of.
Streitferdt et al. [STR 03] introduce a OCL formalization of feature models tocheck the product line consistency. The authors define the following feature con-straints: requires, excludes, and hint, as well as the uses relation.
Riebish et al. [RIE 04] sum-up issues of discussions of a workshop and show hi-erarchical relations in FMs (feature sub-feature), and constraints (requires, excludes).The authors suggest weak forms of the latter: recommends and discourages.
In [MEI 06], the paper presents a metamodel for modeling system features andrelationships between features. The authors explicitly specify both static and dynamicdependencies between system features. The static dependencies between features arespecified by the constraint relationships, and the dynamic dependencies between fea-tures are captured by the interaction relationships.
Specifically concerned with the Dependencies between Features:Ferber et al. [FER 02] introduce a method to investigate feature dependencies and
interactions and propose two complementary views to represent the FM; hierarchi-cal refinement of features and dependencies and interactions between features. Theauthors identify five types of dependencies (intentional interaction, resource usage in-teraction, environment induced interaction, usage dependency, exclude dependency).
Lee and Kang [LEE 04] analyze feature dependencies and gave out six types offeature dependencies which have significant influences on the design of PL assets. Theauthors organize the variability modeling in terms of structural relationships (viz. ag-gregation and generalization), configuration dependencies (viz. require and exclude),and operational dependencies. The latter are decomposed into: usage dependencies(functional), modification dependencies (behavioral modification of a feature by an-other), and four activation ones (exclusive, subordinate, concurrent, sequential).
Vranic [VRA 04] exposes the logical connectives in FMs (e.g. implication !, andequivalence ") that are used to define default dependency rules. Relations between
39
6 JLdP. Volume 1 - n! JLdP/2012
the FM and other modeling artifacts are defined as a set of links.Zhu et al. [ZHU 06] present an approach to analyzing domain requirements depen-
dencies influence on product line architecture. The authors define a feature dependen-cies classification (static dependencies are: decomposition, generalization, required,excluded; and dynamic dependencies are: serial, collateral, synergetic, and change -state, behave, data, code) and mapping rules from features to the architecture.
Ye and Liu [YE 05] provide a matrix-based approach to model feature dependen-cies for scalability purpose. Three hierarchical relationships (composition, general-ization / specialization and variation point) and three non hierarchical ones (requires,excludes and impacts) have been identified.
In [SIL 06], the authors propose the use of dependencies to bind the variability.The approach defines fundamental dependencies (imposed by the problem space), andconfiguration-specific dependencies (relative to implementation).
Cho et al. [CHO 08] introduce an aspect-oriented approach to manage operationaldependencies. Relationships exposed are based on a previous work [LEE 04].
A formalization of the dependencies from [KAN 98] and [LEE 04], and a catego-rization in global and local is made in [LUO 09].
Specifically concerned with Feature Models and Visualization:Botterweck et al. [BOT 08] introduce a meta-model and accompanied research
tool that employs visualization techniques to support fundamental product line devel-opment tasks. The authors reify some relationships in their metamodel: Requires isa directed dependency between elements of the same type (Requires_FF, expressesdependencies between features - Requires_DD for decisions - Requires_CC for com-ponents); Excludes is an undirected dependencies, since it describes a set of elementsthat are mutually exclusive; ImplementedBy, which again has subtypes for the differ-ent elements (ImplementedBy_DF, a decision is implemented by certain features, andImplementedBy_FC, a feature is implemented by certain components).
Zhao et al. [ZHA 08] address the collaborative customization of FMs problemproposing a multi-view based approach. The authors rely on a FM metamodel thatreifies parent-child refinement relations (decomposition, characterization and special-ization), as well as constraints (require, exclude and complex ones).
Cawley et al. discuss [CAW 09] how to represent the relationships that exist be-tween those models and present an approach for communicating the relationships us-ing visualization techniques. A 3D visual environment is employed to render these re-lationships to support stakeholder cognition during product derivation. (The 3 Ds are:decision, feature and components). Decisions are “implemented by” Feature relation-ships, and Features are “implemented by” Component relationships (Feature requiresFeature, Feature excludes Feature, Feature recommends Feature (no more details pro-vided), Feature problematic with Feature (no more details provided)).
3.1.2. Inter-Model Concerns in Feature Modeling
Inter-model relationships can be either in a unique metamodel (variability model)or between heterogenous metamodels (variability and core artifacts ones).
40
Survey of Relationships in Variability Modeling Approaches 7
Relating Features to Implementations:To allow the generation of the product, there is typically some mapping between
features and implementation artifacts, e.g. Sametinger and Riebisch [SAM 02] pro-vide additional information about details of the solution domain by linking featuresto elements of design and implementation. In Riebish [RIE 03] it is express as con-nections of features to other models that are given by traceability links. Czarnecki etal. [CZA 05] associate FMs to model fragments by adding tags into them. In [HEI 08],authors map (mapping relationship), with no precise semantic, feature to assets.
Separation of Concerns and Modularization:In [REI 07], Reiser and Weber are concerned with the management of large and
complex FMs, organized as hierarchical sub-feature models (sublines), where somefeatures are connected with referenceFeature relationships to others. The authors useFMs and provide customable direct typed feature links to constraint the set of validconfigurations (e.g. needs, suggests, independent of or excludes).
As previously introduced, Metzger et al. [MET 07] make the distinction betweenproduct line variability and software variability. In [MET 07, THA 09], the authorsdefine dependencies as generic cross-model links called x-links. Variability modelsand links are formalized to be checked as a satisfiability problem. In the latest arti-cle [THA 09], some of the authors make the separation between (i) requirements, (ii)problem world context, and (iii) specifications (features), with the aim to generate fea-ture configurations from selected requirements.
Bo!kovic et al. [BO11] propose an approach to improve the manageability and re-duce the maintainability efforts in feature modeling. The authors rely on the FM tree-like structure and introduce two kinds of integrity constraints, namely intra-concernintegrity constraints (between features of one concern, viz. includes and excludes) andinter-concern integrity constraints (between features in different concerns, introduc-ing the equivalent constraints).
Hartmann and Trew [HAR 08] introduce context variability models to supportmultiple product lines; requires and excludes are used in FMs, and dependency linksbetween the Context Variability Model and the FM are set. These links can be anno-tated with a rationale property (e.g. excludes, set cardinality).
Lee and Kang [LEE 10] define links between the Usage Context Variability Modeland the other variability Models. The approach uses n-to-m mappings to connect thedifferent concerns.
3.2. Other Modeling Techniques and Metamodels
COVAMOF [SIN 04] models the variability in terms of Variation Points (VPs) anddependencies, which represent the constraints on these VPs. The approach defines Re-alization relation entities to relate VPs at different levels of abstraction. Dependencyentities specify a mapping from a sub-configuration of VPs to the target domain.
Pohl et al. propose OVM [POH 05], a DSL also based on VPs and Variants, tomodel the variability separately. It provides a view on variability across all develop-
41
8 JLdP. Volume 1 - n! JLdP/2012
ment artifacts. Constraints like mutex and require are represented and traceability linkscalled artefact dependency are defined to relate variability artifacts to design ones.
The amalgamated variability technique like [MOR 09], or approaches concernedwith the architecture (e.g. [ASI 04]), are limited in defining relationships. Typically,these kinds of approaches rely on the relationships defined in the amalgamated targetlanguage. The CVL language [FLE 12] do not focus specifically on relationships, butcovers dependencies found in FM approaches and implicit modification ones.
The TVL text-based approach [CLA 11] subsumes existing FM languages. Froma relationship perspective, the language formally defines equality and implication, aswell as guarded constraints.
Finally, with the aim to manage heterogeneous models, Dhungana et al. [DHU 11]define inter-model dependencies between FM (provides feature, extends feature) andbetween generic variability models (alternative models, extends model).
4. Classification of the Relationships and Discussion
Based on our observations, the relationships revealed by the survey can be clas-sified by five main properties: (1) Concern: the relationships do or do not cross con-cerns (intra or inter concerns); (2) Artifact Related: the relationships link same set ofartifacts (homogeneous) or different sets (heterogeneous); (3) Abstraction level: therelationship is defined as vertical (crossing abstraction levels) or horizontal; (4) Time:the relationships is temporally related to (i) design time, being structural (establishedby logical groups or hierarchy) or dependency (basic configuration or usage specificones), (ii) run-time (operational activities), or (iii) over-time (evolution concerned);(5) Impact: the relationships define (i) induction (implication or exclusion), (ii) modi-fication (interaction, substitution, deletion), or (iii) activation.
The following list organizes the surveyed approaches in four main categories en-countered, following combinations of the properties:
– Hierarchical refinement relationships: This refinement is typical to feature mod-els, and initially called Consist-of [KAN 90]. These co-implication relation-ships are symmetric and transitive and are specialized into generalization (isspecialized by), aggregation (has a), decomposition (part of) and classification(is a). Approaches are: [KAN 90, GRI 98, KAN 98, CZA 00, FEY 02, FER 02,RIE 03, LEE 04, RIE 04, VRA 04, YE 05, MEI 06, ZHU 06, REI 07, CHO 08,ZHA 08, LUO 09, CLA 11, FLE 12].
– Configuration dependencies: Are mainly based on the two following constraints,Implication (dissymmetric and transitive), and Exclusion (symmetric but nottransitive). Approaches are: [KAN 90, GRI 98, KAN 98, CZA 00, FEY 02, FER 02,RIE 03, STR 03, LEE 04, VRA 04, RIE 04, POH 05, YE 05, MEI 06, SIL 06,ZHU 06, REI 07, BOT 08, CHO 08, HAR 08, HAR 09, ZHA 08, CAW 09, LUO 09,BO11, CLA 11].
– Usage specific relationships: Depending on the usage, the relationships canbe refined with rationals (even though, very often not described precisely),
42
Survey of Relationships in Variability Modeling Approaches 9
like for Implication: depends-on, requires, resource, includes, impacts, satis-fies, uses, allocate-to, induces, design, core, implemented-by; and for Exclu-sion: incompatible, mutex-with, conflict. Approaches are: [FEY 02, FER 02,RIE 03, STR 03, LEE 04, RIE 04, MEI 06, SIL 06, ZHU 06, REI 07, CHO 08,CAW 09, LUO 09, CLA 11]. These relationships correspond to various view-points (often not so well defined) and can particularly defined runtime (opera-tional) dependencies [STR 03, LEE 04, SIL 06, ZHU 06, CHO 08, LUO 09].
– Inter-concerns dependencies: in a single variability model ([KAN 98, CZA 00,FER 02, LUO 09]), between variability models ([SIN 04, POH 05, MET 07,REI 07, HAR 08, HAR 09, THA 09, BO11, LEE 10, DHU 11]), or variabil-ity models and core artifacts ([SAM 02, SIN 04, POH 05, ZHU 06, BOT 08,HEI 08, CAW 09, THA 09]).
With a particular focus on configuration dependencies and usages until 2004, workshave moved to explicitly define concerns and relating them with relationships. Someformalization efforts have been then provided to improve the PL consistency.
The degree of formalization is divided in three types: (1) Textual description:[KAN 90, GRI 98, KAN 98, CZA 00, FER 02, SAM 02, RIE 03, LEE 04, RIE 04,SIL 06, CHO 08, HAR 08, HAR 09, CAW 09, BO11, DHU 11], (2) Metamodel rep-resentation: [FEY 02, STR 03, SIN 04, MEI 06, POH 05, YE 05, REI 07, BOT 08,HEI 08, ZHA 08, FLE 12], (3) Mathematical formalism: which can be related to propo-sitional formulae or any set-based formalism [VRA 04, MEI 06, ZHU 06, MET 07,LUO 09, THA 09, LEE 10, CLA 11].
As concluding remarks, it is interesting to notice that, in variability modeling, moreefforts have been provided in Feature Modeling about the separation of concerns andrelating variants. The initial purpose of FMs to address only variability as limits andmany works express the need to enhance the expressiveness of the models. Neverthe-less, there is no consensus about relations in FMs or other variability models in theliterature and even though categories have been defined, relationships are not consid-ered by most approaches as first-class elements.
The need of relating variants or part of variability models to one another can befound in several works, especially in Feature Model approaches. Nevertheless the re-lationships are often buried in the variability model and can lack semantics: their de-scription can be quite vague and imprecise, especially when describing the specificusages. Efforts have therefore to be provided to (i) clarify the relationships, (ii) theirsemantics and (iii) their corresponding usages.
Indeed, making explicit these relationships is useful to increase the understand-ability and the tool interoperability, improving the operational semantics. In a Model-Based Product Line, the Modeling Space is defined by a huge set of models (whichmight be at different levels of abstraction): variability models and core asset models. Inthis space, relational information appears everywhere e.g., overlapping models, inter-acting ones. Thus, organizing dependencies among modeling artifacts and clarifyingtheir use is central to ensure consistency and to ease maintenance of PLs.
43
10 JLdP. Volume 1 - n! JLdP/2012
5. Conclusion
The paper presents a survey of the variability modeling approaches in the literaturethat handle explicit relationships between variable elements. The goal is to present acoverage of the current body of knowledge in the area and to reveal needs. Relation-ships are defined for various purposes: Hierarchical refinement, Configuration, Spe-cific Usage, and Inter-concerns management. We observe a lack of formalization andmostly of description of the relationships usages, and emphasize on the need to ex-plicit the relationships and isolate the relational concern. Making known relationshipsexplicit participates to reveal implicit relational information.
Based on the relationships categories of the classification, we investigate in [CRE 12]on an approach based on a relationship-based DSL connected to feature models tosemantically enriched the variability viewpoint. The DSL is based on multi-level con-cerns addressing intentional relations and operational relationships to improve read-ability and understandability. Through this work, we help understand the semantics ofrelationships by capturing them into a DSL and structuring the variability models.
Future work will extend the language to other variability models and will providedetails on the implementation of such DSL into a model-based development process.The aim is to provide a solution that allows the engineers to focus on their domain andreason about the relationships between the elements of the different spaces, abstractionlevels and concerns.
6. References
[ASI 04] ASIKAINEN T., SOININEN T., MÄNNISTÖ T., “A Koala-Based Approach for Mod-elling and Deploying Configurable Software Product Families”, vol. 3014 of Lecture Notesin Computer Science, p. 225–249, Springer, 2004.
[BAI 93] BAILIN S., “Domain Analysis with KAPTUR”, Tutorials of TRI-Ada’93, , 1993.
[BO11] BO"KOVIC M., MUSSBACHER G., BAGHERI E., AMYOT D., GA"EVIC D., HATALA
M., “Aspect-oriented feature models”, MODELS’10, Berlin, Heidelberg, 2011, Springer-Verlag, p. 110–124.
[BOT 08] BOTTERWECK G., THIEL S., NESTOR D., BIN ABID S., CAWLEY C., “VisualTool Support for Configuring and Understanding Software Product Lines”, SPLC, IEEEComputer Society, 2008, p. 77-86.
[CAW 09] CAWLEY C., THIEL S., BOTTERWECK G., NESTOR D., “Visualising Inter-ModelRelationships in Software Product Lines”, VaMoS, 2009, p. 37-44.
[CHO 08] CHO H., LEE K., KANG K. C., “Feature Relation and Dependency Management:An Aspect-Oriented Approach”, Proceedings of SPLC ’08, Washington, DC, USA, 2008,IEEE Computer Society, p. 3–11.
[CLA 11] CLASSEN A., BOUCHER Q., HEYMANS P., “A text-based approach to featuremodelling: Syntax and semantics of TVL”, Science of Computer Programming, vol. 76,num. 12, 2011, p. 1130 - 1143.
[CLE 01] CLEMENTS P. C., NORTHROP L., Software Product Lines: Practices and Patterns,SEI Series in Software Engineering, Addison-Wesley, August 2001.
44
Survey of Relationships in Variability Modeling Approaches 11
[CRE 12] CREFF S., CHAMPEAU J., JÉZÉQUEL J.-M., MONÉGIER A., “Relationships For-malization for Model-Based Product Lines”, Proceedings of APSEC ’12, 2012, to appear.
[CZA 00] CZARNECKI K., EISENECKER U. W., Generative programming: methods, tools,and applications, ACM Press/Addison-Wesley Pub. Co., NY, NY, USA, 2000.
[CZA 05] CZARNECKI K., ANTKIEWICZ M., “Mapping features to models: A template ap-proach based on superimposed variants”, LNCS, vol. 3676, 2005, Page 422, Springer.
[DHU 11] DHUNGANA D., SEICHTER D., BOTTERWECK G., RABISER R., GRUNBACHER
P., BENAVIDES D., GALINDO J. A., “Configuration of Multi Product Lines by BridgingHeterogeneous Variability Modeling Approaches”, Proceedings of SPLC ’11, Washington,DC, USA, 2011, IEEE Computer Society, p. 120–129.
[FER 02] FERBER S., HAAG J., SAVOLAINEN J., “Feature Interaction and Dependencies:Modeling Features for Reengineering a Legacy Product Line”, CHASTEK G., Ed., SoftwareProduct Lines, vol. 2379 of LNCS, p. 37-60, 2002.
[FEY 02] FEY D., FAJTA R., BOROS A., “Feature Modeling: A Meta-Model to Enhance Us-ability and Usefulness”, Proceedings of the Second International Conference on SoftwareProduct Lines, SPLC 2, London, UK, UK, 2002, Springer-Verlag, p. 198–216.
[FLE 12] FLEUREY F., HAUGEN Y., MØLLER-PEDERSEN B., SVENDSEN A., ZHANG X.,“Standardizing Variability Challenges and Solutions”, SDL 2011 Proceedings, vol. 7083of LNCS, p. 233-246, Springer / Heidelberg, 2012.
[GRI 98] GRISS M. L., FAVARO J., ALESSANDRO M. D., “Integrating Feature Modeling withthe RSEB”, Proceedings of the 5th ICSR, IEEE Computer Society, 1998.
[HAR 08] HARTMANN H., TREW T., “Using Feature Diagrams with Context Variability toModel Multiple Product Lines for Software Supply Chains”, Washington, DC, USA, 2008,IEEE Computer Society, p. 12–21.
[HAR 09] HARTMANN H., TREW T., MATSINGER A., “Supplier independent feature mod-elling”, SPLC ’09, Pittsburgh, PA, USA, 2009, Carnegie Mellon University, p. 191–200.
[HEI 08] HEIDENREICH F., KOPCSEK J., WENDE C., “FeatureMapper: Mapping Features toModels”, Companion Proceedings of ICSE’08, ACM, 2008.
[KAN 90] KANG K. C., COHEN S. G., HESS J. A., NOVAK W. E., PETERSON A. S.,“Feature-Oriented Domain Analysis (FODA) Feasibility Study”, report , 1990.
[KAN 98] KANG K. C., KIM S., LEE J., KIM K., “FORM: A feature-oriented reuse methodwith domain-specific reference architectures”, Ann. Softw. Eng., vol. 5, 1998, J. C. BaltzerAG, Science Publishers.
[LEE 04] LEE K., KANG K. C., “Feature dependency analysis for product line componentdesign”, Lecture Notes in Computer Science, Springer, 2004, p. 69–85.
[LEE 10] LEE K., KANG K. C., “Usage context as key driver for feature selection”, Pro-ceedings of the 14th international conference on Software product lines: going beyond,SPLC’10, Berlin, Heidelberg, 2010, Springer-Verlag, p. 32–46.
[LUO 09] LUO D., DIAO S., “Feature Dependency Modeling for Software Product Line”,ICCET ’09 Proceedings, vol. 2, 2009, p. 256 -260.
[MEI 06] MEI H., ZHANG W., ZHAO H., “A metamodel for modeling system features andtheir refinement, constraint and interaction relationships”, Software and Systems Modeling,vol. 5, 2006, p. 172-186, Springer Berlin / Heidelberg.
45
12 JLdP. Volume 1 - n! JLdP/2012
[MET 07] METZGER A., POHL K., HEYMANS P., SCHOBBENS P.-Y., SAVAL G., “Disam-biguating the Documentation of Variability in Software Product Lines: A Separation ofConcerns, Formalization and Automated Analysis”, Requirements Engineering Confer-ence, vol. 0, 2007, p. 243-253, IEEE Computer Society.
[MOR 09] MORIN B., PERROUIN G., LAHIRE P., BARAIS O., VANWORMHOUDT G.,JÉZÉQUEL J.-M., “Weaving Variability into Domain Metamodels”, SCHÜRR A., SELIC
B., Eds., Proceedings of MODELS’09, Springer Verlag, 2009, p. 690–705.
[POH 05] POHL K., BÖCKLE G., LINDEN F. J. V. D., Software Product Line Engineering:Foundations, Principles and Techniques, Springer NY, Inc., Secaucus, NJ, USA, 2005.
[REI 07] REISER M.-O., WEBER M., “Multi-level feature trees: A pragmatic approach tomanaging highly complex product families”, Requir. Eng., vol. 12, num. 2, 2007, p. 57–75, Springer-Verlag New York, Inc.
[RIE 03] RIEBISCH M., “Towards a More Precise Definition of Feature Models”, RIEBISCH
M., COPLIEN J. O., STREITFERDT D., Eds., Modelling Variability for Object-OrientedProduct Lines, p. 64-76, Norderstedt, 2003.
[RIE 04] RIEBISCH M., STREITFERDT D., PASHOV I., “Modeling Variability for Object-Oriented Product Lines”, ECOOP 2003 Workshop Reader, vol. 3013 of LNCS, p. 165-178,Springer Heidelberg, 2004.
[SAM 02] SAMETINGER J., RIEBISCH M., “Evolution Support by Homogeneously Docu-menting Patterns, Aspects and Traces”, ECSMR’02 Proceedings, 2002.
[SIL 06] SILVA FILHO R. S., REDMILES D. F., “Towards the Use of Dependencies to ManageVariability in Software Product Lines”, Proceedings of the Workshop held in conjunctionwith SPLC-2006, Fraunhofer IESE, October 2006, p. 4-15.
[SIN 04] SINNEMA M., DEELSTRA S., NIJHUIS J., BOSCH J., “COVAMOF: A Frameworkfor Modeling Variability in Software Product Families”, NORD R. L., Ed., SPLC, vol. 3154of LNCS, Springer, 2004, p. 197-213.
[STR 03] STREITFERDT D., RIEBISCH M., PHILIPPOW I., “Details of Formalized Relationsin Feature Models Using OCL”, Proceedings of ECBS 2003, Huntsville, USA. IEEE Com-puter Society, 2003, p. 45–54.
[THA 09] THAN TUN T., BOUCHER Q., CLASSEN A., HUBAUX A., HEYMANS P., “Relatingrequirements and feature configurations: a systematic approach”, Proceedings of SPLC ’09,USA, 2009, p. 201–210.
[VRA 04] VRANIC V., “Reconciling Feature Modeling: A Feature Modeling Metamodel.”,WESKE M., LIGGESMEYER P., Eds., Net.ObjectDays, vol. 3263 of Lecture Notes in Com-puter Science, Springer, 2004, p. 122-137.
[YE 05] YE H., LIU H., “Approach to modelling feature variability and dependencies in soft-ware product lines”, Software, IEE Proceedings -, , 2005, Institution of Electrical Engineers.
[ZHA 08] ZHAO H., ZHANG W., MEI H., “Multi-View based Customization of Feature Mod-els”, Journal of Frontier of Computer Science and Technology, , 2008.
[ZHU 06] ZHU C., LEE Y., ZHAO W., ZHANG J., “A Feature Oriented Approach to Mappingfrom Domain Requirements to Product Line Architecture”, ARABNIA H. R., REZA H.,Eds., Software Engineering Research and Practice, CSREA Press, 2006, p. 219-225.
46
Refactoring Process for Software Product Line Architecture Design Francisca Losavio* - Oscar Ordaz* - Nicole Levy** -Anthony Baïotto**,*** * MoST, Escuela de Computación, Facultad de Ciencias, Universidad Central de Venezuela, Caracas, Venezuela {francisca.losavio, oscar.ordaz}@ciens.ucv.ve ** CEDRIC, CNAM, Paris, France [email protected] *** Thales Group, Velizy, France [email protected] _________________________________________________________________________________________________
ABSTRACT. Product Line Architecture (PLA) is a core architecture that captures the high level design for the products of some Software Product Line (SPL), including variation points. PLA can be obtained either following a top-down or proactive design, i.e., constructing PLA from the domain knowledge, or a bottom-up or reactive design which explicitly requires reengineering techniques such as reverse engineering and refactoring, to generalize reusable assets from concrete products. The majority of SPL architecture design methods follow these two approaches, or a combination of them. However, few specific architectural design methods are proposed for SPL and the reuse of existing single-system methods makes difficult the handling of architectural variability. Responding to industrial practice, this paper proposes to use reengineering techniques to define a reactive process to build a PLA from existing similar software product architectures of a domain. The approach is composed of four main steps: (a) describe existing product architectures; (b) create Refactoring Graphs for each product to build the Product Line Architecture Graph; (c) construct a candidate PLA; (d) optimize the candidate PLA. The reactive graph-based bottom-up process is applied to a case study in the robotics industry domain that inspired this work. The process is partially tool supported. KEYWORDS: software product line, product line architecture, reverse engineering, refactoring, directed graph, refactoring graph, quality model
47
1. Introduction
In the context of an industrial production domain, “a production line is a set of sequential operations established in a factory whereby materials are put through a refining process to produce an end-product that is suitable for onward consumption; or components are assembled to make a finished article1”, in other words, a production line is defined as a process to construct several products from existing items. In the software domain, 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 and that are developed from a common set of core assets, which are reused in different products that form a family [1]. The SPL approach favours reusability and claims to decrease costs and time-to-market. The key issue in SPL development is the construction of a common architecture from which new products can be derived.
Software Architecture is defined in [2] as “a collection of computational components - or simple components - together with a description of the interactions between these components, the connectors”. A Product Line Architecture (PLA) is defined by [3] as a core architecture that captures the high level design for the products of the SPL, including variation points and variants documented in the variability model. After examining several definitions of PLA, [4] considers that it is a special kind of software architecture used to build a SPL; it explicitly describes commonality and variability and is the basis for the architecture of all products in the SPL. Two axes for SPL engineering are followed: the top-down or proactive design which considers constructing PLA from domain knowledge and the reactive or extractive bottom-up design which develops the PLA from systematic refactoring of existing products [5].
In this work the reactive or bottom-up design is followed, because in practice, many industrial organizations do not have a PLA; they only dispose of products constructed over time and by different development teams, and a generic architecture, according to the business domain is required to reduce costs, time-to market and increase products evolution [5], [6]. The basic input required by this approach are architectures of the similar existing products conforming the SPL family and architectural quality requirements. The key problem in SPL of constructing the PLA is in general not addressed systematically in the literature and left to case studies [6], and the details of methods and approaches are difficult to follow. Existing traditional architectural methods and evaluation techniques for single-systems are reengineered and not specifically designed for SPL [7]. On the other hand, the reengineering discipline, consisting in the examination and the alteration of a subject system or software artefact to reconstitute it in a new form [8], is used to the guarantee the SPL evolution. In the pro-active approach it is generally used to maintain and improve the PLA, and in the reactive approach it is required to 1 http://en.wikipedia.org/wiki/Production_line 2 ISO/IEC 25010. Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models,” ISO/IEC JTC1/SC7/WG6, 2011.
48
recover architectural knowledge from existing products. Reengineering techniques are - Reverse Engineering (the examination) that helps clarifying the structure by extracting information and providing high-level views on the subject system, and - refactoring (the alteration) that modifies software or software artefact to improve some of its quality properties, such as maintainability, understandability, or robustness. Once the software or artefact is better understood and in a better shape, it is ready to fulfil its new requirements.
An important question that commonly appears in the literature is what needs to be done to ensure a suitable choice of architecture for the family of products [9]. This work contributes to provide an answer to this question, proposing a refactoring process to build the PLA as a main goal. This reactive bottom-up process is based on the identification of different connected architectural intermediate configurations, starting from some existing similar product architectures and that will be part of the SPL family. The inspiration for this work came from [10] with a case study in the robotics industry domain. The model supporting our process is a directed graph, or Refactoring Graph, denoted by RG. A product is considered to be a set of architectural configurations; a component provides/requires interface to/from another component; we will neither consider other relation types among components, nor ports. Only the logical view [11] of the architecture expressing static aspects will be considered in this work; this view will be specified using UML 2.0 [12], as the architecture description language (ADL). Four main steps constitute the refactoring process: specify products’ architectures, build the RG for each product considered, build a candidate PLA from RGs and variation points, and optimize the candidate PLA.
This paper is structured as follows, besides this introduction: the second section presents the graph model supporting the refactoring process and describes the case study of the robotics industry. The third section contains the steps of the refactoring process, illustrated by the application on the case study. The fourth section discusses the related works. Finally, the conclusion and perspectives are presented.
2. Modelling of the refactoring process
The model supporting our process is a directed graph, or Refactoring Graph, denoted by RG. Given a certain product, the nodes of RG are all connected intermediate architectural configurations of the product, i.e., valid configurations. Nodes are distributed into levels, Li is referred as level i; there are as many levels in RG, as many components in the product. If n is the number of components in a product, the last level Ln has only one node corresponding to the product architecture. There is an arc between two nodes in consecutive levels, if one of them is obtained from the other (preceding node) by adding a new component. A triplet indicating the starting node, the added component with its associated weight, respectively, labels each arc. The bottom-up process followed to construct RG, starting from Ln, is inspired by the work of Carlos Matus [13], placing in Li-1 the preceding nodes of Li. In this way, the potential assets are the components
49
constituting L1 that can be considered for the PLA. The construction of RG can be justified by showing that levels are non-empty sets, and that the product is assembled by adding components one by one. 2.1. Case Study in the Robotics Industry Domain
An interesting work by Koziolek, Weiss and Doppelhamer [10] describes a reengineering approach to build the product line architecture to develop PC software for a robotics industry, based on the refactoring of three existing products. However, it lacks the description of a systematic process, being limited to expertise considerations; the PLA that is produced satisfies established quality goals for the domain. Considering the case study described in [10], we propose in this work a systematic and repeatable derivation process, based on a refactoring approach and the use of the graph model described above. The bottom-up derivation of PLA from the individual products is performed analysing the RG associated to each product. Figure 1 shows three similar products of the robotics industry domain specified in UML. Notice that UML 2.0 is used here as an ADL; however, only the statics aspects or logical view of the architecture are discussed in this work. In figure 1, aRb means that component a is connected to component b by some type of symmetric connector R, and for example for the first product: P1 = {a, b, c, d}; sub-components are denoted by a list, b(b1, b2, b3). The relevance (high=3, medium=2, low=1) of each component [14] with respect to the architectural configuration of each product is expressed by their weights, provided by the architect, as shown in table 1. Product architectures shown in figure 1 had been recovered in [10] using
Figure 1. Logical view for three products of a robotics industry [10]
Product P1 : {a, b(b1, b2, b3), c, d} aRc; aRb; cRd; bRc
Product P2 : {a, b1, b2, c ,e , f} aRb2; aRc; cRe; b1Rf; b1Rc; b2Rc
Product P3 : {a, c, g(b1), h} aRc; aRg; cRh; gRc
50
reverse engineering techniques, which we have not directly used here. However, component names were unified in this work for the three products considering internal name and content similarity, according to [21].
Pi\w a b b1 b2 b3 c d e f g h
P1 3 3 2 2 2 3 1
P2 3 3 3 3 1 1
P3 3 2 3 3 1
Table 1. Component weights for each product
3. Reactive Design Process to build the PLA
Figure 2 shows the main activities or sub-processes of the PLA refactoring process.
Figure 2. Activity diagram for the PLA Reactive Design Process
The architectural quality model (AQM) contains the PLA quality requirements,
specified according to the ISO/IEC 250102 standard; these quality goals drive the whole optimization process. Notice that AQM should be part of the SPL asset repository [24]; otherwise it should be built accordingly, using the present domain knowledge. A prototype computational tool to build RG supports this process. In what follows, each step of the Refactoring Process will be presented and applied to the case study.
2 ISO/IEC 25010. Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models,” ISO/IEC JTC1/SC7/WG6, 2011.
51
3.1. Specify products’ architectures.
The software architect starts from the description of the architectures of the products of the domain knowledge (see Section 2.1, figure 1). Names for components and their connections are specified as follows (see figure 1):
P1: P = {a, b (b1, b2, b3), c, d), R = {aRc, aRb, cRd, bRc};
P2: P = {a,b1, b2, c, e, f}, R= {aRb2, aRc, cRe, b1Rf, b1Rc, b2Rc};
P3: P = {a, c, g (b1), h}, R = {aRc, aRg, cRh, gRc}.
The weights of each component were shown in table 1.
3.2. Build the Refactoring Graph (RG).
RG is built automatically from the above specification.
In figure 3, node abcd represents the original architectural configuration of product P1 on L4 (see figure 1), and RG shows that abcd can be obtained by three alternative ways from the preceding L3, either from valid configuration abc by adding d, or from valid configuration bcd by adding a, and finally from acd by adding b. Figures 4 and 5 show RG for products P2 and P3, respectively.
3.3. Build Candidate PLA
The idea now is to define a common architecture from which the different products can be derived by transformation. This Candidate PLA needs to contain the variation points and those architectural components that are functionally most relevant to the domain, according to [14]. Given the RG associated to several products Pk, a variation point V is defined as equal configuration nodes on the same level Lq, q ! 2, in each RG of Pk, with the maximum number of components. Notice that there may be more than one variation point. The quality requirements that PLA must accomplish will be considered in the optimization step of the Candidate PLA. All variation points can be considered as the initial PLA. In the case study the variation point is ac. From this initial PLA, the Candidate PLA will be constructed automatically; to do so we need to find the more “convenient path” to obtain at least one of the products, among different existing paths containing the variation point. This path will contain the most relevant functionality of the architecture (see table 1). For example, in product P1, the arc label (ac, b, 3) means that component b is added to configuration ac to conform configuration abc, since w=3, and b (Picking/Packing application) is a relevant functionality for a product of the robotics industry. According to [14], the main functionalities are the initial components for the architecture, which is refactored by adding other components by transformations based on non-functional requirements; we consider the relevant functional components a starting point for our PLA. The incidence of the different weights on the arcs and the weight of the initial component (asset) on level L1 in a path will be the factor used to select a convenient path.
52
Figure 3. RG of Product 1
Figure 4. RG of Product 2
Figure 5. RG of Product 3
The Candidate PLA has been automatically obtained; it will be optimized in the
next step, where the architect can eventually select an alternative path (if any), according to a different selection strategy, if required.
53
Let d(V, Pk) for some variation point V in Lq, be the number of transformations required to reach Pk from V; M = min d (V, Pk), k = 1, …, n. The fusion of all configuration nodes on level LM+q of the PLAG, respecting the connections, constitutes the Candidate PLA. In the case study, the PLA is constituted by the fusion of the configuration nodes abcd, ab1b2c, acgh on L4 belonging to the selected path, from ac to P1, P2, P3 respectively (see figures 6 and 7).
Figure 6. PLAG for the Candidate PLA for robotics industry
Figure 7. Candidate PLA for robotics industry
3.4. Optimize Candidate PLA
This optimization step is a refactoring process performed using the expertise of the architect and domain engineer to transform iteratively the Candidate PLA into the final PLA, responding to specific quality properties. It involves three sub-processes:
• build the Architectural Quality Model (AQM), that represents the quality view of the domain [24], i.e., the set of all quality requirements concerning existing architectural solutions for the domain; it is considered an asset which is part of the domain knowledge
• build the Extended Architectural Quality Model (EAQM), i.e., the AQM enriched with architectural solutions and metrics for each quality property
54
• refactor the Candidate Product Line Architecture, according to the architectural solutions provided by each quality property
There are some tools that support the partial automation of these sub-processes;
for example some goal-oriented techniques [15] and trade-offs analysis [9], [25], [22], [26]. The HAM (Hybrid Assessment Method) [9] combining multi-criteria decision approaches is used to asses the architectural styles and their quality requirements suitable for the PLA, since its follows a top-down approach; in our case this information is already known as part of the domain knowledge since we follow a bottom-up design; however HAM could be used to improve the assignment of the priorities of the quality properties specified by our AQM. In general, complete automation is difficult to achieve [14], the final selection of the architectural solution is generally provided by the architect [22]. The optimized PLA, obtained from the Candidate PLA, is shown in figure 8. We have not placed the Job Controller component, because we have considered it is included in the Engineering component. However, it can be adapted from the existing b3 component of the Picking/Packing Application of product P1, and added between components a Plant Interaction Controller and c Robot Controller, to further increase availability and even performance.
Figure 8. PLA for robotics industry
4. Related works
Refactoring has been traditionally used to reconstruct legacy code and reverse engineering to recover or reconstruct documentation from existing software artefacts [16]. In the context of SPL these reengineering techniques have been used to modify existing PLA that have been built within a proactive top-down approach using the domain knowledge; from this generalization new evolutionary PLAs are built in [17], [18] and [6]. Another research axe also within the proactive approach, uses reverse engineering to analyse feature models (FMs); in [19] a tool supported
55
process for reverse engineering of the architecture of FMs is presented, with automated techniques to extract and combine different variability descriptions of an architecture. In [20], tool-supported automatic procedures for reverse engineering of FMs based on a heuristic for identifying parents, are presented; the key challenge in this task is the construction of the feature diagram, which is reduced to the selection of a parent for each feature, thus decreasing the number of features complexity to identify parent candidates for a given feature. On the other hand, reverse engineering and refactoring techniques are required to construct the PLA if the reactive bottom-up approach is used [5]; we recall that it generalizes reusable assets out of concrete products and it is the approach followed in this paper. The works of [10] and [21] had similarity with our approach, however none of them use a graph model to support the PLA construction. In [10] reverse engineering techniques were used to recover the architecture of three robotics industry products, from where the authors proceeded manually to construct the PLA satisfying main quality requirements; the trade-offs step was limited to a discussion. More recent works [22] and [23] propose the automation of the trade-offs step, based on multi-objective optimization where the objectives represent different quality attributes. Our work, which was inspired in [10], proposes a tool-supported automatic refactoring process to construct the Candidate PLA; the final PLA is obtained by refactoring this candidate PLA to satisfy specific quality requirements, which are specified by the ISO/IEC 25010 standard quality model, to improve communication among SPL architects and domain engineers. The trade-offs step is performed manually, however goal-oriented techniques are often used to improve trade-offs for the selection of the architectural solution and other tool-supported techniques could be introduced [9]. A semi-automatic PLA recovery approach is presented in [21], assuming that involved legacy products have similar designs and implementations. Clone detection and context analysis are used to identify corresponding mappings among design elements in different products. Different levels of abstraction of design elements are considered (class, methods, code); however they do not deal specifically with the architectural configuration, as we do; measures are defined to detect class, code, and methods similarities; we use some of them in the first step of our Reactive Design Process to unify components’ names. In [27] a systematic means to reengineer the legacy software products into SPL, based on automatic variability analysis, is provided. They propose a hybrid approach that consolidates feature knowledge from top-down domain analysis with bottom-up analysis of code similarities in subject software products. The bottom-up analysis follows a similar approach of [21] for similarity measures. From the works discussed we can appreciate the use of reengineering techniques and semi-automatic processes for the evolution and/or construction of PLA, however complete automation has not been achieved, because the expertise of the software architect is still the key issue to select convenient architectural solutions.
5. Conclusion
Traditional architectural design and assessment methods or combinations of them
for single-systems, have been adapted to construct SPL architectures [7]; however
56
they lack completeness, robustness and accuracy. SPL architectures have specificities that must be considered, such as existing architectural solutions that are part of reusable core assets, and the domain knowledge on non-functional requirements enhanced by the architecture, which are shared by all products of the SPL. We have proposed a Reactive Design process, based on systematic refactoring, to build the PLA for SPL starting from several existing products, using a reactive bottom-up design based on a graph model. The RG used to represent the intermediate valid architectural configurations, and the way in which they are constructed using transformations, is a useful model to help the expert reasoning during the PLA construction process; it is an excellent scenario for conflicting goals detection. The weights that are assigned to the transformations play an important role to justify the decisions and solve conflicts. The construction of RG, PLAG and Candidate PLA is automatic and supported by a prototype computational tool. The optimization of the Candidate PLA is manual; however the trade-offs step could be automated, taking into account existing tools from multi-criteria decision and multi-objective optimization models and tools and techniques from the goal-oriented engineering; for example a global SIG for the domain can be automatically generated from the domain quality model and Model-Driven Engineering (MDA) techniques could be used, being this an on-going research trend. Let us note that the existence of several products serving as a basis to the construction of the PLA is not as simple as it may seem. It involves a considerable reverse engineering effort in documenting individual components and unifying their names using complex similarity measures. The refactoring tool is currently under construction. Figures 3 to 6 have been obtained using it. It still needs improvements and to be completed to support completely the proposed process. This research has been partially sponsored by the PEI N 200 DISOFT project, Fonacit, Venezuela, and the Postgrado en Ciencias de la Computación, Facultad de Ciencias, Universidad Central de Venezuela.
References
[1] P. Clements and L. Northrop. Software product lines: practices and patterns 3rd edn., Readings, MA: Addison Wesley, 2001.
[2] M. Shaw, D. Garlan, Software Architecture. Perspectives of an emerging discipline, Prentice-Hall, 1996
[3] K. Pohl, G. Böckle, F. van der Linden: Software product line engineering - foundations, principles, and techniques. Springer 2005: I-XXVI, 1-467
[4] E. Y. Nakagawa, P. O. Antonio and M. Becker, Reference architecture and product line architecture: a subtle but critical difference, Crancovic V., Grhun, and M. Book (Eds.): ECSA 2011, LNCS 6903, pp. 207-211, Spronger-Verlag Berlin Heidelberg 2011
[5] P. Clements and C. Krueger. “Point-Conterpoint”, IEEE Software, 19(4), 2002. [6] A. Rashid, JC. Royer, A. Rummler (Eds). “Aspect-Oriented Model-Driven Software
Product Lines. The AMPLE Way, Chapter 1, pag 4,” Cambridge University Press, Cambridge, 2011.
[7] M. Matinlassi, Comparison of software product line architecture design Methods: COPA, FAST, FORM, KobrA and QADA, Proceedings of the 26th International Conference on Software Engineering (ICSE’04)
57
[8] E. J. Chikofsky and J. H. Cross, II. Reverse engineering and design recovery: A taxonomy. IEEE Software, pages 13–17, January 1990
[9] A. Rashid, JC. Royer and A. Rummler (Eds). “Aspect-Oriented Model-Driven Software Product Lines. The AMPLE Way, Chapter 2, pag. 48,” Cambridge University Press, Cambridge, 2011.
[10] H. Koziolek, R. Weiss, J. Doppelhamer. “Evolving industrial software architectures into a software product line: A case study,” R. Mirandola, J. Gorton, and C. Hofmeister (Eds): QoSA 2009, LNCS 5581, pp. 177-193, 2009.
[11] P. Krutchen, The 4+1 View model of software architecture, IEEE Software, 12(6) pp 42-50, 1995
[12] Object Management Group (OMG). “Unified Modeling Language Supersturcture, version 2.0 (formal/05-07-04),” August 2005. Available at: www.omg.org/spec/UML/2.0.
[13] C. Matus. “Planificación de situaciones”, Cuadernos de CENDES, Universidad Central de Venezuela, Caracas, Venezuela, 1977
[14] J. Bosch, “Design and use of software architectures - adopting and evolving a product-line approach,”. Addison-Wesley 2000
[15] L. Chung, B. Nixon and E. Yu, Using non-functional requirements to systematically select among alternatives in architectural Design, 1st International Workshop on Architectures for Software Systems, pp. 31-42, Seattle, Washington, 1995
[16] M. Fowler “Refactoring: improving the design of existing code,” Addison-Wesley, 1999. [17] M. Critchlow, K. Dodd, J. Chou, and A. van der Hoek, “Refactoring product line
architectures,” In IWR: Achievements, Challenges, and Effects, pp. 23–26, 2003. [18] D. Saraiva, LPereira, T. Batista, F.C. Delicato, P.F. Pires, U. Kulesza, R. Araújo, T.
Freitas, S. Miranda and A.L. Souto “Architecting a model-driven aspect-oriented product line for a digital TV middleware: A refactoring experience” LNCS, Volume 6285, Software Architecture, Pages 166-181, 2010.
[19] M. Acher, A. Cleve, P. Collet, P. Merle, L. Duchien and P. Lahire, Reverse engineering architectural feature models, ECSA 2011
[20] S. She, R. Lotufo, T. Berger, A. Wasowski and K. Czarnecki: Reverse engineering feature models. ICSE 2011: 461-470
[21] Y. Wu, Y. Yang, X. Peng, C. Qiu and W. Zhao, Recovering object-oriented framework for software product line reengineering, 12th International Conference on Software Reuse, ICSR 2011, Pohang, South Korea, June 13-17, 2011. Proceedings. LNCS 6727 Springer, pp. 119-134
[22] A. Martens, D. Ardagna, H. Koziolek, R. Mirandola and R. Reussner, A hybrid approach for multi-attribute QoS optimisation, in component based software systems, Proc. 6th Int. Conf. on the Quality of Software Architectures (QoSA'10), volume 6093 of LNCS, pages 84-101. Springer, June 2010
[23] A. Koziolek, H. Koziolek and R. Reussne, PerOpteryx: Automated application of tactics in multi-objective software architecture optimization, QoSA’11 Boulder, Colorado, USA, 2011
[24] F. Losavio, A. Matteo, N. Levy, “Web services domain knowledge with an ontology on software quality standards.” ITA’09, pp.74-85, CAIR, Glyndwr University, UK, Sept. 2011.
[25] L. Zhu, A. Keaurum, I. Gorton and R. Jeffrey, Tradeoff and sensitivity analysis in software architecture evaluation using analytic hierarchy process, Software Quality Journal, 13, 357–375, 2005
[26] I.M. Murwantara, Towards quality attributes decision modeling approach for a product line architecture, IJCSNS International Journal of Computer Science and Network Security, VOL.11 No.11, November 2011
[27] Y. Xue: Reengineering legacy software products into software product line based on automatic variability analysis. ICSE 2011: 1114-1117
58
Vers des interfaces graphiques flexibles deconfiguration
Simon Urli, Guillaume Perez, Heytem Zitoun, Mireille Blay-Fornarino, Philippe Collet, Philippe Renevier-Gonin
Laboratoire I3S (UNS - CNRS)Les Algorithmes - Bât Euclide B2000 route des Lucioles – B.P. 121F-06903 Sophia Antipolis Cedex
RÉSUMÉ. Par leur utilisation dans des domaines maintenant très divers, les lignes de produitslogiciels sont de plus en plus confrontées à une forte évolution couplée à des besoins de configu-ration par des utilisateurs finaux. L’interface graphique de configuration doit alors être déduite,de manière générique, des modèles de variabilité de la ligne, mais les travaux relatifs aux IHMsoulignent les faiblesses ergonomiques de ce type d’approche. Dans cet article, nous relatonsune expérience de réalisation d’une interface de configuration dédiée à la création de systèmesde diffusion d’informations, basée sur une approche mixte mêlant généricité et adaptation del’interface graphique par annotation des feature models décrivant la variabilité.
ABSTRACT. With their important usage in many domains, Software Product Lines (SPL) are moreand more facing frequent evolution coupled with the need for configuration by end users. Theconfiguration User Interface is expected to be deduced, in a generic way, from the variabilitymodels in the SPL. But previous work in HCI denote the ergonomic weakness of automatic-generated User Interface. In this paper, we report on the development of a graphical userinterface for configuration of an information broadcasting systems SPL. Our method is a mix ofgenericity and adaptability of user interface by enhancing feature models with annotations.
MOTS-CLÉS : feature model, configuration, généricité, IHM
KEYWORDS: feature model, configuration, genericity, HCI
Journée Lignes de produits 2012
59
1. Introduction
La force d’une ligne de produits est d’abstraire dans les termes du métier la pro-duction de produits en masquant à l’utilisateur final la mise en œuvre concrète de sesproduits. L’usage d’une ligne de produits est d’autant plus pertinente que les produitspotentiels présentent une grande variabilité et sont donc complexes à concevoir. L’in-terface de configuration/instanciation apparaît alors à l’homme du métier comme lapart fondamentale de la ligne qui le conduira ou non à l’utiliser.
La mise en place des outils graphiques supportant la configuration/instanciationdes produits pour une ligne donnée est donc essentielle à l’acceptation de la ligne parles utilisateurs finaux. Or, la construction des interfaces graphiques augmente de ma-nière conséquente le coût de la ligne et exige des efforts importants d’appréhensiondes exigences ergonomiques liées au métier associé. De plus si la ligne est appelée àévoluer, il conviendra de prévoir l’évolution également des interfaces graphiques deconfiguration. La construction de la ligne dans un processus agile amplifie alors le pro-blème puisque l’ajout de nouveaux features1 dans la ligne peut impacter grandementles interfaces graphiques associées.
Bien que dans (Bosch et al., 2001), la construction d’une interface dédiée estconseillée dans le contexte de lignes stables où peu de nouveaux features sont ajoutés,notre contexte fortement évolutif nous amène à considérer la génération automatiqued’interface graphique de configuration.
Cependant, différents travaux dans le domaine des IHM dans les années 90 - débutdes années 2000 (Myers et al., 2000) ont montré que la génération automatique d’in-terface graphique à partir de modèle(s) ne donnait pas de résultats aussi bons qu’undéveloppement spécifique. Dans les démarches centrées utilisateurs (Coutaz, 1990),différents modèles sont pris en considération pour la réalisation d’une interface gra-phique : les concepts du domaine (ici les features models), le modèle utilisateur (quiva utiliser), le modèle de tâches (comment l’utilisateur va intervenir sur les conceptsdu domaine), le modèle d’interaction (comment représenter les concepts du domaine,comment les manipuler), etc. La difficulté principale pour la génération automatiquede configurateur est la prise en compte de l’ensemble de ces modèles.
Dans (Boucher et al., 2012), certains de ces modèles sont intégrés dans la généra-tion de l’interface graphique de configuration, comme une représentation du modèledes tâches via le Feature Configuration Workflows. De manière complémentaire, nousproposons de prendre en compte l’utilisateur final et sa perception des produits à créerpour générer une interface graphique de configuration qui vérifie la propriété d’adap-tabilité des IHM (Bastien et al., 1993).
Cet article relate l’expérience menée dans le projet ANR Emergence YourCast,qui est présenté dans la partie 2. L’étude menée nous a permis d’identifier des élé-
1. Nous utiliserons dans l’ensemble du document les termes anglais feature model et featureafin de ne pas créer de contresens.
60
ments graphiques distinctifs entre les lignes utilisées (cf. partie 3). Sur la base de cesconstatations nous proposons une approche, décrite dans la partie 4, qui repose surla génération de l’interface de configuration à partir d’annotations sur les feature mo-dels, cette interface communiquant par la suite de manière synchrone avec un moteurde raisonnement sur les feature models. Nous discutons aussi les travaux connexes enpartie 5, avant de conclure cet article.
2. Etude de cas : configuration de produits dédiés à la diffusion d’informations
2.1. YourCast
YourCast a pour but de faciliter la création de systèmes de diffusions d’informa-tions. Il a pour vocation d’être utilisé par de nombreux acteurs non-informaticienspossédant une connaissance limitée du domaine des systèmes de diffusion.
Ce domaine regroupe des concepts aussi divers que :
– les sources d’informations : les services renvoyant les informations brutes sou-haitées,
– les renderers : les opérateurs de traitement des informations pour leur donnerune forme,
– les layouts : les structures d’écrans intégrant différentes zones,
– les zones : les emplacements dans lesquels les informations envoyées par lesrenderers seront affichées,
– les behaviours : le comportement qu’une zone doit adopter pour passer d’uneinformation à une autre.
Tous ces concepts sont exprimés sous la forme de feature models indépendants,afin d’obtenir les différents produits voulus qu’il sera possible par la suite de combinerpour réaliser un système de diffusion fonctionnel. Ainsi, nous avons dès lors besoind’une interface de configuration apte à prendre en compte ces différents feature modelset à les rendre configurables par une personne non-experte.
La figure 1 présente une capture d’un système en cours de diffusion. On peutconstater sur cet écran la présence d’un layout contenant deux zones, une centraleet une placée en bas de l’écran, diffusant deux sources différentes : la météo dans lazone centrale et des tweets dans la zone du bas. Les behaviours représentant la ma-nière dont les informations changent ne sont évidemment pas visibles sur cette capturestatique.
2.2. Agilité du développement de la ligne
La rapide évolution des besoins et des produits dans ces différents concepts force laprise en compte d’une grande évolutivité des caractéristiques. Nous visons par ailleurs
61
Figure 1. Capture d’écran d’un système de diffusion déployé lors du GDR-GPL 2012à Rennes
la création d’une communauté de développeurs2 et d’utilisateurs travaillant de concert,ce qui renforce le besoin d’une gestion incrémentale de l’ajout de nouveaux produitsdans la ligne (Urli et al., 2012).
De fait, les feature models seront donc amenés à évoluer en fonction de cette com-munauté de manière agile. L’interface de configuration s’appuyant sur ceux-ci devradonc être suffisamment souple pour pouvoir s’adapter automatiquement à ces change-ments réguliers.
Nos travaux sont donc guidés par deux préoccupations : (i) la compréhension(l’utilisabilité) de l’interface graphique de configuration par un utilisateur non-expertet (ii) une génération de cette interface graphique compatible avec l’évolution fré-quente des feature models sous-jacents. Le point (i) est détaillé dans la partie 3 puisnous présentons notre solution évolutive dans la partie 4.
3. Requis pour un utilisateur non-expert
Une première étude de l’outil de configuration supportant la construction de diffu-seurs d’informations nous a conduit à identifier selon les lignes de produits différentsparadigmes récurrents de configuration.
3.1. Des features discriminants pour l’utilisateur
L’expérience nous montre que tous les features ne jouent pas le même rôle enterme de configuration d’un point de vue utilisateur.
2. La mise en place de la communauté est poussée par les étudiants qui au fil du temps ont étéassocié au projet, et les besoins de nos partenaires industriels qui souhaitent pouvoir enrichir laligne avec leur propre "produits".
62
Figure 2. Capture d’écran de l’IHM de configuration
Des niveaux de sélection La sélection des sources d’information conduit à pri-vilégier la sélection du type d’information (albums photo, tweets, ...) qui est fortementdiscriminante, puis à s’intéresser ensuite aux familles de service (par exemple picasa,twitter). Les autres features (critère de sélection des informations, niveau de sécurité,...) se situent à un niveau plus bas de discrimination et sont généralement sélectionnéessuite aux sélections de plus haut niveau.
A contrario, certains feature models, comme celui de behaviours, ne possèdentqu’un seul niveau de sélection, toutes les caractéristiques étant toutes aussi discrimi-nantes les unes que les autres.
Dans le contexte de notre étude nous avons rencontré au maximum trois niveauxde sélections tel qu’on peut en avoir un aperçu dans la figure 2. Cette figure présente leconfigurateur généré dans le cas du feature model de sources. Dans les deux zones duhaut, les éléments présents dans une zone rouge ne sont plus disponibles à la sélectionpar le jeu des contraintes, ceux dans une zone verte ont été sélectionnés, et la zoneblanche représente les éléments que l’utilisateur peut encore potentiellement choisir.La zone du bas présente les dernières features permettant d’affiner la personnalisation.
Des features non pertinents à la configuration d’un point de vue utilisateurDe plus, certaines features ne sont parfois utilisées que par le jeu des contraintes etne semblent pas pertinentes à montrer à l’utilisateur : par exemple, certaines proprié-tés techniques ne parleront aucunement à l’utilisateur mais il est intéressant de lesmodéliser lors de la conception de la ligne.
63
3.2. Visualisations imagées
Plusieurs des features gagnent à être représentées par des icônes qui sont pluspertinentes que des textes : par exemple les logos des services dans le cas des sources(Picasa, Twitter, ...), l’iconification d’une disposition par des rectangles juxtaposésdans le cas des layouts, une animation pour visualiser des behaviours (défilements,...), etc.
Certains features peuvent être représentées par une même icône complétée parl’identifiant de la caractéristique (par exemple : "ByTag" ou "ByUrl" dans le cas d’unfiltrage ou d’un tri). Cette visualisation des features est particulèrement utile lors despremières étapes de construction d’une ligne de produits.
D’autres features ne trouvent pas facilement de représentation graphique. Nousutilisons alors les identifiants. La figure 2 montre ainsi l’utilisation de logos dans lesdeux premiers niveaux et l’utilisation d’identifiants dans le dernier niveau.
3.3. Explications
Lors de la définition des features dans les lignes de produits, il est fréquent devouloir associer des explications pour à la fois faciliter la maintenance de la ligne elle-même et aider la selection des features par l’utilisateur final. Il s’agira par exempled’expliquer qu’une source d’information "hyperplanning" diffuse des calendriers ouqu’un type d’information Calendrier respecte le format ical, etc. Ces explicationspourront servir aussi bien à décrire plus finement le rôle des features, leur mise enoeuvre, ou encore à expliciter certaines dépendances.
4. Interfaces graphiques de configuration adaptables
Sur la base des exigences liées à notre projet et identifiées dans la partie 3, noustravaillons à la mise en place d’interfaces graphiques de configurations adaptables pardes fichiers de configuration.
4.1. Annotation de FMs et séparation des préoccupations
Nous constatons tout d’abord que la structure des FMs n’est pas déterminante pourobtenir des informations sur la discrimination des features en niveaux de visualisation.Dans le cas des sources (cf. figure 3 (a))3, par exemple, le feature model présenteessentiellement deux branches, qui ne correspondent pas aux deux principaux niveauxde visualisation. Par ailleurs, il semble difficile et incohérent de forcer l’utilisationd’une structure au sein d’un feature model afin de le faire correspondre à une IHM.
3. Afin de simplifier la lecture des feature models nous avons choisi de ne pas représenter lescontraintes tranverses.
64
Source
TypeInfo Criteria
Tweets Calendar PictureAlbumForecast Announces Filter
Twitter ICalReader Weather2 FlickR Picasa Announcement City TimeLine Album Target
KeyMandatory
featureOptional feature
XOR
OR
Layout
Design Product Zones
EPU NoelCA N2IIRSAM LayoutIRSAM LayoutEPU LayoutCA BigSquareCenter ThinBarBottom
ThinBarBottomNoLogo ThinBarBottomLogo
(a)
(b)
Figure 3. Représentation simplifiée des feature models de source et de layout
Dans le cas des layouts (cf. figure 3 (b)), le feature model a une structure qui lui estpropre, très éloignée de la structure du feature model de sources par exemple.
En outre, rattacher la visualisation à la structure des feature models peut induiredes comportements non souhaités lors de leur évolution. Notre expérience sur Your-Cast nous a ainsi amenés à modifier profondément la structure du feature model deSources, sans pour autant vouloir modifier les informations et priorités de sélectionpour l’utilisateur final. L’évolution du feature model ne doit ainsi pas interférer avecl’interface de configuration présentée à l’utilisateur.
De manière symétrique, il est probable que l’interface de configuration évolue enfonction des retours des utilisateurs, sans pour autant que l’on souhaite modifier lesinformations contenues dans les features models. Par exemple, dans le cas des beha-viours nous considérons pour le moment toutes les informations au même niveau, sansdéfinir de priorité, proposant à l’utilisateur un arbre de critères pour réaliser sa confi-guration ; il est probable que cette interface évoluera afin de définir des priorités plusaisément compréhensibles par un utilisateur extérieur au domaine, tout en conservantidentique notre feature model de behaviours.
Ainsi, il nous semble particulièrement important de conserver une séparation claireentre les features models et la manière dont ils seront représentés dans une interface deconfiguration. Nous proposons donc un mécanisme d’annotation, utilisable à traversdes fichiers de configurations externes aux feature models, permettant d’enrichir ceux-ci automatiquement en leur apportant différentes informations.
65
4.1.1. Niveaux
Le premier besoin auquel doit pouvoir répondre notre système d’annotationconsiste à discriminer les features en niveaux. Comme nous l’avons décrit précédem-ment (cf. 3.1), nous avons identifié dans notre cas d’utilisation au maximum troisniveaux d’affichages et un "niveau" un peu particulier précisant de ne pas afficher lefeature.
Nous avons donc défini notre grammaire pour les fichiers d’annotation afin depouvoir associer un nom de feature à l’un de ces 4 niveaux en utilisant les mots cléssuivants :
– first : correspond au premier niveau d’affichage, permettant généralement de dis-criminer grossièrement les produits disponibles ;
– second : est associé au second niveau correspondant habituellement aux famillesde produits ;
– criteria : est associé au troisième niveau dit de critères : il s’agit du seul niveauayant une forme d’arbre permettant de fixer finement certains choix ;
– none : permet de ne pas afficher le feature.
Dans un même fichier d’annotation, il est possible d’utiliser n’importe quelle com-binaison de niveaux : leur dénomination n’implique aucune dépendance entre eux.Ainsi, si un utilisateur de l’outil souhaite afficher un niveau de discrimination puis unarbre de sélection, il utilisera les annotations first et criteria. Il n’y a, à l’heure actuelle,pas d’intérêt à utiliser le niveau second lorsque le niveau first n’est pas employé. Onpeut cependant imaginer sans peine des évolutions où son utilisation indépendanteferait sens dans le design de l’interface de configuration par exemple.
Les niveaux peuvent s’appliquer aussi bien sur les features feuilles que sur lesnoeuds : lorsqu’un niveau est appliqué à un noeud, les noeuds enfants hériteront mé-caniquement de la même valeur de niveau. Cependant il est possible de redéfinir lavaleur d’un noeud enfant en lui assignant son propre niveau dans le fichier d’annota-tion. Enfin, lorsqu’une feature ne possède aucune information de niveau de manièreexplicite ou de manière implicite par l’un de ses noeuds parents, elle prend le niveaunone par défaut.
4.1.2. Logos
Conformément au requis exprimé dans la sous-partie 3.2, notre système d’anno-tation doit également pouvoir permettre d’associer des images aux features afin derendre l’interface plus intuitive à l’utilisateur.
La mise en œuvre a consisté ici à enrichir la grammaire de nos annotations afin depermettre d’associer aux features une URL, correspondant à l’image que l’on souhaiteafficher pour cette feature. De la même façon que pour les niveaux, un logo associé àun noeud sera automatiquement répercuté à ses enfants si ceux-ci n’en disposent paseux-même. Enfin, si aucun logo n’est associé à une feature, celle-ci sera affichée ausein de l’interface de configuration avec une image par défaut.
66
SpineFMMoteur de
raisonnement
TocsinInterface de
Configuration
featuremodelssélections
Feature Models
Annotationsnotifications
IHM
Figure 4. Architecture globale du système
Nous avons par ailleurs pu rencontrer lors de notre mise en œuvre d’importantesdifficultés à trouver le ou les logos adéquats pour certaines features. Ainsi, dans lamajorité des cas, les seuls logos que nous avons attribués concernent les features desniveaux first et second. En outre, dans certains cas (renderers, behaviours ...), nousavons envisagé d’utiliser des images animées en guise de logo afin de pouvoir lesdistinguer aisément les uns des autres. Cette option doit cependant être davantageétudiée afin de déterminer si la présence d’un grand nombre d’images animées nerisquent pas de nuire à l’ergonomie du configurateur comme souligné dans (Nogier,2008).
4.1.3. Explications
Enfin, au sein de nos annotations, il est possible d’enrichir encore les features enleur associant une ou plusieurs explications (cf. 3.3). La mise en œuvre des explica-tions consiste simplement à ajouter une chaîne de caractères aux features.
4.2. Architecture d’un configurateur
L’architecture mise en œuvre pour supporter la mise en place des configurateursest illustrée par la figure 4. La figure nous montre que l’interface de configuration(nommée Tocsin) communique avec un moteur de raisonnement (appelé SpineFM)opérant sur des feature models. Sur la base d’un feature model et d’un fichier d’anno-tation, Tocsin génère automatiquement l’interface adaptée afin que l’utilisateur puisseréaliser la configuration qui lui convient.
Les opérations de sélection ou de déselection réalisées par l’utilisateur sont en-voyées de manière synchrone à SpineFM qui les applique sur sa propre représentationet calcule le FM résultant suite aux possibles contraintes internes. Ce FM est ensuite ànouveau renvoyé à Tocsin pour mettre à jour l’interface de configuration. Ce processusse répète jusqu’à obtention d’un produit dont la validité est déterminée par le moteurde raisonnement.
L’utilisation d’un processus synchrone dans notre approche résulte d’un choix dé-libéré afin d’empêcher l’utilisateur de violer des contraintes en réalisant plusieurs
67
opérations sans faire appel au moteur de raisonnement. Nous pallions l’inconvénientpotentiel de la lenteur de l’interface par un couplage fort, au sein d’une applicationdéployée dans un même service, des deux processus. Il va sans dire que d’avantagesd’études empiriques vont être réalisées afin de valider l’ergonomie de cette approche.
5. Discussions et autres travaux
Ce travail prend ses racines dans les travaux relatifs aux Lignes de produits etaux interfaces Homme-Machine. Les expérimentations menées nous ont confronté àdifférents problèmes présentés ci-après.
Dé-sélection de features La partie graphique reflète le contenu de la ligne. Ladé-sélection d’un feature peut entraîner la dé-sélection d’autres features. C’est la ligneelle-même qui gère les contraintes via SpineFM. L’interface graphique visualise alorsuniquement les features sélectionnables ou obligatoires. Ce choix permet de simpli-fier la configuration lorsque le nombre de features potentiels est grand. Néanmoins ladisparition de features peut perturber l’utilisateur, car cela va à l’encontre de l’homo-généité (ou la cohérence) de l’interface graphique (Bastien et al., 1993). Nous envi-sageons la mise en place de règles qui permettraient d’adapter l’IHM en fonction dunombre de features potentiels.
Explications par déduction Dans (Frey et al., 2012), les auteurs soulignentl’importance pour les utilisateurs d’obtenir des explications sur le comportement del’IHM elle-même. L’ajout d’explications exploitant les contraintes entre features pourprésenter les produits est un point qui devrait être pris en charge par l’IHM (Botter-weck et al., 2009, Paul et al., 2005) et ainsi de rester le plus comptatible possible avecle vocabulaire de l’utilisateur (Bastien et al., 1993).
Vocabulaires Lors de la définition des différents FM, nous avons fait des choixde vocabulaire en unifiant ou distinguant des termes, qu’il serait utile de mémoriserpour faciliter la compréhension de la ligne en compléments des explications. L’utili-sation d’ontologies pourrait être une façon de traiter ces questions (Czarnecki et al.,2006, Johansen et al., 2010).
Multi-niveaux de configuration Pour l’instant, nous considérons les configu-rations dans le contexte global de la ligne. A l’instar des auteurs de (Czarnecki etal., 2005), le besoin d’offrir différents niveaux de configuration est apparu pour, parexemple, offrir des outils de configuration n’offrant qu’un choix limités à certainessources d’informations dans le contexte de l’organisation de rassemblements nécessi-tant de la diffusion d’informations. Ce point devrait être étudié dans l’année à venir.
68
6. Conclusion et perspectives
Si les approches génériques en terme d’IHM sont décriées, la définition d’inter-faces sur mesure reste une tâche coûteuse et fastidieuse. Des travaux sont menés dansle cadre des lignes de produits afin de permettre la réalisation d’IHM de configurationutilisables pour des modèles de variabilité assez généraux (Boucher et al., 2012). CesIHM demandent cependant une certaine connaissance dans le domaine des lignes deproduits.
Nous proposons une démarche intermédiaire outillée visant à réaliser des IHM deconfiguration spécifiques à certains feature models, mais automatiquement adaptablesaux évolutions qu’ils peuvent ainsi suivre. Dans cette optique, nous avons abstraitcertaines propriétés, comme les niveaux de priorité, l’utilisation de logos et les ex-plications. Dans le cadre du projet ANR YourCast, qui vise à faciliter la création desystèmes de diffusion par des techniques de lignes de produits logiciels, ces propriétésnous ont semblé intéressantes à manipuler afin de définir une interface de configu-ration facile à prendre en main par un utilisateur. Cette abstraction se concrétise pardes annotations définies séparément des feature models afin de conserver une bonneséparation des préoccupations. Notre outillage génère ensuite automatiquement l’in-terface adaptée à partir de ces informations. Lors des sélections de configuration, cetteinterface communique de manière synchrone avec un moteur de raisonnement sur lesfeature models.
Les travaux que nous présentons ici consistent en un premier noyau que nous al-lons développer de manière incrémentale en fonction des besoins rencontrés. Ainsi,nous envisageons dès à présent un certain nombre d’évolutions. La grammaire des an-notations, tout d’abord, peut être améliorée afin d’apporter plus de flexibilité dans letraitement des feature models. Donner la possibilité de ne pas associer à la hiérarchied’un noeud le même niveau et/ou le même logo, par exemple, est une fonctionnalitédont nous ressentons dès à présent le besoin. De même, nous envisageons d’étendrele mécanisme d’explications aux contraintes afin de pouvoir expliquer à l’utilisateurla raison de l’action d’une contrainte, ce qui le conduira à mieux comprendre l’impactde ses choix.
Enfin, la validation de nos travaux a été effectuée par des personnes ayant à lafois une grande connaissance du domaine des Lignes de produits logiciels et notre casd’utilisation. Afin de valider et d’améliorer notre approche, une étude va être menéeauprès d’utilisateurs n’ayant aucune connaissance sur les lignes de produits logiciels,et ce avec l’intervention d’ergonomes.
Remerciements
Les auteurs remercient Laurence Duchien et Daniel Romero pour leur participa-tion au projet yourcast, leurs remarques et nos discussions toujours constructives.
69
7. Bibliographie
Bastien J. C., Scapin D. L., Ergonomic criteria for the evaluation of human-computer interfaces,Technical Report n˚ RT-0156, INRIA, June, 1993.
Bosch J., Högström M., « Product Instantiation in Software Product Lines : A Case Study »,in , G. Butler, , S. Jarzabek (eds), Generative and Component-Based Software Engineering,vol. 2177 of Lecture Notes in Computer Science, Springer Berlin / Heidelberg, p. 149-163,2001.
Botterweck G., Janota M., Schneeweiss D., « A design of a configurable feature model confi-gurator », VAMOS 2009, 2009.
Boucher Q., Perrouin G., Heymans P., « Deriving configuration interfaces from feature models :a vision paper », Proceedings of the Sixth International Workshop on Variability Modelingof Software-Intensive Systems, VaMoS ’12, ACM, New York, NY, USA, p. 37-44, 2012.
Coutaz J., Interfaces homme-ordinateur : conception et réalisation, Dunod, 1990. 455 pages.
Czarnecki K., Helsen S., Eisenecker U., « Staged configuration through specialization and mul-tilevel configuration of feature models », Software Process : Improvement and Practice, vol.10, n˚ 2, p. 143-169, 2005.
Czarnecki K., Kalleberg K., « Feature Models are Views on Ontologies », 10th InternationalSoftware Product Line Conference (SPLC’06), vol. 1, p. 41-51, 2006.
Frey A. G., Calvary G., Dupuy-Chessa S., « Users need your models ! Exploiting Design Modelsfor Explanations », Proceedings of HCI 2012, Human Computer Interaction, People andComputers XXVI, The 26th BCS HCI Group conference (Birmingham, UK), 2012.
Johansen M., Fleurey F., Acher M., « Exploring the Synergies Between Feature Models andOntologies », International Workshop on Model driven Approaches in Software ProductLine Engineering MAPLE 2010/SPLC10, vol. 2, 2010.
Myers B., Hudson S. E., Pausch R., « Past, present, and future of user interface software tools »,ACM Trans. Comput.-Hum. Interact., vol. 7, n˚ 1, p. 3-28, March, 2000.
Nogier J., Ergonomie du logiciel et design web - 4ème édition - Le manuel des interfaces utili-sateur : Le manuel des interfaces utilisateur, Etudes et développement, Dunod, 2008.
Paul K., Böckle G., Linden F. J., Software product Line Engineering : Foundation, Principlesand Techniques, hardcover edn, Springer, 2005.
Urli S., Blay-fornarino M., Collet P., « Using Composite Feature Models to Support AgileSoftware Product Line Evolution », Models and Evolution, 2012.
70
Vers des Workflows Configurables et Stan-dardisés : Premières Expériences
Quentin Boucher*, 1 — Jacques Flamand**
Marc Thunissen** — Jean-Christophe Deprez***
* Centre de Recherche PReCISE, Faculté d’Informatique, Université de NamurNamur, [email protected]
** Océ Software Laboratories Namur, Canon GroupGembloux, Belgique{jacques.flamand, marc.thunissen}@oce.com
*** Centre d’Excellence en Technologies de l’Information et de la CommunicationCharleroi, [email protected]
RÉSUMÉ. Le projet NAPLES vise à supporter les processus de développement logiciel des PMEsen maximisant la réutilisation de ceux-ci. Cet objectif s’inscrit dans l’effort de standardisationque l’ISO mène actuellement pour ce type d’entreprise, en proposant différents niveaux de ma-turité des processus de développement en fonctions de besoins. Néanmoins le support de tellesnormes, ainsi que leur adaptation, sont complexes à mettre en œuvre dans de petites struc-tures. Dans cet article, nous expliquons comment la notion de workflow configurable permet defournir à la fois le respect de la norme et une adaptation intuitive aux besoins des PMEs vial’utilisation de questionnaires. Nous présentons ici deux expériences illustrant cette approche.
ABSTRACT. The NAPLES project aims at supporting software development processes in VSEs bypromoting reuse. This goal is part of the trend initiated by the ISO which proposes differentmaturity levels depending on the needs of VSEs. Nevertheless, implementing and adapting suchstandards might prove difficult for small entities. In this paper, we explain how the notion ofconfigurable workflow allows to follow the standard while being easily adaptable to customers’needs through questionnaires. We present two experiments illustrating our approach.
MOTS-CLÉS : Workflow, Mise en œuvre, Configuration, Variabilité
KEYWORDS: Workflow, Operationalization, Configuration, Variability
1. Personne de contact
71
1. Introduction
La pression du marché pousse les firmes de développement logiciel à améliorerleur productivité tout en veillant à la qualité des solutions délivrées aux clients. Laréutilisation d’artefacts et un meilleur processus de développement, notamment, per-mettent de répondre à cette demande. Néanmoins, la mise en place d’un processusde développement logiciel dans une entreprise ou une structure est coûteux, surtout sil’entreprise est petite et désire faire certifier son processus. A cette fin, l’ISO s’est in-téressée à ces petites structures en définissant une norme, l’ISO/IEC 29110 [ISO 11],légère et adaptable à leurs besoins spécifiques. Néanmoins sans support, il est difficilede suivre systématiquement de tels processus et encore plus de les certifier. De plus,la personnalisation demande une expertise parfaite de la norme ce qui est rarement lecas dans ces structures.
L’objectif du projet NAPLES1 est d’améliorer cette situation, notamment en im-plantant des workflows dans lesquels l’utilisateur pourra, selon ses besoins, facilementpersonnaliser les séquences de tâches tout en favorisant la réutilisation d’élément exis-tants.
Dans cet article, nous nous concentrons sur l’opérationnalisation des workflowsde manière à ce qu’ils soient directement exploitables par des entités relativement pe-tites. Après une première expérience pour construire des workflows personnalisablesrespectueux de la variabilité exprimée dans la norme, nous nous proposons ici de sefocaliser sur une approche plus intégrée se basant sur le moteur de workflow Bonita2.En outre, notre approche permet de guider l’utilisateur dans la configuration de ceworkflow grâce à un questionnaire. Les réponses collectées sont ensuite stockées dansune base de données et utilisées pour guider l’exécution des workflows.
L’article est structuré comme suit. La Section 2 décrit le contexte dans lequel cetterecherche prend place, notamment en donnant plus de détails sur l’état actuel du pro-jet NAPLES. La Section 3 présente une première expérience de capture de la normeISO/IEC 29110 dans un workflow configurable. Ensuite, dans la Section 4, nous pro-posons notre nouvelle solution. Les réalisations actuelles et les challenges restants sontensuite discutés dans la Section 5. Finalement, les recherches connexes sont mention-nées Section 6 avant de conclure en Section 7.
2. Contexte
NAPLES est l’acronyme de “New Agile Platform for a Lifelong Engineering ofSoftware". Ce projet vise à développer une plateforme outillée et intégrée encoura-geant et facilitant la réutilisation de composants tout au long du cycle de vie du lo-giciel. Parmi les objectifs, un nous intéresse plus particulièrement dans cet article,“promouvoir un travail de développement logiciel orienté “workflow", dans le sens
1. http://www.cetic.be/NAPLES2. http://www.bonitasoft.com/
72
ou chaque partie-prenante doit être capable de sélectionner et personnaliser des sé-quences de tâches provenant de pratiques reconnues. Ce processus sera soutenu parun outillage adéquat en particulier au niveau des outils de génie logiciel et de l’envi-ronnement IT."3.
Concrètement, cette tâche nous a conduit à élaborer des workflows correspondantaux pratiques communément admises dans le domaine et notamment en cours de stan-dardisation dans le cadre de la norme ISO/IEC 29110. Nous avons donc traduit desworkflows appartenant à des processus tels que la gestion de projet, gestion des exi-gences, et implémentation du logiciel dans un outil donné, à savoir Bonita. Cet outil anotamment été choisi parce qu’il existe une version gratuite et open source. Cela per-met notamment aux futurs utilisateurs de NAPLES de limiter les coûts tout en gardantla possibilité de migrer vers une version payante offrant plus de fonctionnalités. Néan-moins, Bonita ne supporte pas la configuration des workflows, exigence fixée pour laplateforme NAPLES.
3. Workflows Configurables
Précédemment [BOU 12c], nous avons donc proposé une première approche deconfiguration des workflows illustrée par la norme ISO/IEC 29110. Cette approcherepose principalement sur les workflows configurables [GOT 08] qui adoptent une vi-sion ligne de produits à la modélisation des workflows. Plus précisément, nous avonsappliqué la suite d’outils Synergia [ROS 09] au workflow d’ingénierie des exigencesde la norme ISO/IEC 29110. L’approche se décompose en 4 phases : (1) Identifica-tion de la variabilité dans le workflow et représentation de celui-ci dans le moteur deworkflow YAWL [HOF 10] ; (2) Définition d’un questionnaire permettant de configu-rer les points de variation du workflow ; (3) Définition des liens entre les réponses duquestionnaire et les points de variabilité ; (4) Réponse aux questions par l’utilisateurfinal. Ces réponses sont ensuite utilisées pour individualiser le workflow. Le résultatest un workflow YAWL sans aucune variabilité. Chacune de ces étapes est supportéepar un outil de la suite Synergia [ROS 09].
Cette approche a reçu un accueil favorable des partenaires du consortium NAPLESainsi que des membres de la communauté EuroSPI, active dans l’amélioration desprocessus4. Cependant, elle n’est pas directement exploitable dans le projet NAPLESpour deux raisons. Premièrement, comme précédemment mentionné, l’outil Bonita aété choisi pour implémenter les workflows du projet. Or il s’avère que Bonita ne pos-sède pas d’API permettant d’individualiser les workflows. Ensuite, l’approche initialebasée sur Synergia ne permet pas d’effectuer de modifications du workflow une foisque celui-ci est en cours d’exécution. En effet, une fois que le workflow a été indivi-dualisé, les tâches non requises ont été enlevées de celui-ci et ne sont plus accessibles,même si l’utilisateur change d’avis. Ces deux faiblesses nous ont amené à proposer
3. http://www.cetic.be/NAPLES4. http://www.eurospi.net/
73
une nouvelle approche plus flexible et plus intégrée qui est détaillée dans la sectionsuivante.
4. Configuration de Workflows Bonita
Pour résoudre les problèmes posés par l’approche basée sur la suite d’outils Sy-nergia, nous avons élaboré une solution spécifique. Cette nouvelle approche est assezsimilaire à celle précédemment proposée. Elle est elle aussi découpée en 4 étapes.
Tout d’abord, l’utilisateur doit identifier la variabilité incluse dans le workflow et lereprésenter dans le moteur de workflow Bonita. Cependant, vu que Bonita ne proposepas de tâches configurables (i.e. qui peuvent être désactivées en fonction des préfé-rences de l’utilisateur), les liens entre les tâches sont marqués par des conditions surles valeurs de certaines variables. L’utilisateur doit donc, pour chaque valeur possibled’une variable, marquer le chemin correspondant dans le workflow.
Une fois que le workflow et ses points de variation ont été définis, un question-naire doit être élaboré afin de configurer ceux-ci. Bonita fournit, de manière similaireà l’outil Questionnaire Designer de la suite Synergia, un éditeur de formulaires quipermet, entre autres, de créer des questionnaires. Cependant, contrairement à Ques-tionnaire Designer, Bonita ne permet pas de définir de liens de dépendance entre lesdifférentes questions et/ou réponses. Une question peut en effet n’avoir de sens quesi une réponse spécifique à une autre question a été sélectionnée. Un exemple simpledans la gestion d’un projet est le fait d’envoyer un rapport de réunion au client ou non.Répondre à cette question n’a de sens que si, dans une précédente question qui nousproposait de tenir le client informé de l’état d’avancement du projet soit “en direct”,soit par des rapports mensuels, la première réponse a été sélectionnée. Pour comblerce manque dans Bonita, nous proposons de nous reposer sur les modèles de caracté-ristiques [KAN 90], et plus particulièrement le langage TVL [BOU 10, CLA 11] et leraisonneur associé. Concrètement, le questionnaire devra être représenté comme unmodèle de caractéristiques sur lequel le raisonneur pourra effectuer son travail. Lacréation de ce modèle par l’utilisateur peut être vue comme une tâche supplémentaireà la création du questionnaire. Cependant, nous menons actuellement des recherchespour arriver à générer semi-automatiquement des interfaces de configuration à partirdes modèles de caractéristiques [BOU 12a, BOU 12c]. L’idée est, à partir d’un mo-dèle de caractéristiques et d’un fichier associé de type CSS permettant de fournir desdonnées spécifiques à l’interface graphique, de dériver le questionnaire de configura-tion qui sera connecté au raisonneur. Les interactions entre l’interface et le raisonneurTVL sont illustrées à la Figure 1. Chaque fois que l’utilisateur effectue un choix dansle questionnaire, celui-ci est détecté par le contrôleur, un JavaScript par exemple, 1qui traduit l’information pour le raisonneur et la lui transmet 2 . Le raisonneur met àjour le modèle de caractéristiques sous-jacent 3 , ce qui va potentiellement engendrerla mise à jour d’autres caractéristiques 4 . Une fois son travail effectué, le raisonneurenvoie la liste des caractéristiques modifiées au contrôleur 5 qui va mettre l’inter-
74
face graphique à jour en conséquence 6 , empêchant ainsi l’utilisateur d’effectuer deschoix incohérents.
Action utilisateurMettre à jour modèlede caractéristiques
NotifierMettre à jour IHMPropager
changementsChangements
API de Configuration
RaisonneurTVL
Couche RaisonnementCouche ContrôleCouche Présentation
ContrôleurIHM
Modèle de caractéristiques
Traduire
1 2
34
56
Figure 1 – Architecture Modèle-Vue-Contrôleur de l’Interface Graphique
Lors de la troisième étape, un lien doit être établi entre les réponses au question-naire et les variables utilisées par le workflow. Pour l’instant, nous avons choisi d’uti-liser une base de données. Chaque réponse au questionnaire permet de donner unevaleur aux variables marquant les transitions dans le workflow. Lors de l’exécution duworkflow, un script appelé par Bonita viendra récupérer la valeur des variables danscette même base de données et orienter le cours du workflow en conséquence. Aveccette nouvelle approche, le lien entre le questionnaire et le workflow est plus facile àmettre en place qu’avec la suite d’outils Synergia dans laquelle il fallait, pour chaqueétat d’une réponse (i.e. sélectionné et non-sélectionné), définir le lien avec les tâchesimpliquées. Avec la précédente approche, il y avait 2n liens à définir par question, nreprésentant le nombre de réponses possibles à une question donnée.
Finalement, la dernière étape consiste à répondre au questionnaire et exécuter leworkflow. Contrairement à la première approche, aucune tâche n’a été supprimée dece dernier. Cela permettra, notamment, à l’utilisateur de revenir sur les choix effectuésdans le questionnaire si celui-ci se rend compte, en cours d’exécution du workflow, quecertains choix ne sont pas adéquats. Cependant, la modification des variables nécessitedes vérifications supplémentaires qui seront discutées à la fin de la prochaine section.
5. Réalisations et Défis
Ici nous illustrons la configuration de workflows avec Bonita sur un cas concret.Ensuite, un certain nombre de défis sont abordés.
75
5.1. Mise en pratique
La Figure 2 représente le workflow correspondant à la planification d’un projet.Nous pouvons y noter la présence de huit variables. Quatre d’entre elles seulementsont associées à la configuration du workflow par l’intermédiaire du questionnaire,à savoir les deux associées à la tâche GetStatementWorkReview et les deux autresattachées à GetProjectPlanReview. La valeur des autres variables sont définies lorsde l’exécution des tâches auxquelles elles sont attachées, i.e. getparallelworkflowet Project Plan Review by Customer.
Le modèle de caractéristiques correspondant au questionnaire exprimé dans le lan-gage TVL [BOU 10, CLA 11] est le suivant :
1 roo t Tune {2 PPR_Meeting !> IMRT ;3 SWR_Meeting !> IMRT ;4 RSMC_No !> RATC_Yes ;5 group a l l o f {6 SWR group oneof {SWR_Immediate , SWR_Meeting } ,7 PPR group oneof { PPR_Immediate , PPR_Meeting } ,8 opt IMRT group oneof { S p e c i f i c , S t a n d a r d } ,9 RAT group oneof {QC, Redmine } ,
10 opt RAW group oneof {OSL} ,11 RSMC group oneof {RSMC_No, RSMC_Yes} ,12 RATC group oneof {RATC_No , RATC_Yes } ,13 PW group oneof {PW_No, PW_Yes}14 }15 }
Dans ce modèle, seule la caractéristique SWR et ses sous-caractéristiques, i.e. SWR_-Immediate et SWR_Meeting, sont utilisées dans le workflow de la Figure 2. Bien quedes abréviations aient été utilisées dans le modèle, la correspondance avec les variablesdu workflow est assez directe. Les autres caractéristiques et sous-caractéristiques duworkflow correspondent à des variables d’autres workflows qui ne sont pas pertinentesici. Nous sommes conscients que le modèle de caractéristiques n’est pas directementutilisable pour générer l’interface de configuration, raison pour laquelle nous avonsproposé [BOU 12a] d’associer des fichiers de type CSS permettant de guider cettegénération. Ces fichiers contiendront, par exemple, des textes pour les étiquettes del’interface plus lisibles que le nom des caractéristiques du modèle TVL. Nous avons,dans un premier temps, défini l’interface graphique manuellement (Figure 3). Derrièrecette interface se trouve un script qui, à chaque changement d’une option va récupé-rer sa valeur et l’envoyer au raisonneur TVL. Ce dernier va lui retourner la liste descaractéristiques touchées par le changement. Le script devra alors, pour chaque carac-téristique impactée, retrouver l’élément d’interface qui lui correspond afin de mettresa valeur à jour, de la désactiver,. . . Cette correspondance entre les caractéristiqueset les objets de l’interface peut, notamment, être établie en utilisant l’identifiant descaractéristiques comme identifiant des objets graphiques correspondants.
76
Figure 2 – Workflow de la planification d’un projet
77
Figure 3 – Interface graphique du questionnaire
Les deux dernières étapes peuvent, quant à elles, être facilement rendues opéra-tionnelles. La connexion entre le questionnaire et les workflows est, comme précé-demment expliqué, réalisée via une base de données. Il suffit donc d’y enregistrer lesvaleurs du questionnaire une fois que celui-ci a été validé par le raisonneur TVL etl’utilisateur. Nous ne détaillerons pas cette étape ici vu qu’il s’agit simplement d’ins-tancier des valeurs dans une base de données. Finalement, l’exécution du workflowest gérée par Bonita qui va automatiquement aller chercher les valeurs requises dansla base de données.
5.2. Défis
L’approche proposée à la Section 4 est, à l’heure actuelle, partiellement implémen-tée. Les workflows et variables associées ont été définis dans Bonita et la connexionentre le questionnaire, le raisonneur TVL et la base de données est établie. Par contre,l’interface graphique n’a pas été générée. En effet, nous avons préféré la construirenous-même à la main afin de valider le concept auprès de nos partenaires dans leconsortium NAPLES. Il est évident que, par la suite, cette interface sera générée. Pourcela, nous devrons d’abord résoudre les défis posés par une telle entreprise. Ceux-ciont déjà été préalablement identifiés [BOU 12b].
L’utilisation du raisonneur TVL nous permet de garantir une certaine cohérenceentre les réponses fournies par l’utilisateur. De cette manière, nous pouvons assurerque les variables introduites dans la base de données (et utilisées à l’exécution parle workflow) sont correctes. Cependant, cette approche ne nous permet pas de véri-fier que, pour les variables enregistrées, l’exécution du workflow se déroulera sans
78
problème. Nous devons encore explorer ce type de vérification. A cette fin, nouspouvons notamment nous reposer sur les workflows de configuration de caractéris-tiques [HUB 09].
Un des avantages de la nouvelle approche est que, contrairement à la premièreversion, elle permet, théoriquement, de revenir sur certaines décisions. Cette fonc-tionnalité n’est cependant pas encore disponible car elle requiert des analyses supplé-mentaires. En effet, avant de changer une décision, il faut vérifier l’impact d’un telchangement sur les autres variables. Par exemple, si une variable touchée par ce chan-gement a un impact sur une tâche du workflow qui a déjà été effectuée, le changementde décision devrait être impossible. Avant de mettre en œuvre un tel mécanisme, nousdevrons étudier tous les cas (problématiques) qui pourraient se présenter.
6. Recherches Connexes
Les workflows configurables [GOT 08, ROS 09] constituent potentiellement unebonne option pour l’implémentation des workflows dans le projet NAPLES. Cepen-dant, comme cela a été mentionné dans la Section 3, une telle approche n’est pascompatible avec le moteur de workflow choisi pour le projet (Bonita). En outre, unetelle approche supprimant les tâches correspondant à des options non sélectionnées,empêche de modifier les choix précédemment effectués lors de l’exécution du work-flow.
Desclaux et al. [DES 12] proposent également d’utiliser conjointement les work-flows avec les modèles de variabilité. Leur but diffère du nôtre vu qu’ils cherchentà générer des workflows à partir de modèles de variabilité, tandis que nous utilisonsles modèles de variabilité pour vérifier que les choix effectués par l’utilisateur pourconfigurer un workflow sont cohérents. L’approche de Desclaux et al. peut être vuecomme compositionnelle (le workflow est créé en connectant un ensemble de compo-sants) alors que la nôtre est annotative (workflow complet duquel on élague les tâchesnon requises) [KÄS 08a, KÄS 08b]. Les mêmes conclusions s’appliquent aux travauxde Mosser et al. [MOS 10] qui utilisent également une approche compositionnelle.
L’Ingénierie des Méthodes (IM) de situation se concentre également sur l’adap-tation des méthodes au contexte [BRI 96]. Celle-ci propose généralement de com-biner différents fragments de méthodes se trouvant dans une base commune de mé-thodes [HEN 10]. Parfois, seul un fragment de la méthode est changé, ainsi appeléIM incrémentiel. Evidemment, ce fragment est généralement adapté à la situation spé-cifique afin d’améliorer les performances générales de la méthode. Une autre façonde gérer la variabilité est d’introduire des points de variation dans la méthode elle-même. C’est l’approche adoptée par l’ISO/IEC et ses différents profils. Ensuite, il estpossible d’effectuer une configuration des méthodes [KAR 04] en personnalisant uneméthode existante. Cette approche pourrait, par conséquent, également être appliquéepour personnaliser les processus tels que définis pat l’ISO/IEC.
79
Au fil du temps, différents outils d’IM tels que MetaEdit+ [KEL 96] ont été déve-loppés pour aider les ingénieurs dans leur activité de personnalisation des méthodes.Cependant, comme cela a été mentionné par Cerva et al. [CER 10], très peu d’ou-tils, excepté MetaEdit+, ont atteint un niveau de maturité suffisant pour l’industrie. Deplus, les industriels considèrent généralement que les coûts liés à l’application de l’IMde situation sont largement supérieurs à ceux engendrés par l’utilisation de méthodes“prises sur étagère" [HEN 10].
Dans notre cas où, pour rappel, les petites entreprises sont visées, d’autres pro-blèmes apparaissent. Parmi eux, nous pouvons notamment mentionner le prix des ou-tils d’IM. Cela va à l’encontre d’un des objectifs du projet NAPLES qui est de fournirune approche à faible coûts pour ces entités. De plus, ces entités ne disposent généra-lement pas, en interne, des compétences suffisantes en IM, ce qui pourrait notammentconduire à des erreurs de modélisation.
7. Conclusions
Dans cet article nous avons proposé une approche permettant de configurer unworkflow par l’intermédiaire d’un questionnaire. Cette approche, basée sur une autreque nous avions précédemment développée, se décompose en quatre phases. La pre-mière consiste à définir le workflow et ses points de variabilité. Dans la deuxième,le modèle de variabilité d’un questionnaire correspondant aux points de variabilitédu workflow est défini. Ce modèle sera utilisé pour vérifier les contraintes entre lesdifférentes options mais également pour générer le questionnaire. La connexion entrele workflow et le questionnaire est mise en place lors de la troisième étape, les va-riables correspondant aux points de variation étant stockés dans une base de donnéescommune. Finalement, lors de l’exécution, l’utilisateur répond au questionnaire et lemoteur de workflow ira, automatiquement, rechercher les variables correspondantesstockées dans la base de données.
L’approche a été présentée en utilisant le moteur de workflows Bonita mais pour-rait facilement être adaptée à d’autres outils concurrents. Bonita a été utilisé car c’estl’outil qui a été choisi par les partenaires du consortium NAPLES.
L’approche n’est que partiellement implémentée dans le cadre du projet NAPLES,laissant de la place pour de futurs travaux. A l’avenir, nous devrons notamment d’abordmettre en œuvre notre approche de génération d’interfaces. Pour cela, nous devronsnotamment sélectionner le bon langage pour nos interfaces graphiques. Nous devronségalement nous pencher sur la vérification des workflows afin de s’assurer que ceux-cipeuvent être correctement exécutés avec les variables stockées dans la base de don-nées. La modification des décisions précédemment prises et leur impact est un autredomaine que nous devrons explorer. Finalement, il est évident que l’ensemble de ceséléments devra être évalué auprès des utilisateurs-pilotes du projet NAPLES.
80
Remerciements
Nous tenons à remercier Gilles Perrouin pour les commentaires constructifs reçuslors de la rédaction du présent article. Nos remerciements vont également à ChristophEvers pour le support technique fourni lors de la mise en œuvre des interactions entrele questionnaire et le raisonneur TVL. Cette recherche est financée par la Wallonie viale partenariat d’innovation technologique NAPLES.
8. Bibliographie
[BOU 10] BOUCHER Q., CLASSEN A., FABER P., HEYMANS P., « Introducing TVL, a Text-based Feature Modelling Language », VaMoS’10, University of Duisburg-Essen, January2010, p. 159–162.
[BOU 12a] BOUCHER Q., ABBASI E. K., HUBAUX A., PERROUIN G., ACHER M., HEY-MANS P., « Towards More Reliable Configurators : A Re-engineering Perspective », Pro-ceedings of the 3rd Product LinE Approaches in Software Engineering (PLEASE’12), 2012,p. 29-32.
[BOU 12b] BOUCHER Q., PERROUIN G., DEPREZ J.-C., HEYMANS P., « Towards Confi-gurable ISO/IEC 29110-Compliant Software Development Processes for Very Small Enti-ties », EuroSPI, Springer, 2012, p. 169-180.
[BOU 12c] BOUCHER Q., PERROUIN G., HEYMANS P., « Deriving Configuration Interfacesfrom Feature Models : A Vision Paper », Proceedings of VaMoS’12, ACM, 2012, p. 37–44.
[BRI 96] BRINKKEMPER S., « Method engineering : engineering of information systems de-velopment methods and tools », Information and Software Technology, vol. 38, no 4, 1996,p. 275–280, Elsevier.
[CER 10] CERVERA M., ALBERT M., TORRES V., PELECHANO V., « A MethodologicalFramework and Software Infrastructure for the Construction of Software Production Me-thods », Proceedings of ICSP’10, Springer, 2010, p. 112-125.
[CLA 11] CLASSEN A., BOUCHER Q., HEYMANS P., « A text-based approach to feature mo-delling : Syntax and semantics of TVL », Sci. Comput. Program., vol. 76, 2011, p. 1130–1143, Elsevier North-Holland, Inc.
[DES 12] DESCLAUX C., URLI S., BLAY-FORNARINO M., FARON-ZUCKER C., « Vers laconstruction de workflows pour le filtrage sémantique de nouvelles », Conférence en Ingé-nieriE du Logiciel(CIEL 2012), , 2012, p. 1-6.
[GOT 08] GOTTSCHALK F., AALST W. V. D., JANSEN-VULLERS M. H., ROSA M. L.,« Configurable workflow models », International Journal of Cooperative Information Sys-tems, vol. 17, no 2, 2008, p. 177–221, World Scientific Publishing Co. Pty. Ltd, 5 TohTuck Link, 596224, Singapore.
[HEN 10] HENDERSON-SELLERS B., RALYTÉ J., « Situational method engineering : state-of-the-art review », Journal of Universal Computer Science, vol. 16, no 3, 2010, p. 424–478.
[HOF 10] TER HOFSTEDE A. H. M., VAN DER AALST W. M. P., ADAMS M., RUSSELL N.,Modern Business Process Automation - YAWL and its Support Environment, Springer, 2010.
[HUB 09] HUBAUX A., CLASSEN A., HEYMANS P., « Formal modelling of feature configu-ration workflows », Proceedings of SPLC’09, 2009, p. 221-230.
81
[ISO 11] ISO-INTERNATIONAL STANDARD ORGANISATION, « ISO29110 – Lifecycle Pro-files for Very Small Entities 2011 », Standard, 2011.
[KAN 90] KANG K., COHEN S., HESS J., NOVAK W., PETERSON S., « Feature-OrientedDomain Analysis (FODA) Feasibility Study », rapport no CMU/SEI-90-TR-21, November1990, SEI, Carnegie Mellon University.
[KAR 04] KARLSSON F., AGERFALK P., « Method configuration : adapting to situational cha-racteristics while creating reusable assets », Information and Software Technology, vol. 46,no 9, 2004, p. 619 - 633.
[KÄS 08a] KÄSTNER C., APEL S., « Integrating Compositional and Annotative Approachesfor Product Line Engineering », Proceedings of McGPLE’08, University of Passau, 2008,p. 35–40.
[KÄS 08b] KÄSTNER C., APEL S., KUHLEMANN M., « Granularity in software productlines », Proceedings of ICSE’08, ACM, 2008, p. 311-320.
[KEL 96] KELLY S., LYYTINEN K., ROSSI M., « METAEDIT+ A fully configurable Multi-User and Multi-tool CASE and CAME Environment », Proceedings of CAiSE’96, Springer,1996, p. 1–21.
[MOS 10] MOSSER S., BLAY-FORNARINO M., FRANCE R. B., « Workflow Design UsingFragment Composition - Crisis Management System Design through ADORE », T. Aspect-Oriented Software Development, vol. 7, 2010, p. 200-233, Springer.
[ROS 09] ROSA M. L., GOTTSCHALK F., « Synergia - Comprehensive Tool Support for Confi-gurable Process Models », BPM (Demos), 2009.
82
Vers un Outil de Configuration et de Déploie-ment pour les Nuages
Clément Quinton — Laurence Duchien
Inria Lille - Nord EuropeLIFL UMR CNRS 8022University Lille 1, France
RÉSUMÉ. L’informatique dans les nuages est une tendance actuelle majeure pour répartir lestraitements et les données de façon virtuelle sur des environnements d’exécution paramétrables.Le développement et le déploiement de logiciels pour les nuages proposent un nouveau chal-lenge scientifique en termes d’expression et de prise en compte de la variabilité. En effet, l’infor-matique dans les nuages repose sur des principes d’hétérogénéité et d’élasticité, ce qui permetde nombreux choix de configuration et de dimensionnement. Les Modèles de Caractéristiques(MC) issus de l’approche Ligne de Produits Logiciels (LPL) sont une réponse possible pourgérer cette variabilité, préparer et dimensionner des configurations à déployer dans les nuages.Dans cet article, nous introduisons SALOON, un cadre logiciel d’expression de la variabilitéet d’aide à la décision pour configurer et dimensionner des applications à déployer dans lesnuages. Basé sur des ontologies et des MCS étendus, il prend en compte les aspects techniqueset non-fonctionnels de l’application pour trouver un fournisseur de nuages qui correspond aumieux à la configuration de l’application.
ABSTRACT. Cloud Computing is a major trend in distributed computing environments enablingsoftware virtualization on configurable runtime platforms. Development and deployment ofCloud software systems result in new challenges to express and manage their intrinsic variabil-ity. Many configuration and customization choices arise due to the heterogeneous and scalableaspect of the Cloud Computing paradigm. Features Model originating from Software ProductLine (SPL) approach is one way to handle this variability, manage, create and deploy configura-tion in the Cloud. In this paper, we introduce SALOON, a framework to configure and describevariability for applications to be deployed in the Cloud. Based on ontologies and extended fea-tures models, SALOON takes application’s technical and non-functional requirements intoconsideration to provide the most appropriate cloud solutions.
MOTS-CLÉS : Informatique dans les Nuages, Ligne de Produits Logiciels, Ontologie, Modèle deCaractéristiques Étendu
KEYWORDS: Cloud Computing, Software Product Line, Ontology, Extended Feature Model
83
2 Journée Lignes de Produits 2012
1. Introduction
L’informatique dans les nuages (Cloud Computing) est une tendance majeure dansles environnements d’informatique répartie qui permet d’accéder à des ressources vir-tuelles configurables (e.g., serveurs, espace de stockage, réseaux) sous forme de ser-vices délivrés à la demande par les fournisseurs de Cloud [MEL 09]. Pour être ac-cessible en tant que service (Software-as-a-Service, SaaS) sur le Cloud, une applica-tion peut être déployée soit sur l’infrastructure (Infrastructure-as-a-Service, IaaS) dufournisseur de Cloud, soit sur la plateforme qui va l’exécuter (Platform-as-a-Service,PaaS). Dans les deux cas, il faut configurer et dimensionner l’environnement d’exé-cution de l’application pour prendre en compte l’hétérogénéité et l’élasticité inhé-rentes au paradigme du Cloud Computing. En effet, il existe un grand nombre deressources ayant des niveaux de fonctionnalité et des possibilités de dimensionnementhétérogènes parmi les différentes solutions de cloud disponibles (Amazon EC2, Je-lastic, CloudBees, taille de l’instance, etc.). Lors d’un déploiement d’application surun PaaS, il faut sélectionner un serveur d’application, la fréquence CPU nécessaire àl’exécution, la base de données à utiliser, sa capacité, etc. Il en va de même pour ledéploiement sur un IaaS qui nécessite la configuration de toute la pile logicielle (sys-tème d’exploitation, librairies, serveurs d’applications) qui supporte l’application etqui s’exécute sur l’infrastructure du fournisseur de cloud. Cette variabilité en termesde configuration et de dimensionnement offre une multitude de possibilités de confi-gurations qui sont généralement effectuées de manière ad hoc et sont sources d’erreurslorsqu’elles sont réalisées à la main.
Nous pensons que cette sélection peut être en partie guidée et automatisée enutilisant des outils issus de l’approche Ligne de Produits Logiciels (LPL) [CLE 01,POH 05] et de définition d’ontologies [GRU 93]. Les LPLs permettent la description,la gestion et le développement de logiciels qui partagent un ensemble de caractéris-tiques communes mais qui diffèrent en certains points de variabilité, formant ainsi unefamille de produits logiciels. Une approche bien connue pour modéliser la variabilitérepose sur l’utilisation des Modèles de Caractéristiques (MC) proposés par [KAN 90]dans son étude Feature Oriented Domain Analysis (FODA). La variabilité des envi-ronnements de Cloud Computing peut ainsi être représentée par des MCS et le di-mensionnement de la configuration est effectué par le biais d’attributs qui étendent leMC [BEN 05]. De plus, nous proposons d’utiliser les ontologies [GRU 93] commemodèle de données représentatif du domaine du Cloud Computing pour en décrire lesconcepts, les relations entre ces concepts et leur sémantique. Différentes caractéris-tiques de Cloud peuvent ainsi être capturées sous le même concept. En définissant ledomaine, les points communs, les points de variabilité et la famille de produits à déri-ver, nous décrivons les principaux objectifs du processus d’ingénierie du domaine desLPLs [POH 05] appliqué au Cloud, et donnons une ébauche du processus d’ingénieriede l’application en expliquant le processus de configuration. De plus, nous propo-sons d’utiliser les ontologies comme modèle de données représentatif du domaine duCloud Computing pour en décrire les concepts, les relations entre ces concepts et leursémantique. Dans cet article, nous présentons donc une approche basée sur l’utilisa-tion d’ontologies et de MCS étendus pour identifier le(s) fournisseur(s) de Cloud qui
84
Vers un Outil de Déploiement pour les Nuages 3
permettent de déployer l’application et de choisir parmi les solutions possibles cellequi répond aux exigences techniques de la configuration et au dimensionnement deces exigences.
La structure de l’article est la suivante. Dans la SEC. 2, nous décrivons quels sontles problèmes liés au déploiement dans le Cloud et les challenges auxquels font faceles acteurs du Cloud. La SEC. 3 présente SALOON, l’approche basée sur les ontolo-gies et les MCS pour choisir son fournisseur de Cloud. Dans la SEC. 4, nous donnonsles détails d’implémentation et discutons des limitations de l’approche. La SEC. 5évoque les travaux connexes tandis que la SEC. 6 conclut cet article.
2. Motivations & Challenges
Le déploiement d’une application dans le Cloud offre à son propriétaire de nom-breux avantages : réduction des coûts, passage à l’échelle, haute disponibilité, etc.Cependant, la migration d’une application ou le développement d’un nouveau servicedans le Cloud n’est pas trivial. En effet, il existe un grand nombre de possibilités aumoment de choisir le fournisseur de Cloud capable de fournir l’environnement pourhéberger l’application en tant que service. Ainsi, certains utilisateurs préfèrent dé-ployer leur application vers une solution de Cloud qu’ils ont déjà utilisée mais qui necorrespond pas complètement aux exigences de l’application à déployer (e.g., chan-ger de type de base de données) plutôt que de se risquer à configurer un PaaS ou unIaaS pourtant plus adapté à leurs exigences. Le Cloud offre de nombreux choix deconfiguration et de dimensionnement tant au niveau de l’application à déployer quedes environnements d’exécution IaaS ou PaaS paramétrables (FIG. 1). Il est donc trèsdifficile de prendre les bonnes décisions face aux questions suivantes : faut-il privilé-gier un déploiement niveau PaaS ? IaaS ? Quel fournisseur choisir ? Comment être sûrqu’il représente une bonne solution pour les types d’applications et de déploiementssouhaités ?
Figure 1. Les différentes couches du Cloud Computing1
À notre connaissance, il n’existe pas à l’heure actuelle d’outil d’aide à la configu-ration et au dimensionnement permettant de choisir finement le fournisseur de Cloudidéal, ou du moins le plus en adéquation avec l’environnement technique et non-fonctionnel de l’application. Aujourd’hui, ce choix repose sur les connaissances des
1. http://blog.gravitant.com/wp-content/uploads/2012/07/CloudTechSpectrum_Vendors_v21.png
85
4 Journée Lignes de Produits 2012
experts en Cloud Computing et soulève le problème de la fiabilité et de l’exhausti-vité de cette connaissance. Le cadre logiciel présenté dans cet article est une solutionproposée pour concevoir un outil de configuration et de déploiement dans le Cloud.Il a pour objectif de relever deux challenges auxquels sont confrontés tous les acteursconcernés par un déploiement dans le Cloud :
C1 : Gestion de la variabilité technique et applicative. Lors du déploiement de l’ap-plication dans le Cloud, il faut s’assurer de la compatibilité entre les exigences tech-niques de l’application et l’environnement technique des fournisseurs de Cloud avantle déploiement pour identifier un fournisseur adéquat.
C2 : Gestion du dimensionnement. L’utilisateur doit pouvoir dimensionner les Quali-tés de Service en adéquation avec les exigences techniques et les ressources du Cloudpour pouvoir choisir plus précisément parmi les fournisseurs de Cloud potentiellementidentifiés en C1.
3. SALOON, un Cadre Logiciel Basé sur les Modèles pour la Configuration etle Déploiement dans le Cloud
Pour faire face à ces deux challenges, nous proposons un outil de configurationet de déploiement appelé SALOON. Basé sur des ontologies et des MCS, SALOONpermet (i) de spécifier une configuration technique pour l’application à déployer et(ii) de dimensionner cette configuration.
[n..m]
[n..m]
[n..m]
Cloud
Dimension
Utilisateur
Sélection de concept
Légende
Correspondance
Configuration valide/Invalide
Ontologies Modèles de caractéristiquesdu domaine
Ingénierie de l'application
Ingénierie du domaine
Figure 2. Architecture de SALOON
86
Vers un Outil de Déploiement pour les Nuages 5
Vue générale de SALOON. Les ontologies et les MCS de SALOON (FIG. 2)forment l’architecture de base et représentent l’ingénierie du domaine, tandis que lasélection de concepts et de caractéristiques constitue l’ingénierie d’application. Nousproposons dans un premier temps de faire face au challenge C1 en (i) définissant desmodèles de caractéristiques des fournisseurs de Cloud et en (ii) associant les carac-téristiques à des concepts présents dans l’ontologie du Cloud. Dans un deuxièmetemps, nous traitons le challenge C2 en proposant une ontologie de propriétés non-fonctionnelles dont les concepts sont associés aux attributs des caractéristiques.
Les Utilisateurs. SALOON est destiné à toute personne souhaitant migrer uneapplication existante dans le Cloud ou déployer un nouveau service, sous réserved’avoir les connaissances techniques nécessaires au bon fonctionnement de l’appli-cation. Il peut donc s’agir d’un développeur, d’un architecte logiciel, d’un expert enCloud Computing qui souhaite un support logiciel pour l’aider dans ses démarchesvoire même d’un fournisseur de Cloud (e.g., pour tester ses services SaaS). Les mo-dèles utilisés par le cadre logiciel (les ontologies et les MCS) sont établis et mis à jourpar des experts en Cloud Computing.
Cloud
IaaS PaaS
Modèle
Ontologie Modèle de Caractéristiques
représente
Elément
[1..*]
Concept
[1..*]
Caractéristique Attribut[0..*]
1 1correspond à
Figure 3. Meta-modèle de SALOON (Extrait)
Ingénierie du Domaine. L’architecture de SALOON (FIG. 3) repose sur deuxparties distinctes, (i) les ontologies d’une part et (ii) les MCS d’autre part. Les onto-logies permettent de formaliser la connaissance d’un domaine particulier, en l’occur-rence ici du Cloud Computing. Elles servent ici également de pont sémantique entrel’utilisateur et l’outil de raisonnement du système, les MCS. En effet, certaines carac-téristiques définies dans des MCS distincts peuvent différer syntaxiquement mais êtresémantiquement équivalentes. L’ontologie permet de regrouper ces caractéristiquessous un même concept. Ainsi, la caractéristique Database du fournisseur A (FIG. 4a)et la caractéristique Storage du fournisseur B (FIG. 4b) sont sémantiquement équi-valentes et correspondent au même concept (e.g., Stockage) dans l’ontologie Cloud
(FIG. 5). Nous proposons deux ontologies. La première, Cloud, représente les élé-
87
6 Journée Lignes de Produits 2012
ments techniques proposés par les fournisseurs de Cloud (e.g., serveur d’applicationutilisé, base de données supportée, etc.). La deuxième ontologie, Dimension, forma-lise, quant à elle, le dimensionnement de ces éléments techniques, (e.g., la taille de labase de données souhaitée, la fréquence CPU, etc.). La séparation en deux ontologiesdistinctes permet une meilleure évolution de chacune d’entre elles et garantit de garderla cohérence de l’une lors de la modification de l’autre.
Cloud A
Tomcat
GlassFish
Tomcat 6
Tomcat 7
DatabaseNom: FréquenceDomaine: réelValeur: 800
CPU[0..4]
Nom: TailleDomaine: réelValeur: 1
(a) Modèle de caractéristiques du fournisseur A
Application Server
Cloud B
Tomcat
[1..32]
App-Cell
JBoss
Storage
Single Mas/Sla
Nom: FréquenceDomaine: réelValeur: 150
Nom: MémoireDomaine: réelValeur: 128
Nom: TailleDomaine: réelValeur: 2
(b) Modèle de caractéristiques du fournisseur B
Figure 4. Différents fournisseurs de Cloud et leur MC
Les MCS forment l’ossature du cadre logiciel pour raisonner. Chaque MC repré-sente l’offre d’un fournisseur de Cloud Computing et les possibilités de configurationassociées à cette offre (FIG. 4). Le manque d’expressivité de certaines caractéristiquesa été comblé en ajoutant des informations sous forme d’un attribut, qui consiste en untriplet <nom, domaine, valeur>, déjà envisagé dans FODA. Ce sont ces attributs quipermettent de dimensionner la configuration. Un exemple d’attribut est illustré FIG. 4aavec la définition de la taille de la base de données (Database), ici 1To. À ces MCS
dits étendus ont aussi été ajoutées des cardinalités [CZA 05], sous la forme d’un in-tervalle [n..m] avec n borne minimale et m borne maximale de cet intervalle. Celui-cidétermine le nombre d’instances autorisées de la caractéristique dans la configuration.Ainsi, FIG. 4b, le fournisseur Cloud B propose de 1 à 32 App-cells (mini instancesde calcul comprenant 128Mo de RAM et 150MHz de CPU).
Ingénierie de l’Application. Pour l’utilisateur, les ontologies sont le point d’entréede SALOON, permettant ainsi de délimiter le domaine. En effet, l’utilisateur ne vientpas directement configurer les MCS des fournisseurs de Cloud mais sélectionne les
88
Vers un Outil de Déploiement pour les Nuages 7
concepts présents dans les ontologies en fonction de la configuration de l’applicationà déployer. Des correspondances sont établies entre les concepts définis dans ces on-tologies et les caractéristiques des MCS des fournisseurs de Cloud ou leurs attributs.Nous définissons une correspondance entre un concept et une caractéristique (ou attri-but) sur la base d’un nom identique. Ainsi, si l’utilisateur choisit le concept Stockagedans l’ontologie, les correspondances associées aux sous-concepts de Stockage im-pliquent la sélection de la caractéristique Database (respectivement Storage) dans leMC du fournisseur A (respectivement B), comme illustré FIG. 5. La configurationétablie peut ensuite être vérifiée à l’aide de solveurs SAT dans le cas de MCS binaireset de solveurs SMT pour des MCS étendus.
Correspondance Concept / CaractéristiqueLégende
Correspondance Concept / Attribut
Cloud A
DatabaseNom: FréquenceDomaine: réelValeur: 800
CPU
[0..4]
...
Configuration Dimensionnement
...
Cloud B
[1..32]
App-CellStorageNom: FréquenceDomaine: réelValeur: 150
Nom: MémoireDomaine: réelValeur: 128
Cloud
Stockage
Application Server
Database
Storage
MySQL
PostgreSQL
fournit
de type
StockageType
CapacitéMémoire
DimensionStockage
Temps
Fréquence
AntDroid
Stockage Index
RTree
Web
AttackWeb
Experience
Sender PublisherAttack Clustering
Algo1 Algo2
Extracter
définit
MC de l'application
Un MC par fournisseur de Cloud
Figure 5. Correspondances entre les ontologies et les MCS (Extraits).
Réponse aux Challenges. Pour faire face au challenge C1 gestion de la variabilitétechnique et applicative, l’utilisateur choisit dans l’ontologie Cloud les éléments tech-niques nécessaires au bon fonctionnement de l’application en fonction de sa configu-
89
8 Journée Lignes de Produits 2012
ration. Par le biais des correspondances entre concepts et caractéristiques, ce choix deconcepts entraine la sélection des caractéristiques correspondantes dans les différentsMCS et établit donc une configuration de ces MCS. La vérification par des solveursSAT des contraintes associées à ces MCS (e.g., sélection d’une caractéristique si elleest requise par une autre caractéristique, sélection de la caractéristique parent d’unecaractéristique sélectionnée) permet de tester la validité des configurations sélection-nées et détermine donc les fournisseurs de Cloud capables de déployer l’application(i.e., ceux dont la configuration du MC est valide). Ainsi, une application nécessitantune base de données peut être déployée sur chacun des Clouds Cloud A et Cloud B dela FIG. 4. En revanche, si cette même application doit être déployée dans un serveurd’application JBoss, seul le fournisseur Cloud B offre une configuration valide.
Plusieurs configurations de MCS peuvent être valides. Dans ce cas plusieurs four-nisseurs de Cloud peuvent permettre le déploiement de l’application. Pour gérer lechallenge C2, gestion du dimensionnement, l’utilisateur a alors la possibilité d’affinerla liste des fournisseurs potentiels en choisissant dans l’ontologie Dimension les pro-priétés non-fonctionnelles qu’il souhaite pour l’application à déployer (e.g., la taille del’espace de stockage, les performances CPU, etc.). Supposons qu’il veuille déployerune application App ayant besoin de peu de fréquence CPU (e.g., moins de 800MHz)pour s’exécuter correctement. Il peut alors choisir entre un déploiement chez le four-nisseur Cloud A ou chez le fournisseur Cloud B (FIG. 4). S’il exige une plus grandefréquence CPU, il doit s’orienter vers le fournisseur Cloud B qui permet de sélec-tionner plusieurs App-Cells et donc d’augmenter la fréquence CPU fournie. L’utilisa-teur a la possibilité de dimensionner toutes les caractéristiques possédant un attribut.Ainsi, si le déploiement de l’application App, en plus d’une fréquence CPU supérieureà 800MHz, nécessite aussi la configuration d’une base de données dont la capacitédépasse 2To, dimension seulement supportée par le fournisseur Cloud A qui permetjusqu’à 4To de stockage, l’utilisateur devra donc déterminer quelle est la dimension laplus importante pour le déploiement de son application App et choisir entre Cloud A
et Cloud B. Des solveurs SMT peuvent ensuite être utilisés pour tester la validité desconfigurations de MCS étendus.
4. Implémentation & Retours d’Expériences
Implémentation. Le cadre logiciel SALOON repose sur différentes technologiescorrespondant aux deux formalismes utilisés, les ontologies et les modèles de caracté-ristiques. Pour construire nos ontologies, nous avons utilisé Protégé-OWL 4, un éditeuropen-source Java permettant de créer et de manipuler des ontologies au format OWL[KNU 04]. Protégé-OWL est le plus connu et le plus utilisé des éditeurs d’ontologie.Il offre notamment la possibilité d’obtenir une représentation graphique de l’ontolo-gie développée et permet d’exécuter des raisonneurs sur cette ontologie (e.g., sur lesdescripteurs logiques). Les ontologies sont ensuite utilisées avec la librairie OWLAPI [HOR 11]. OWL API est une librairie Java open-source sous licence LGPL quipermet de créer et de manipuler des ontologies. C’est cette librairie qui nous permetde faire correspondre un concept de l’ontologie avec une caractéristique ou un attri-
90
Vers un Outil de Déploiement pour les Nuages 9
but d’un MC. En effet, la librairie offre la possibilité de décomposer l’ontologie etd’en lister ses concepts, qui sont associés à des caractéristiques ou des attributs dansun fichier de correspondance. Nous utilisons ce fichier pour établir les configurationsdes MCS à partir de la liste de concepts choisis par l’utilisateur, en sélectionnant lescaractéristiques correspondant à ces concepts. Les modèles de caractéristiques avecattributs et cardinalités ont été décrits avec le langage TVL (Textual Variability Lan-guage) [CLA 11]. Basé sur une syntaxe proche du C, il offre des mécanismes permet-tant à la fois d’être compréhensible et concis tout en supportant des besoins d’expres-sivité avancés tels que les attributs et cardinalités d’une caractéristique.
Retours d’Expériences. MC vs ontologie. Sur le plan technique, TVL n’en est àl’heure actuelle qu’au stade de la proposition de langage et est en cours d’implémen-tation. Il est cependant possible de se passer de TVL et des MCS étendus en utilisantdes ontologies pour modéliser les différentes offres de Cloud Computing. L’approcheest identique, seule la modélisation des fournisseurs de Cloud change. L’utilisationd’ontologies à malgré tout un certain nombre d’inconvénients. Les ontologies ne sontpas dédiées à la gestion de la variabilité et leur utilisation n’est pas adaptée lorsqu’ils’agit de gérer les caractéristiques et les contraintes associées. Pour jouer correctementle rôle d’un MC, les ontologies doivent donc être mises en relation avec un ensemblede contraintes. Nous pensons donc associer les ontologies à des contraintes OCL (Ob-ject Constraint Language). Pour reprendre l’exemple du dimensionnement du CPU(l’application nécessite au moins 800MHz de CPU), on peut associer une contrainteOCL spécifiant que la quantité de CPU donnée par la configuration soit supérieure àcelle spécifiée par l’utilisateur lors du dimensionnement. Pour faciliter la gestion deces contraintes, les ontologies initialement décrites en OWL peuvent être décrites endiagramme de classes UML (Unified Modeling Language), de nombreux outils issusde L’Ingénierie Dirigée par les Modèles permettant de manipuler le binôme UML-OCL. Il serait d’ailleurs intéressant de proposer une comparaison entre les MCS et lecouple UML-OCL en termes d’expressivité, de résolution de contraintes, de temps detraitement, etc. afin de définir si le raisonnement de SALOON doit être basé sur desMCS ou des ontologies.
Évolution des ontologies et des MCS. L’utilisation exclusive d’ontologies a l’avan-tage de ne proposer qu’un seul formalisme de modélisation et réduit donc le coût degestion lié aux évolutions du Cloud Computing. En effet, ces évolutions doivent êtrerépercutées dans les différents modèles de SALOON. A l’heure actuelle, chaque MCdoit être mis à jour en fonction de l’évolution de l’offre du fournisseur de Cloud. Afinde maintenir les correspondances entre MCS et ontologies cohérentes, ces dernièresdoivent également évoluer en conséquence.
Idéalement, et très certainement dans la suite de nos travaux, les ontologies et lesMCS seront rendus publics et mis à disposition sur le Web. Ils pourront donc êtreconsultés et mis à jour régulièrement (par le biais d’une plateforme collaborative parexemple) par des experts du Cloud Computing. Ainsi, à chaque démarrage de SA-LOON, la dernière version de l’ontologie et/ou des MCS pourra être téléchargée etSALOON sera donc à jour des évolutions des différents fournisseurs du Cloud Com-puting.
91
10 Journée Lignes de Produits 2012
5. Travaux Connexes
Plusieurs approches utilisent des ontologies comme fondement pour trouver unfournisseur de Cloud. Dastjerdi et al. présentent une architecture basée sur des onto-logies pour déployer des piles logicielles sur des fournisseurs de IaaS [DAS 10]. Ilsproposent une ontologie qui décrit les exigences fonctionnelles et non-fonctionnellesde l’utilisateur en termes de Qualité de Service et une ontologie décrivant différentsservices fournis au niveau IaaS. Ils font ensuite correspondre les deux ontologies pourdéterminer quel service répond le mieux aux besoins de l’utilisateur. Notre proposi-tion va dans ce sens mais propose de chercher le fournisseur le plus approprié niveauIaaS et niveau PaaS. De plus, elle prend en compte la configuration de ces services etleur composition (i.e., la possibilité de chercher un fournisseur de Cloud offrant plu-sieurs services). Dans [KAN 11], les auteurs présentent un système à base d’agents dedécouverte de services de Cloud. Ils proposent en outre des taxonomies qui sont desconcepts hiérarchisés des niveaux PaaS et IaaS. Le système (i.e., les agents) raisonnesur les relations entre les différents services et établit des similarités entre les requêtesde l’utilisateur et les services de Cloud pour établir un classement des services lesplus pertinents. Les auteurs poursuivent donc le même but que nous mais là encore,l’utilisateur ne peut chercher qu’un service à la fois (e.g., un service de Cloud offrantdu CPU) et les ontologies proposées ne correspondent pas tout à fait à nos besoins.
Des approches basées sur les Lignes de Produits Logiciels et les modèles de carac-téristiques sont également proposées. Ainsi, [CAV 12] et al. proposent une adaptationdu développement basé sur les LPLs pour déployer leur système de contrôle de santé(HW). Ils incorporent dans le MC de l’application à déployer des caractéristiques"de Cloud" (e.g., Amazon S3 pour le stockage, Google Authentication pour le login)qu’ils ont recueillies en étudiant des applications déjà déployées sur le Cloud. Contrai-rement à notre démarche, ils viennent donc modifier le MC d’origine de l’applicationet, en quelque sorte, influent sur le choix final du fournisseur de Cloud. Ils utilisentégalement des MCS étendus mais l’utilisation des attributs n’est pas expliquée préci-sément. Dans [SCH 12], les auteurs utilisent l’ingénierie des LPLs pour configurer desapplications de Cloud à plusieurs utilisateurs. Ils s’appuient sur un MC étendu pourreprésenter la variabilité des fonctionnalités et des qualités de services de l’applicationà déployer et proposent d’utiliser dans leurs travaux futurs un processus de configura-tion par étapes pour configurer l’application. Un expert de chaque niveau (IaaS, PaaS,SaaS) vient à tour de rôle configurer son niveau. Le choix du fournisseur de Cloudn’est donc pas possible et le déploiement dépendra du IaaS/PaaS configuré. D’autresauteurs ([QUI 12], [LEN 12]) présentent une approche dirigée par les modèles de ca-ractéristiques pour créer et gérer des configurations et déployer des images virtuellessur un IaaS. Ils considèrent une image virtuelle comme une LPL et utilisent les MCS
pour représenter les configurations. Chaque caractéristique de la configuration est unlogiciel à installer dans l’image virtuelle. Contrairement à notre approche, ils n’ontpas à choisir parmi les différentes plateformes de déploiement puisqu’ils configurenttoute la pile logicielle qui va accueillir l’application, qui ne peut être déployée qu’auniveau IaaS.
92
Vers un Outil de Déploiement pour les Nuages 11
6. Conclusion et Perspectives
Dans cet article, nous avons présenté un cadre logiciel, SALOON. Basé sur lesontologies et les MCS, il aide l’utilisateur à choisir en fonction de la configurationde l’application le fournisseur de Cloud qui permettra son déploiement. Les ontolo-gies représentent le domaine du Cloud, tandis que les MCS décrivent la variabilitédes différents fournisseurs de Cloud. L’utilisation de MCS étendus permet en outrele dimensionnement de cette variabilité. Nous utilisons SALOON comme outil deconfiguration et de dimensionnement de l’application à déployer sur le Cloud. Nousproposons d’utiliser les ontologies comme point d’entrée et définissons des correspon-dances entre les caractéristiques des MCS et les concepts des ontologies. La sélectionde concepts par l’utilisateur correspondant aux exigences de l’application entraînela définition de configurations des MCS de Cloud. Si cette configuration est valide,le fournisseur de Cloud associé au MC peut exécuter cette application, et la confi-guration peut ensuite être dimensionnée pour profiter de l’élasticité du Cloud. Notreapproche fait face aux challenges identifiés en SEC. 2. Pour le premier challenge, àsavoir le support de la variabilité technique, nous proposons une ontologie de conceptstechniques communément utilisés dans le Cloud et des MCS des différents fournis-seurs de Cloud. Concernant le second challenge, le support du dimensionnement, nousproposons une ontologie et des attributs associés aux caractéristiques des MCS pourdécrire les dimensions des différents concepts techniques. Dans les deux cas, le cadrelogiciel établit une correspondance entre les concepts des ontologies et les caractéris-tiques des MCS. Nous avons implémenté notre approche en utilisant des technologiesconnues du domaine et avons décelé quelques limitations.
Notre perspective sera dans un premier temps de lever les limitations techniquesafin d’évaluer et de valider complètement notre approche. Par la suite, nous pensonsque notre approche peut être étendue afin de gérer les différentes Qualités de Ser-vice souhaitées par l’utilisateur (e.g., coût du déploiement d’une configuration don-née) pour proposer la meilleure solution possible parmi les solutions envisageables.De plus, il serait intéressant d’aller vers un outil d’optimisation de la configurations’appuyant sur les différents solveurs pour aider l’utilisateur dans sa configuration.
7. Bibliographie
[BEN 05] BENAVIDES D., TRINIDAD P., RUIZ-CORTÉS A., « Automated reasoning on fea-ture models », Proceedings of the 17th international conference on Advanced InformationSystems Engineering, CAiSE’05, Berlin, Heidelberg, 2005, Springer-Verlag, p. 491–503.
[CAV 12] CAVALCANTE E., ALMEIDA A., BATISTA T., CACHO N., LOPES F., DELICATO
F. C., SENA T., PIRES P. F., « Exploiting software product lines to develop cloud compu-ting applications », Proceedings of the 16th International Software Product Line Confe-rence - Volume 2, SPLC ’12, New York, NY, USA, 2012, ACM, p. 179–187.
[CLA 11] CLASSEN A., BOUCHER Q., HEYMANS P., « A Text-based Approach to FeatureModelling : Syntax and Semantics of TVL », Science of Computer Programming, Special
93
12 Journée Lignes de Produits 2012
Issue on Software Evolution, Adaptability and Variability, vol. 76, no 12, 2011, p. 1130–1143.
[CLE 01] CLEMENTS P., NORTHROP L. M., Software Product Lines : Practices and Patterns,Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2001.
[CZA 05] CZARNECKI K., HELSEN S., EISENECKER U. W., « Formalizing cardinality-basedfeature models and their specialization », Software Process : Improvement and Practice,vol. 10, no 1, 2005, p. 7-29.
[DAS 10] DASTJERDI A. V., TABATABAEI S. G. H., BUYYA R., « An Effective Architecturefor Automated Appliance Management System Applying Ontology-Based Cloud Disco-very », Proceedings of the 2010 10th IEEE/ACM International Conference on Cluster,Cloud and Grid Computing, CCGRID ’10, Washington, DC, USA, 2010, IEEE ComputerSociety, p. 104–112.
[GRU 93] GRUBER T. R., « A translation approach to portable ontology specifications »,Knowl. Acquis., vol. 5, no 2, 1993, p. 199–220, Academic Press Ltd.
[HOR 11] HORRIDGE M., BECHHOFER S., « The OWL API : A Java API for OWL ontolo-gies », Semantic Web, vol. 2, no 1, 2011, p. 11-21.
[KAN 90] KANG K. C., COHEN S. G., HESS J. A., NOVAK W. E., PETERSON A. S.,« Feature-Oriented Domain Analysis (FODA) - Feasibility Study », rapport, 1990, TheSoftware Engineering Institute.
[KAN 11] KANG J., SIM K. M., « Cloudle : an ontology-enhanced cloud service search en-gine », Proceedings of the 2010 international conference on Web information systemsengineering, WISS’10, Berlin, Heidelberg, 2011, Springer-Verlag, p. 416–427.
[KNU 04] KNUBLAUCH H., FERGERSON R. W., NOY N. F., MUSEN M. A., « The ProtégéOWL plugin : An open development environment for semantic web applications », Springer,2004, p. 229–243.
[LEN 12] LE NHAN T., SUNYÉET G., JÉZÉQUEL J.-M., « A Model-Driven Approach forVirtual Machine Image Provisioning in Cloud Computing », DE PAOLI F., PIMENTEL E.,ZAVATTARO G., Eds., Service-Oriented and Cloud Computing, vol. 7592 de Lecture Notesin Computer Science, p. 107-121, Springer Berlin / Heidelberg, 2012.
[MEL 09] MELL P., GRANCE T., « The NIST Definition of Cloud Computing », rapport,2009, National Institute of Standards and Technology.
[POH 05] POHL K., BÖCKLE G., LINDEN F. J. V. D., Software Product Line Engineering :Foundations, Principles and Techniques, Springer-Verlag New York, Inc., Secaucus, NJ,USA, 2005.
[QUI 12] QUINTON C., ROUVOY R., DUCHIEN L., « Leveraging feature models to configurevirtual appliances », Proceedings of the 2nd International Workshop on Cloud ComputingPlatforms, CloudCP ’12, New York, NY, USA, 2012, ACM, p. 2 :1–2 :6.
[SCH 12] SCHROETER J., MUCHA P., MUTH M., JUGEL K., LOCHAU M., « Dynamic confi-guration management of cloud-based applications », Proceedings of the 16th InternationalSoftware Product Line Conference - Volume 2, SPLC ’12, New York, NY, USA, 2012, ACM,p. 171–178.
94
![Identification of Low-Abundance Lipid Droplet Proteins · Identification of Low-Abundance Lipid Droplet Proteins in Seeds and Seedlings1[OPEN] Franziska K. Kretzschmar,a,2 Nathan](https://img.pdfslide.fr/doc/110x75/5f1b6eccd9db36017f49896d/identiication-of-low-abundance-lipid-droplet-identiication-of-low-abundance.jpg)
