Génération automatique des adaptateurs pour BUT4Reuse Encadrants : Tewfik ZIADI (UPMC & LIP6) Jabier Martinez (UPMC & Université de Luxembourg) Contexte : les lignes de produits logiciels L ingénierie des lignes de produits logiciels (LdP)[1,2] est une approche du génie logiciel qui a commencé à s imposer ces dix dernières années. Cette approche est une transposition des chaînes de production industrielles (ex. voitures) au monde logiciel. Le principe est de minimiser les coûts de construction de logiciels dans un domaine d application particulier en ne développant plus chaque logiciel séparément, mais plutôt en concevant à partir d éléments réutilisables une collection (appelée aussi une famille) de logiciels similaires. Le principe de l approche LdP réside dans la conception d une architecture permettant de définir plusieurs logiciels à la fois. Les membres d une ligne de produits sont caractérisés par leurs points communs, mais aussi par leurs différences (appelées variabilité). La gestion de cette variabilité est l une des activités clé des lignes de produits. Une autre activité dans l ingénierie des LdP concerne la construction d un produit logiciel (on parle aussi de dérivation de produit) qui consiste en partie à figer certains choix vis- à- vis de la variabilité définie dans la ligne de produits pour générer un produit spécifique. La Figure 1 illustre le schéma général de l approche LdP. XOR XOR Figure 1 : Lignes de produits logiciels - une approche descendante Figure 2 : Extraction d une ligne de produits
Plusieurs méthodes souvent intégrées dans des outils ont été proposées ces dernières années pour la manipulation des LdP [1,2]. L idée de base de ces travaux consiste à implémenter les deux axes ci- dessus à savoir : 1) proposer des mécanismes pour la spécification de la variabilité, 2) automatiser la dérivation de produits en utilisant les transformations de programmes et ou de modèles. L approche de manipulation de LdP dans le cadre de ces méthodes devient donc descendante comme illustrée par la Figure 1 : la ligne de produits est modélisée en premier lieu et par la suite les produits sont dérivés automatiquement. Motivation : extraction automatique de lignes de produits Il existe cependant des cas où un grand nombre de produits similaires et dans le même domaine sont modélisés séparément, c est- à- dire sans prise en compte de la notion de LdP et de la variabilité dès le départ. C est une démarche assez répandue dans l industrie. L extraction ad hoc a posteriori et manuelle induit un coût de maintenance élevé. Dans le cadre de ce projet, nous souhaitons nous focaliser sur cette vision ascendante ou approche extractive, où la ligne de produits est extraite automatiquement à partir de plusieurs produits logiciels similaires existants (appelés product variants, en anglais). La Figure 2 illustre cette vision. L idée est d analyser toutes ces variantes du logiciel pour construire une ligne de produits en identifiant les éléments communs et les éléments variables. Cela permet de faciliter la maintenance de toutes ces variantes et faciliter l adoption de l approche lignes de produits. Une première méthode ascendante a été déjà implémentée au sein de l équipe MoVe. Cette approche est intégrée dans le prototype But4reuse (http://www.but4reuse.org). But4reuse consiste à identifier à partir d artefacts logiciels similaires les éléments communs et variables. But4reuse est basé sur trois hypothèses : 1. Hypothèse 1 (H1) : Décomposition de chaque produit sous forme d un ensemble d éléments atomiques. 2. Hypothèse 2 (H2) : Définition d une relation de similarité entre les éléments atomiques. 3. Hypothèse 3 (H3) : Implémentation d algorithmes permettant l identification des éléments communs et variables entre les différents artefacts. Application d un algorithme simple basée sur la notion de relation d équivalence entre les ensembles [3,4]. La notion d élément atomique dépend du type de produit logiciel considéré. But4reuse est proposé comme un cadre générique pour supporter plusieurs types d artefacts : code source, modèles, exigences, fichiers texte, images, etc. Pour chaque type d artefact, But4reuse implémente ce qui a été appelé «adapteur» permettant d une part de préciser l élément atomique (H1) et la relation de similarité entre les éléments
atomiques (H2). But4Reuse propose par la suite d intégrer des algorithmes d identification et de comparaison. Actuellement, un seul algorithme simple a été implémenté et intégré. Cet algorithme est basé sur la notion de relation d équivalence dont l objectif est de réaliser une intersection entre les différents ensembles d éléments atomiques représentant les différentes variantes de produit. La Figure 3 illustre visuellement le résultat de l application de But4reuse sur une collection d images similaires en utilisant «adapter image». L élément atomique dans le contexte de l image est le «pixel» qui est défini par la couleur mais aussi la position du pixel sur l image. La relation d équivalence est une relation simple d égalité entre pixels (même couleur et même position). L algorithme d identification et de comparaison permet par la suite d identifier les blocs communs et variables sous forme d ensemble de pixels. Il s agit dans cet exemple d identifier les fragments d image commun (le visage) et les différents fragments qui sont optionnels (pulls, pantalons, etc.). Comme l illustre la figure, But4reuse permet aussi d identifier les contraintes d implication et d exclusion entre les blocs, ce qui permet de découvrir de nouvelles images qui n étaient pas présentes initialement. Figure 3 : Illustration de But4reuse sur des produits «images» But4reuse implémente actuellement 12 adaptateurs : C and Java source code EMF models Text lines File structure Images Comma- Separated- Value Requirements Eclipse installations adapter Graphs adapter Natural language text Music scores JSON
Objectifs Pour implémenter un adaptateur, il est demandé d implanter un plugin Eclipse selon des points d extension bien définis par l architecture générique de BUT4Reuse. Chaque adaptateur est implanté donc comme un projet plugin Eclipse (cf. Figure 4). Cela demande une expertise supplémentaire concernant le développement des plugins Eclipse. Nous souhaitons donc dans ce projet faciliter cette activité d implantation des adaptateurs en se basant sur une approche dirigée par les modèles dont l objectif est de proposer une génération automatique. L idée est : 1. Proposer un langage du domaine (DSL) permet de spécifier d une manière abstraite les éléments atomiques et leurs relations de similarité. 2. Implanter un générateur permettant à partir de la spécification de l adaptateur de générer la squelette de plugin Eclipse implantant l adapter et l intégrer dans BUT4Reuse. Figure 4 : Les adaptateurs de But4reuse comme des projets plugin Eclipse. Spécifications et Lots En se basant sur les mécanismes d extensions proposés par But4Reuse, il vous est demandé : 1. Lot 1 : Proposition d un DSL (Domain Specific Language) pour la spécification abstraite des adaptateurs BUT4Reuse. La syntaxe abstraite et concrète de ce DSL doit etre proposée en utilisant les technologies EMF et XText. 2. Lot 2 : Implantation d un générateur de plugin Eclipse. Les technologies autours d EMF et Xtext permettent d implanter ce genre de générateur.
3. Lot 3 : Validation sur au moins 3 adaptateurs existants. Le projet suivra une démarche itérative et autant que possible dirigée par les tests. Il ne s agit donc pas de faire complètement tel lot avant de passer au suivant mais au contraire de développer rapidement une version permettant de tester rapidement. Il s agira alors d ajouter peu a peu des fonctionnalités. Références [1] Klaus Pohl, Günter Böckle, Frank van der Linden: Software product line engineering - foundations, principles, and techniques. Springer 2005, isbn 978-3- 540-24372- 4, pp. I- XXVI, 1-467. [2] Apel, S. B. (2013). Feature- oriented software product lines: concepts and implementation. Springer. [3] T.Ziadi, C. Henard, M.Papadakis, M.Ziane, & Y.LeTraon. (2014). Towards a language- independent approach for reverse- engineering of software product lines. SAC (pp. 1064-1071).,ACM. [4] T. Ziadi, L. Frias, M. Almeida da Silva, M. Ziane : Feature Identification from the Source Code of Product Variants, 16 th European Conference on Software Maintenance and Reengineering (CSMR), pp. 417-422, (IEEE Computer Science) (2012) [5] : S. Lamprier, N. Baskiotis, T. Ziadi, and L. M. Hillah. The CARE platform for the analysis of behavior model inference techniques. Information and Software Technology, 60(0):32 50, 2015. [6] : E. Alpaydin. Introduction to Machine Learning. Number 978-0- 262-01243- 0. MIT Press, second edition, 2010.