Intégration à l'équipe R&D de Smartesting. Corentin FIEUX. Stage en entreprise de deuxième année de Master Informatique

Transcription

1 Corentin FIEUX Master 2 - Informatique finalité professionnelle option Sécurité & Sûreté du Logiciel Intégration à l'équipe R&D de Smartesting Stage en entreprise de deuxième année de Master Informatique Responsable Enseignant : Hervé GUYENNET Responsable Entreprise : Christophe GRANDPIERRE Jury : Hervé GUYENNET, Jean-Christophe LAPAYRE Année

2 Remerciements Je tiens à remercier en premier lieu Bruno LEGEARD, Laurent PY et Stéphane WERBA pour m'avoir chaleureusement accueilli au sein de Smartesting. J'ai eu beaucoup de plaisir à intégrer leur entreprise. Un grand merci également à toute l'équipe R&D et son chef d'équipe Olivier ALBIEZ qui m'ont fait confiance tout au long du stage et ont tout fait pour me mettre dans les meilleures dispositions afin que je puisse développer et apprendre à leur coté de la meilleure des façons. Leur disponibilité et les conditions de travail qu'ils ont réussi à créer sont pour beaucoup dans le bon déroulement de ce stage et je les remercie pour cette expérience. Enfin, j'aimerais remercier les employés des agences Smartesting de Paris, Boston et Bangalore que j'ai eu le plaisir de rencontrer au moment du «meeting corp'» auquel j'ai été invité. 2

3 Table des matières 1. Introduction Présentation du sujet Présentation de Smartesting L'entreprise L'équipe R&D Description du sujet Définition du sujet Méthode de travail Réactivité face au changement Interaction avec les personnes Produit fonctionnel Collaboration avec le client Environnement de programmation Langages de programmation Poste de travail Travail réalisé Planning Axes de travail Semaine type Planning de travail Analyses et Développements Observation Travaux sur les «publishers» et connecteurs «Publisher» QC «publisher» Testlink Connecteur Reqtify Gestion de licence Analyse Implémentation du gestionnaire Interfaçage avec le serveur Implémentation du gestionnaire de licence Création du «plugin» Eclipse Écriture des tests de validation Création d'ihm

4 «Packaging» Maintenance Correction de «warnings» «Refactoring» Correction de «bugs» Bilans Bilan pédagogique Développement Méthode de travail Bilan humain Conclusion

5 1. Introduction L'informatique est aujourd'hui omniprésente dans notre vie quotidienne de façon plus ou moins perceptible et à tel point qu'il serait difficile voire impossible de s'en passer. L'automatisation des procédures est de plus en plus recherchée afin de gagner en temps et en efficacité. Cependant et malgré l'influence des programmes informatiques au quotidien, tous n'ont pas bénéficié du même soin accordé à leur développement. En effet, si l'on conçoit qu'une anomalie dans un programme gérant une machine à café ait des conséquences limitées, on imagine mal un programme de pilotage d'avion qui risque à tout moment de présenter un comportement anormal et qui ne soit donc pas sûr à 100% (même si cette sûreté totale reste utopique). Ces systèmes dont les actions sont essentielles et sensibles sont dit critiques ; parmi eux, on peut citer les systèmes mettant en jeu d'importantes sommes d'argent (transactions bancaires, projet coûteux tel celui d une navette spatiale) ou même des vies humaines (avions, centrales). Si lors des débuts de l'informatique le fait de tester une application afin d'en limiter les risques de plantage était complètement occulté, c'est aujourd'hui un aspect tout aussi important que la conception du programme lui-même et ce pour plusieurs raisons. La première étant évidemment la sécurité ; comme évoqué précédemment, la sûreté d'un programme est essentielle dans les systèmes critiques. La seconde est économique ; en effet, si le fait de tester un programme s'avère une phase coûteuse, elle est cependant amortie par la suite lors de la phase de maintenance qui s'en trouve grandement allégée. Et enfin, la dernière raison est la satisfaction du client qui aura évidemment une confiance accrue en un programme testé et «sûr» plutôt qu'en un programme qui ne l'est pas. La concurrence au sein du monde de l'informatique étant importante, l'aspect du test est donc naturellement passé sur le devant de la scène lors du développement d'une application. A l'origine confiée aux propres développeurs du programme à tester ou simplement occultée, la phase de test tend aujourd'hui à devenir moins marginalisée si bien qu'elle peut être confiée à des ouvriers qualifiés entièrement dévoués à cette tâche et s'intégrant pleinement dans le processus de développement d'un outil informatique. Les métiers du test informatique sont de plus en plus valorisés et recherchés notamment au sein des entreprises travaillant sur le développement de systèmes critiques ; on peut ainsi observer l'émergence de nouveaux postes comme analyste de test ou ingénieur de test bénéficiant de compétences et de qualifications propres au test. Il existe de nombreuses manières de tester un programme, système ou logiciel et ce à différents niveaux. A l'un de ces niveaux, on trouve le test fonctionnel ou test boite noire consistant à effectuer le test d'une fonctionnalité sans en connaître le code mais seulement le comportement ; il s'agit donc de vérifier que ce-dernier est bien celui attendu dans un contexte défini. De nombreuses techniques permettent de mettre en place des tests fonctionnels, l'une d'elles se base sur la modélisation des comportements du système à tester, aussi appelé SUT 1, pour 1 SUT (System Under Test) : Le système sous test est le système sur lequel seront exécuté les différents tests. 5

6 en générer les tests couvrant l'ensemble des comportements, qui seront exécutés sur le véritable programme. C'est ce que l'on appelle le MBT 2. Cette méthode a plusieurs avantages : premièrement, puisqu'on ne modélise que les actions et données il n'est donc pas nécessaire d'être développeur pour faire du test ; deuxièmement la maintenance des tests est plus aisée puisque la génération est automatisée et que par conséquent, seul le modèle doit être modifié pour mettre à jour la batterie de test ; et troisièmement elle réduit les risques d'erreur liés à l'implémentation d'un test. Tout cela en plus des gains réalisés sur les coûts du processus de test d'application. Cela fait maintenant huit années que la société Smartesting (anciennement Leirios) est active dans ce domaine du test guidé par un modèle, en offrant une solution afin de modéliser un système, d'en générer les tests et de les publier vers un outil tiers permettant de rendre les tests exécutables. Cette solution se compose d'outils permettant la modélisation du système, la génération et la publication de tests, mais également d'un aspect formation permettant d'assister les utilisateurs de la solution. Étant l'une des deux seules entreprises au monde (avec la société finlandaise Conformiq Inc.) dont l'activité principale est la conception d'une solution de test basée sur le MBT, c'est donc un véritable privilège de se voir confier un poste au sein de Smartesting. C'est en tant que développeur que j'ai intégré l'équipe R&D 3 de Smartesting pour une durée de 6 mois durant lesquels j'ai participé au développement des outils de modélisation et de génération de tests. J'ai ainsi eu l'occasion de mettre en application mes connaissances en matière de programmation et de test acquises lors du cursus LMD 4 à l'université de Franche-Comté et plus précisément, durant la seconde année de Master option Sécurité et Sûreté du logiciel (S2L), deux notions en relation directe avec les activités de l'équipe R&D de Smartesting. 2 MBT (Model Based Testing) : Procédé de test consistant à tester un modèle plutôt que le programme lui-même. 3 R&D : Recherche et Développement. 4 LMD : Licence Master Doctorat. 6

7 2. Présentation du sujet 2.1. Présentation de Smartesting L'entreprise Smartesting est une entreprise française d'édition de logiciels créée en 2003 par Bruno LEGEARD et Laurent PY. Nommée originellement Leirios, elle change de nom en 2008 pour devenir l'actuelle Smartesting. Implantée à Besançon, elle compte aujourd'hui des agences à Paris, à Bangalore en Inde et à Boston aux États-Unis. L'entreprise est aujourd'hui dirigée par un comité de trois personnes : Bruno LEGEARD le directeur technique, Laurent PY le chef de la direction et Stéphane WERBA le directeur opérationnel. L'activité de Smartesting est issue du projet BZTT 5 du Laboratoire Informatique de FrancheComté (LIFC) traitant du test fonctionnel d'applications informatiques. Le projet a été industrialisé par l'entreprise pour aboutir aujourd'hui à la solution Smartesting. Cette solution répond au besoin qu'ont les développeurs d'applications à garantir le fonctionnement de ces-dernières en se basant sur le concept MBT (Figure 1), une activité encore peu répandue puisque comme évoqué précédemment, Smartesting ne compte qu'un seul véritable concurrent : la société Conformiq Inc. basée en Finlande. Figure 1 : Illustration du concept MBT. Concrètement la solution (Figure 2), à partir d'un modèle basé sur UML 6 annoté en OCL7 du 5 BTZZ (B-Z Testing Tools) : L'outil permet l'animation de spécifications B et Z afin de générer des tests. 6 UML (Unified Modeling Language) : Langage de modélisation graphique. 7 OCL (Object Constraint Language) : Langage d'expression de contraintes. 7

8 système à tester, génère des tests fonctionnels (ou boite noire) qui seront exécutés sur l'application finale. Le déploiement de cette solution de test se réalise en trois éléments : La modélisation du SUT : La modélisation du système se fait au moyen de modeleurs indépendants supportés par Smartesting. Actuellement, les modeleurs supportés sont RSA / RSM8 et Papyrus9, tous deux basés sur la plateforme Eclipse. Smartesting propose des «plugins» permettant la vérification syntaxique et l'importation de modèles de test issus de ces modeleurs. La solution utilise également ce qu'ils appellent des connecteurs pour permettre l'utilisation d'outils utiles à la modélisation comme Reqtify qui permet de gérer les exigences. La génération de tests : Cette phase entièrement automatisée est réalisée à travers le logiciel CertifyIt. Celui-ci s'appuie sur le modèle de test pour en générer des cas de test fonctionnels. La publication des tests : Ce dernier aspect est l'aboutissement du travail des concepteurs de tests : il permet d'obtenir des tests fonctionnels concrets. La publication se fait au moyen de «publishers» permettant l'export des tests en différents formats (HTML, JUnit, ) ou vers différents outils (HP QC, TestLink, ). Outre les outils de la solution, Smartesting compte une équipe de consultants qui forment les utilisateurs à l'utilisation de la solution. Cette équipe est très proche de l'équipe de développement des outils et suggère parfois des améliorations et offre une première phase de test des outils. 8 RSA (Rational Software Architect) / RSM (Rational Software Modeler) : Logiciels de modélisation d'ibm. 9 Papyrus : Outil de modélisation officiel d'eclipse. 8

9 Figure 2 : Schéma décrivant la solution Smartesting. L'utilisation et la promotion de la solution Smartesting a permis à la société de nouer plusieurs partenariats avec des entreprises bien connues sur la scène industrielle française et mondiale, et ce dans des domaines très diversifiés ; parmi elles, BNP Parisbas, la SNCF ou encore Renault. Afin de rester à jour dans le domaine du MBT, Smartesting intègre, conjointement à ses innovations personnelles, les besoins de ses clients dans le développement de sa solution. Ainsi les retours des clients par les commerciaux et consultants sont discutés et étudiés afin de faire évoluer les produits, produits dont le développement est confié à l'équipe de recherche et de développement de Smartesting L'équipe R&D L'équipe R&D de Smartesting se compose de huit développeurs chevronnés, puisque tous ont au minimum cinq années post-baccalauréat. Ils sont dirigés par un chef d'équipe lui aussi développeur : Olivier ALBIEZ. L'équipe R&D est en charge du développement des produits commercialisés par la société. En d'autre termes, elle développe le logiciel Smartesting CertifyIt mais aussi les différents «plugins» utilisés dans les modeleurs ainsi les publishers (même si le développement de cesderniers est depuis quelques temps laissé de plus en plus à la charge des consultants). Il existe également d'autres développements tels que les connecteurs ou certains prototypes qui peuvent être développés par d'autres équipes de Smartesting, mais la R&D a toujours le dernier mot pour 9

10 l'intégration au produit final commercialisé Description du sujet Définition du sujet J'ai intégré l'équipe R&D afin de travailler sur le développement des composants de la solution Smartesting décrits précédemment ; le travail qui m'est demandé est donc, dans la mesure de mes capacités et connaissances, le même que celui qu'effectue n'importe quel autre développeur de l'équipe. L'équipe R&D de Smartesting travaille suivant un mode de développement continu. Son travail consiste à faire évoluer constamment le produit développé en l'améliorant au fur et à mesure des besoins de ses clients. Cela diffère du mode de développement pouvant se pratiquer chez d'autres sociétés d'éditeur de logiciels, consistant à sortir une succession de produits qui une fois terminés resterons en l'état. Le travail de l'équipe R&D évolue donc en permanence au gré des besoins des clients de Smartesting et du marché, et ce de manière très rapide si bien qu'il m'est difficile de résumer le stage à un seul aspect du développement de la solution Smartesting, et donc d'en définir clairement un sujet, tant les travaux effectués et les domaines concernés sont nombreux et fluctuants. Malgré cela, le sujet du stage peut tout de même être résumé, tout en restant volontairement évasif, à l'amélioration des composants de la solution Smartesting en intégrant les dernières exigences. La suite montrera que parmi l'ensemble des domaines, certains ont été prépondérants au cours du stage Méthode de travail Une des spécificités de ce sujet de stage est la méthode de travail pratiquée par l'équipe R&D ; en effet, l'équipe a choisi une méthode de développement dite agiles ayant pour finalité l'amélioration de la qualité de ses produits. Parmi les méthodes agiles les plus connues, la méthode XP, pour «extrem Programming», ou encore Scrum, la plus répandue, peuvent être citées. Une méthode agile se compose d'un ensemble de pratiques à appliquer dans le cadre du développement informatique avec la promesse d'une qualité de production et une réactivité aux nouvelles demandes accrues par rapport à un développement utilisant d'autres méthodes (cycle en V10 par exemple). Elles sont particulièrement efficaces appliquées à des équipes de 10 à 15 développeurs. Ce genre de méthode s'adapte donc particulièrement bien à l'infrastructure et au métier de Smartesting. En effet l'équipe R&D est une équipe de développement comptant un effectif réduit et que de nouvelles demandes de leurs clients arrivent régulièrement et doivent être satisfaites au plus vite. La méthode agile de Smartesting se base sur les principes de l'«extrem Programming» (XP) sans en reprendre toutes les caractéristiques. En effet j'ai pu me rendre compte qu'il est difficile 10 Cycle en V : Modèle de gestion de projet axé autour de deux phases que sont conception du projet et sa validation. 10

11 d'appliquer à la lettre les recommandations de la méthode XP, dans la mesure où certaines sont assez difficiles et plutôt lourdes à mettre en place (la cotation par exemple est simplifiée par rapport à la pratique d'xp car l'évaluation du travail à effectuer est parfois trop floue). Ces pratiques ne sont donc pas figées, elles évoluent d'une entreprise à l'autre mais toutes reposent sur ce que l'on appelle les valeurs de l'agile Manifesto 11 que l'on retrouve chez Smartesting et décrites dans les parties suivantes Réactivité face au changement Première valeur prônée par le développement agile : la réactivité. Dans un autre mode, une phase de développement peut compter plusieurs semaines voir plusieurs mois et une fois cette phase terminée, elle est validée jusqu'à ce qu'elle satisfasse tous les aspects du contrat de développement. Dans le développement agile, la conception est fractionnée en courtes itérations (une à deux semaines maximum) validées au fur et à mesure de leur avancement. Chez Smartesting, une itération dure une semaine et se compose de tâches à réaliser concrétisées par des fiches. Celles-ci sont organisées sur un tableau (Figure 3) qui se divise selon les colonnes suivantes : A faire, En cours, A valider, En validation et Terminée. Les développeurs choisissent, en binôme, une fiche sur laquelle ils veulent travailler, la réalise et la place de sorte à ce qu'elle puisse être validée par un autre binôme (ou développeur seul) qui lui même la déclarera comme terminée ou a faire suivant le résultat de sa validation. Ce principe offre un avantage énorme pour la réactivité puisqu'une fiche dure rarement plus de deux journées de travail et donc une fiche qui arriverait entre temps pourrait être rapidement traitée. 11 Agile Manifesto : Texte établi par des experts du développement définissant ce que représente les méthodes agiles. 11

12 Figure 3 : Le tableau d'itération de Smartesting. Pour avoir une meilleure lisibilité du travail en cours, les fiches portent chacune une couleur indiquant son type : rouge pour les anomalies, blanche pour les fonctionnalités demandées par le client XP, jaune pour les tâches non-client XP, et bleue pour les tâches administratives et développements annexes. Typiquement, les rouges sont traitées en priorité, puis viennent les blanches et de priorité moindre pour la R&D, les jaunes et les bleues. Conjointement à cette division en fiches, une phase de cotation a été mise en place pendant laquelle le temps de développement et de validation de la fiche est évalué. En pratique, les développeurs donnent leur avis sur le nombre de points (un point équivaut à une demi-journée de travail en binôme) nécessaires à la terminaison d'une fiche. Une fois réalisée le nombre de points réellement utilisés est notifié à des fins statistiques. Cette pratique permet d'évaluer le travail à fournir pour des tâches futures et offre de la visibilité au développement. 12

13 Interaction avec les personnes Ce second point découle bien évidemment du fait que les méthodes agiles sont applicables dans une équipe ; les interactions entre ses membres sont donc essentielles. Smartesting répond à ce point avec une organisation encourageant la programmation en binôme aussi appelée «pair programming» avec des partenaires de programmation changeant le plus souvent possible. Cette pratique permet de partager les connaissances entre les membres et de favoriser la créativité au sein de l'équipe en permettant à un maximum de personnes de s'exprimer sur un sujet. Le processus de développement de l'équipe R&D favorise également les échanges. Premièrement, les développeurs se réunissent toutes les deux heures lors de «points synchro'» afin de vérifier le bon avancement de l'itération en faisant état de l'avancement de leurs travaux respectifs. Cela permet de demander de l'aide en cas de problème et de tenir les autres développeurs informés des tâches effectuées en parallèle des leurs. Deuxièmement, l'équipe effectue des réunions avec tous les développeurs intéressés, à de nombreuses occasions : avant d'initier une fonctionnalité importante afin de définir la meilleure technique à adopter pour l'implémenter, pour effectuer une démonstration du produit dans sa dernière version ce qui donne une vue d'ensemble des dernières fonctionnalités implantées, et à l'occasion de points techniques lorsqu'un membre prend la parole pour exposer un aspect technique qu'il juge intéressant pour tous. Enfin troisièmement, chaque itération se termine par une rétrospective lors de laquelle chaque membre de la R&D prend la parole afin d'évoquer son ressenti de la semaine ce qui permettra de développer les points forts et de corriger les problèmes de tout type. Le dernier aspect qui peut paraître anecdotique mais qui a son importance, est que la disposition des postes de travail de l'équipe R&D s'organise en cercle. Cela permet d'avoir toujours chacun des membres en vue et facilite les échanges oraux entre eux Produit fonctionnel Sous ce terme abstrait pour le néophytes en matière de développement agile se cache un aspect prônant une pratique différant quelque peu de l'enseignement théorique que l'on reçoit en tant qu'étudiant. Les théories en matière de développement agile soutiennent que les documents expliquant le code sont superflus si ce-dernier est suffisamment bien conçu. Le code produit par l'équipe R&D n'est donc complété par aucun document et ne contient de commentaires qu'en cas d'extrême nécessité. En revanche tous les noms de méthodes, variables, classes et autres éléments doivent être explicites afin que n'importe qui ayant un minimum de connaissance dans le langage concerné puisse comprendre le rôle de chacun des éléments à partir de son seul nom. Plus explicite que le premier aspect, un produit fonctionnel implique qu'il soit à tout moment utilisable sans anomalie. En effet, il n'est pas envisageable que l'équipe apporte sa contribution à quelque chose qui soit sur une mauvaise voie de développement. Pour s'assurer de la fonctionnalité de ses produits au fur et à mesure de leur développement, l'équipe a mis en place un système d'intégration continue. Concrètement, le code produit, une fois envoyé au gestionnaire de version, est compilé par des serveurs d'intégration qui vont s'assurer de la fonctionnalité de l'ensemble du projet en intégrant la modification. Cette vérification se fait au moyen d'exécution de tests de différents types (unitaires, d'acceptation, et de validation) sur la version courante du 13

14 projet. Cela permet de ne pas avoir de régression d'une version à l'autre et de corriger rapidement en cas d'anomalie pour ainsi s'assurer que la version sur le serveur est stable. Un tableau de diodes lumineuses indique constamment l'état de la version et notifie les anomalies en reproduisant les données envoyées par l'outil d'intégration continue Jenkins (Figure 4). Lors d'une anomalie, la notification est ainsi immédiatement observable au tableau et le détail de l'erreur est consultable en passant par Jenkins. Figure 4 : Aperçu de l'application Jenkins depuis un navigateur internet. Le développement en TDD12 aide également à maintenir un produit fonctionnel puisque cette pratique permet de donner une importance supérieure aux tests en les rendant indissociables de l'implémentation et s'assurant de leur fonctionnalité puisqu'il indiquent une erreur à l'origine (la fonction n'étant pas encore implémentée) puis montrent la validité des comportements de la fonction au fur et à mesure du développement Collaboration avec le client Dernier aspect mais non-moins important, un membre essentiel d'une équipe agile est le client, nommé client XP en méthode du même nom et chez Smartesting. En effet l'une des particularités dans ces méthodes est qu'elles ne visent pas la satisfaction d'un contrat de développement mais celle des besoins du client final représenté par le client XP. A ce titre, ce dernier est davantage sollicité afin qu'il guide le développement du projet. Chez Smartesting, cet aspect est particulier puisque ce rôle de client XP est tenu par deux employés, Arnaud BOUZY et Franck LEBEAU. Ils convertissent les besoins décelés par ceux qui étudient le marché et 12 TDD (Test Driven Development) : Pratique consistant à créer les tests d'un programme avant son implémentation. 14

15 communiquent avec les clients de Smartesting, en fonctionnalités à implémenter. Il est donc très souvent questionné pour le développement afin que la fonctionnalité satisfasse pleinement ses exigences. De plus, le client XP peut à tout moment utiliser le produit dans la version courante de développement grâce au système d'intégration continue assuré par SVN 13 et les serveurs d'intégration. Il peut ainsi réagir aux changements pratiquement instantanément. Il s'agit de ma première expérience dans une équipe agile ce qui est très motivant et rassurant dans le sens où les pratiques mises en œuvre ont fait leurs preuves pour ce qui est de la qualité générale du travail produit. Cela constitue surtout une très bonne expérience qui me sera sans aucun doute profitable par la suite Environnement de programmation Langages de programmation L'équipe R&D a depuis longtemps pris le parti de la programmation orientée objet en développant principalement en JAVA14. Cependant, certains autres langages sont parfois ponctuellement utilisés comme Python, Groovy ou même SQL par exemple, car ils sont plus pratiques ou indispensables dans un cas précis ; mais cette utilisation reste marginale de même que l'utilisation de scripts Linux et Windows (respectivement Shell et Batch). Parallèlement à la programmation en JAVA, la compilation du produit se fait au moyen de scripts Ant, remplacés progressivement au cours du stage par des scripts Maven ; loin d'être anecdotique dans un vaste projet comme CertifyIt, le «build15» demande une connaissance précise des règles de compilation et des scripts à implémenter afin de construire correctement les exécutables du projet. Bien que tous ces langages soient utilisés dans le projet, je n'ai pas eu l'occasion de tous les manipuler même s'il m'a fallu les comprendre pratiquement tous, ainsi que leur utilité dans le cycle de développement du projet, afin de mener à bien les différentes tâches qui m'ont été confiées. Un aspect important concernant les langages de programmation est que les développeurs de la R&D les utilisent, autant que possible, dans leur version la plus récente. De même, les nombreuses bibliothèques utilisées sont également à jour ce qui permet de travailler constamment avec les dernières innovations qu'elles proposent. 13 SVN (SubVersioN) : Outil permettant d'archiver le code produit en versions et de le récupérer d'une version à l'autre. 14 JAVA : Langage de programmation orienté objet créé par Sun Microsystems. 15 Build : Terme répandu désignant la compilation du projet. 15

16 Dernier point et non des moindres, les tests sont omniprésents tout au long du processus de programmation. Ainsi chaque fonctionnalité s'accompagne de son lot de tests qu'il incombe au développeur de la fonctionnalité d'implémenter afin de valider son travail (la validation ne s'arrêtant pas au verdict de ce test comme décrit dans les parties précédentes). Ces tests sont notamment constamment exécutés par les serveurs d'intégration pour assurer la stabilité de la version courante du projet Poste de travail Concernant les logiciels utilisés pour le développement, tous les postes des développeurs de la R&D intègrent, autant que possible, les mêmes logiciels ; cela dans le but de faciliter le «pair programming». La seule véritable différence d'un poste à l'autre est le système d'exploitation (Linux ou Windows) ce qui permet de vérifier la portabilité des exécutables du projet CertifyIt. Malgré cela, il est possible pour un développeur d'avoir ses propres outils du moment qu'ils ne sont pas une contrainte au binômage. L'environnement suivant se retrouve donc sur chaque poste de travail : IntelliJ IDEA : IDE16 principal de développement JAVA. Eclipse : Un autre IDE mais utilisé uniquement dans le développement de «plugins» Eclipse et pour le lancement de RSM ou Papyrus dans dans le cadre du test de ces «plugins». SVN : Système de gestion de version pour garder le code du projet à jour entre les développeurs et de conserver une trace des versions précédentes. Outils d'intégration continue : ces outils sont accessibles au moyen d'un navigateur internet et permettent la consultation des données relatives à l'avancement du produit. Chaque poste comporte donc : FitNesse : Permettant l'exécution de tests dits d'acceptation. Jenkins : Le principal outil d'intégration continu permettant de consulter l'état de tous les tests sur la version en cours. Trac : Permettant de suivre l'évolution de la version au fil des modifications, ajouts et suppressions de code, au travers des «commits» effectués sur le serveur SVN. Wiki interne : Utilisé par Smartesting pour partager diverses informations à destination de l'ensemble des membres de la société. 16 IDE (Integrated Development Environment) : Ensemble d'outils de développement informatique. 16

17 Figure 5 : Aperçu de l'application truc depuis un navigateur internet. Figure 6 : Aperçu de l'application FitNesse depuis un navigateur internet. Bien que ce type d'environnement ne me soit pas complètement étranger, les outils utilisés étaient nouveaux et j'ai pu me rendre compte de leur efficacité par rapport à ceux que j'utilisais auparavant. 17

18 3. Travail réalisé 3.1. Planning Axes de travail Comme déjà évoqué, Smartesting travaille sur un mode de développement continu afin de faire évoluer ses produits au fil du marché et des demandes clients. Cependant, l'évolution du produit est jalonnée par des «releases» majeures (Figure 7) regroupant l'ensemble des fonctionnalités classées en axes de développement. Ces jalons définissent ainsi l'orientation prise par les produits sur une période assez longue. Concrètement, une «release» majeure est développée sur plusieurs mois et définie ce vers quoi va s'orienter le produit pendant cette période de développement. Chacune porte un nom et un numéro de version comme c'est le cas avec le logiciel Eclipse par exemple. Durant ces périodes de développement, Smartesting sort néanmoins des «releases» d'itération chaque semaine ou presque. Ce stage couvre la fin d'une «release» et l'intégralité d'une autre ; la suite décrit les orientations prises lors de ces phases de développement ainsi que le planning prévu : Figure 7 : «Roadmap» des produits Smartesting sur la durée du stage 18

19 Comme le montre la figure précédente, les «releases» marquent les avancées suivantes : Electra (5.1) : Support QC 10 : La solution Smartesting supporte le logiciel de test QC 10. Amélioration BPMN17 : Certaines modifications pour améliorer la gestion du BPMN avec CertifyIt. Fidis (5.1.1) : Licence par PU18 : Le système de gestion de licence est entièrement revu pour intégrer la gestion des PU. Performances : Amélioration des performances générales de la solution. Amélioration BPMN : Certaines modifications pour améliorer la gestion du BPMN avec CertifyIt en intégrant les derniers besoins des clients. Support HP ALM 11 : La solution Smartesting supporte le logiciel ALM 11 de gestion de cycle de vie d'application. Fidis (5.2) : CertifyIt RCP Eclipse : Intégration totale de CertifyIt à l'environnement Eclipse au moyen d'une plateforme RCP. Import BPMN : Le BPMN peut être importé dans la solution Smartesting. En tant que développeur, j'ai donc travaillé sur chacune de ces parties mais de façon inégale suivant l'affinité que j'avais avec tel ou tel aspect et la quantité de travail pour couvrir les exigences liées à une avancée technique Semaine type Ainsi que je l'ai décrit précédemment, les itérations de développement chez Smartesting se déroulent sur une semaine. Chaque itération est organisée de manière à permettre à l'équipe de remplir les objectifs de développement mais aussi à favoriser sa créativité et la maintenabilité du code en intégrant une période de «Slack19» lors de laquelle les développeurs travaillent sur des fonctionnalités non requises par le client XP. Cette période est prise en compte lors de la planification de la semaine. Dans la pratique, le «Slack» sert à explorer des techniques de 17 BPMN (Business Process Modeling Notation) : Représentation graphique d'un processus métier. 18 PU (Production Unit) : Unité de production utilisé par Smartesting représentant 160 heures d'utilisation. 19 Slack : En gestion de projet, sur la réalisation d'une tâche, période entre la date estimée et la date effective. 19

20 développement, améliorer le code ou mettre en place des éléments destinés à faciliter le développement futur. Le déroulement de la semaine est entrecoupé de réunions lors desquelles tous les membres de la R&D se retrouvent. Outre la rétrospective ces réunions sont des «points synchro'» dont le rôle a été décrit précédemment. Il existe deux «points synchro'» particuliers : l'engagement et le «morning meeting» ; le premier permet, en début de semaine, d'exposer le travail à faire durant l'itération et de l'évaluer, le second est un «point synchro'» plus long dans lequel les membres prennent plus de temps pour développer certains points et éventuellement parler d'autres aspects que le travail de la R&D. L'emploi du temps ci-dessous illustre l'organisation d'une itération : Lundi Mardi Engagement Point syncho' Mercredi Jeudi Vendredi 9h - 10h 10h - 10h10 10h10-12h 12h - 12h10 Rétrospective Morning meeting 12h10-14h 14h - 15h 15h - 15h10 Point syncho' 15h10-17h 17h - 17h10 Point syncho' 17h10-18h Bleu : période de développement Jaune : période de «Slack» Rose : Réunions Pour ma part, je participais complètement à la période de réalisation des fonctionnalités demandées par le client XP, mais la période de «Slack» me servait à comprendre davantage le code de la R&D et à me mettre à niveau par rapport aux autres développeurs ; j'ai tout de même travaillé sur les fiches liées au «Slack» de temps à autre. 20

21 Planning de travail Bien que les domaines sur lesquels j'ai travaillé soient très dispersés sur la durée du stage, il est tout de même possible de les regrouper pour établir le planning de travail ci-dessous (en occultant néanmoins les développements ponctuels de domaines minimes). Février Mars QC 10 Avril Mai Juin Gestion de licence QC 10 / Reqtify QC 10 / Testlink* Maintenance Bleu : Travail Electra 5.1 Vert : Travail Fidis Rose : Maintenance * Testlink : Logiciel de gestion de tests d'application supporté par Smartesting. Notons que bien que la division se fasse par mois, cela ne veut pas forcément dire que j'ai travaillé sur la tâche durant l'ensemble du mois Analyses et Développements J'ai travaillé dans plusieurs domaines différents pendant ce stage : développement de «plugins» Eclipse, algorithmie appliquée à la preuve de programme, système de licence, «parsers», système de «build», interface graphique ou encore programmation «multi-threads» sans oublier les tests des fonctionnalités sur lesquelles j'ai travaillé. Les parties suivantes décrivent le travail réalisé dans les domaines Observation Le premier rôle qui m'a été confiée fut celui d'observateur. En effet, en tant que nouveau développeur, je devais m'approprier le code en place afin d'en comprendre la substance. Durant la première semaine, j'ai été livré à moi même face au code sans autre aide que celle des membres de l'équipe R&D et uniquement pour ce qui est technique (c'est à dire pas d'aide sur la compréhension du rôle d'une portion de code). Cet exercice fut difficile car c'était mon premier contact avec le travail de la R&D et que le code paraît, au premier abord, radicalement différent du code JAVA que je pouvais élaborer auparavant. Néanmoins une telle activité est utile à la R&D puisqu'elle permet de vérifier que leur code est compréhensible pour un nouveau développeur de leur produit. Au terme de cette première semaine, j'ai donc pu faire un compte rendu des points que j'avais compris, bien sûr j'étais loin de saisir toutes les subtilités d'un code qui compte plus de deux mille cinq cents classes JAVA avec près de cent milles lignes de code et ce, sans compter les outils annexes comme les scripts de compilation par exemple. 21

22 Cette première semaine terminée, j'intégrai concrètement la R&D et commençai à développer en «pair programming» avec les autres membres de l'équipe. Tout comme la première semaine, les premiers binômages ont plus été de l'observation durant lesquels les développeurs m'apprenaient leur pratiques de développement, les détails du code et les différents aspects du produit afin que je monte en compétence et que je puisse, à terme, être capable d'avoir un apport concret, en terme de programmation, pour l'équipe. Il m'aura fallu quelques semaines pour avoir un niveau de compétence me permettant d'apporter quelque chose de concret à l'équipe mais il faut dire que la période d'observation coïncidait avec la fin de la «release» CertifyIt Electra (5.1), et donc il est d'autant plus difficile d'arriver à la fin d'un développement lorsque les autres membres ont une maitrise totale des nouvelles fonctionnalités implantées à la différence d'un nouveau stagiaire, l'écart se fait clairement ressentir. Cependant, au fil des binômages, j'ai pu commencer à coder par moi-même plutôt que de simplement observer mon binôme et j'ai donc développé sur quelques fiches avant l'achèvement d'electra Travaux sur les «publishers» et connecteurs «Publisher» QC Lors de ma première semaine en tant que développeur au sein de la R&D, le principal travail occupant les membres était la compatibilité avec le logiciel gestion de tests développé par HP : Quality Center (ou QC) (Figure 8). Comme je l'ai évoqué précédemment, Smartesting génère des tests et permet leur publication vers un logiciel tiers de gestion et/ou d'exécution de ces tests. Cette publication est faite au moyen des «publishers» à raison d'un par logiciel. Ces «publishers» se présentent sous la forme d'une archive JAR20 qui, lors de son exécution, prend en entrée un fichier représentant les tests générés sur un projet Smartesting, et le convertit en données permettant l'utilisation des tests dans le logiciel adéquat. Dans le cadre de QC, le «publisher» envoie les tests directement dans la base de données de l'application afin de pouvoir les exécuter. Il ne suffit donc pas de générer un fichier qui sera ouvert par QC mais de communiquer directement avec le logiciel ce qui est plus compliqué dans la mesure où il faut mettre en place cette interface de communication. 20 JAR (Java ARchive) : Archive contenant les définitions des classes JAVA et les métadonnées d'un programme. 22

23 Figure 8 : Publication de tests dans HP Quality Center. Ma venue chez Smartesting coïncidait avec la sortie imminente de la «release» Electra, intégrant le développement du publisher QC ; je n'ai donc pas eu l'occasion de suivre l'intégralité du développement mais j'ai néanmoins pu travailler dessus. Une des tâches qui m'a été confié avec un binôme fut de stocker les fichiers dit d'administration servant à faire le lien entre un test dans QC et un test Smartesting. Ces fichiers étaient mis par défaut dans un répertoire de l'arborescence QC choisi par Smartesting et les besoins remontés montraient que les utilisateurs souhaitaient choisir le répertoire par eux-même. Mon binôme et moi-même avons donc modifié le code afin de prendre en compte ce besoin. Pour ce faire, nous avons modifié le fichier XSD gérant le format du fichier XML indiquant la configuration du «publisher» QC afin d'intégrer le champ indiquant le chemin dans lequel seront stockés les données administratives : <xsd:element name="test-publishing"> <xsd:complextype> <xsd:attribute name="testpath" type="xsd:string" use="required"/> <xsd:attribute name="testsetpath" type="xsd:string" use="required"/> <xsd:attribute name="deprecationpolicy" type="xsd:string"/> <xsd:attribute name="projection" type="xsd:string" use="optional"/> <xsd:attribute name="dataadministrationpath" type="xsd:string" use="required"/> </xsd:complextype> </xsd:element> 23

24 Il nous a ensuite fallu créer la méthode pour intégrer ce nouvel élément pour remplacer la gestion par un chemin imposé : public String getdataadministrationpath() { return configuration.gettestpublishingelement().getattribute("dataadministrationpath"). getvalue(); Cette méthode est ensuite utilisée au besoin pour récupérer le paramètre. Par la suite, j'ai retravaillé sur le «publisher» QC lors du jalon Fidis afin d'intégrer certains nouveaux besoins. En effet, lors de la publication de tests, si un test est détecté comme obsolète, il est automatiquement supprimé de la base QC ; or certains clients utilisent ce test dans un projet de test autre que celui de Smartesting ce qui entraine un problème de perte d'information. Il a donc fallu modifier le «publisher» afin de supprimer le test uniquement s'il n'est utilisé que par le projet Smartesting «publisher» Testlink Outre le «publisher» QC, j'ai brièvement travaillé sur son alter ego TestLink (Figure 9). Fonctionnant sur le même principe que le «publisher» QC, il communique directement avec l'application ; cependant l'api21 de la dernière version de Testlink étant incomplète, il a parfois fallu modifier directement la base de données de Testlink au moyen de requêtes SQL plutôt que de passer par des méthodes JAVA : public void createtcstep( final int stepid, final int stepindex, final String actions, final String expectedresults) { database.executeupdate( "INSERT INTO tcsteps values ('" + stepid + "','" + stepindex + "','" + escapesql(actions) + "','" + escapesql(expectedresults) + "'," + "'1','1')"); J'ai donc participé à l'écriture des méthodes formant un équivalent d'api de communication avec Testlink, ces méthodes étant appelées à être remplacées par celles de l'api officielle Testlink. 21 API (Application Programming Interface) : Ensemble de fonctions permettant l'interaction entre les programmes. 24

25 Figure 9 : Publication de tests dans TestLink Connecteur Reqtify Dernier logiciel tiers avec lequel j'ai travaillé : Reqtify (Figure 10) permettant de gérer la couverture d'exigences. Ce logiciel n'est pas lié par un «publisher» mais un connecteur, la différence étant que les logiciels connectés sont utilisés pour importer des données dans la solution Smartesting. Dans le cas de Reqtify, il a fallu récupérer la couverture des exigences du logiciel puis la convertir dans un format Microsoft Excel utilisable par les outils de la solution ; ainsi il est possible d'utiliser Reqtify pour décrire les exigences, d'exporter les données et de les utiliser dans la solution. 25

26 Figure 10 : Gestion exigences avec Reqtify. Pour ce faire, mon binôme et moi-même avons dans un premier temps récupéré les données de Reqtify : nous avons converti les données XML des fichiers Reqtify en objets JAVA au moyen de la bibliothèque JDOM ; la DTD ou le XSD du fichier n'étant pas disponible, nous avons dû analyser par nous-même le fichier afin de comprendre sa structure. Ceci fait, nous avons ensuite exporté les objets JAVA au format XLS de Microsoft Excel au moyen de la bibliothèque POI. Grâce à ce connecteur, il est désormais possible de gérer les exigences avec Reqtify puis de les utiliser avec la solution Smartesting ce qui participe à la compatibilité des outils de la solution Gestion de licence Le travail occupant le plus longtemps la R&D pendant la durée de ce stage fut la mise en place d'un gestionnaire de licence pour les produits Smartesting. Principal élément de la «release» Fidis 5.1.1, ce nouveau gestionnaire de licence vient remplacer celui en place car il répond mieux aux besoins des clients de Smartesting. Le nouveau gestionnaire s'applique uniquement à l'utilisation des «plugins» Eclipse contrairement à l'ancien qui gérait le logiciel CertifyIt. Ce changement est dû au fait que la majorité du temps passé à utiliser les produits Smartesting se fait dans la modélisation et donc sur 26

27 l'utilisation des «plugins», CertifyIt servant uniquement à générer les tests. Ainsi il est possible de faire un système de licence «pay-per-use» (payement à l'utilisation) dans lequel l'utilisateur paye uniquement ce qu'il consomme. Smartesting vend ainsi des PU qui permettent l'utilisation des produits pendant une durée déterminée. Outre l'utilisation de PU, ce gestionnaire permet de limiter le nombre d'utilisateurs utilisant l'application simultanément comme c'était déjà le cas avec l'ancien gestionnaire ; c'est ce qu'on appelle une licence flottante. La mise en place de ce dispositif peut être divisé en plusieurs parties : l'analyse du besoin et les choix de développement, l'implémentation du gestionnaire et enfin la création d'ihm 22 pour l'utilisateur final. Pour des raisons de confidentialité, certains éléments du développement ne seront pas complètement détaillés ici Analyse La phase préalable au développement est l'analyse afin de définir les choix de l'implémentation. La description des besoins et les fonctionnalités à implémenter sont données par les clients XP, l'équipe R&D est en revanche en charge de définir les choix techniques et de les proposer aux clients. Je n'ai pas participé à la sélection du gestionnaire de licence sur lequel se base Smartesting car il a été choisi juste avant le stage. La R&D a examiné au cours de «spikes» (tâches durant lesquelles les membres de la R&D explorent de nouvelles solutions) deux gestionnaires et a sélectionné Orion qui répond au besoin. La bibliothèque Orion permet de se connecter à un serveur pour récupérer des PU et de les utiliser sur une machine, soit en mode connecté au serveur, soit en mode déconnecté. Elle possède une API JAVA qui permet de l'utiliser directement dans le code des produits Smartesting Implémentation du gestionnaire Le choix de la bibliothèque effectué, la R&D peut alors développer la fonctionnalité. Plusieurs fiches ont été rédigés par les client XP pour découper l'implémentation et permettre aux développeur de se répartir les tâches Interfaçage avec le serveur La première partie consiste à développer les classes permettant d'interagir avec le serveur de licence afin de pouvoir effectuer les opérations de contrôle par la suite. Pour ce faire, les développeurs de la R&D dont moi-même avons mis en place un adaptateur permettant de faire le lien entre le serveur de licence et l'application (en l'occurrence, un «plugin» Eclipse dont le rôle sera détaillé par la suite). 22 IHM (Interface Homme-Machine) : Interface graphique permettant d'utiliser les fonctionnalités d'un système. 27

28 Cet adaptateur se présente comme un objet JAVA fournissant les méthodes permettant les actions suivantes : Récupérer un jeton d'utilisation pour une licence. Rendre le jeton en cours d'utilisation. Prendre des PU sur le serveur. Redonner les PU non-utilisés au serveur. Récupérer les informations de la licence en cours. La difficulté de l'implémentation réside dans le stockage local des PU, en effet une fois récupérés sur le serveur, les PU doivent être stockés sur la machine de façon sécurisée. Bien que la majorité de la sécurité soit assurée par la bibliothèque Orion, il a néanmoins fallu stocker ces PU dans un fichier en cryptant son contenu. Ce fichier est ensuite soumis à des dispositifs d'orion pour éviter qu'il puisse être sauvegardé puis réutilisé par la suite comme il l'était au moment de la sauvegarde. Cet adaptateur ne possède pas lui-même de tests, ceux-ci étant faits sur les classes utilisant cet adaptateur (ce genre de cas étant particulier) Implémentation du gestionnaire de licence Une fois l'interfaçage opérationnel, la suite de l'implémentation fut de créer les classes gérant la licence à proprement parler. Cette gestion se fait au travers des deux gestionnaires modélisés par les classes suivantes : FloatingLicenseManager : Ce premier gestionnaire gère les licences flottantes c'est à dire qu'il est utilisé lorsque l'on se connecte au serveur pour récupérer une licence flottante. Ce gestionnaire utilise l'adaptateur. NodeLockedLicenseManager : Ce second gestionnaire est en charge des licences propres à une machine unique. Ce gestionnaire ne passe pas par l'adaptateur, il utilise directement les méthodes de la bibliothèque Orion. 28

29 Ces gestionnaires ont pour rôle principal de gérer les informations de la licence en cours, de contrôler les droits d'utilisation et de gérer la consommation de PU. J'ai moi-même travaillé activement sur la mise en place de ces trois éléments : La gestion des informations de licence se fait au travers de trois interfaces (Figure 11). Lors de l'appel à la méthode du gestionnaire de licence getlicenseinformation(), le retour peut être de différent type : ErrorLicenseInformation : Une erreur s'est produite au niveau du serveur et les informations n'ont pu être récupérées. InvalidLicenseInformation : La licence est invalide (parce qu'elle a expiré, qu'il n'y a plus de PU ou que le nombre maximum d'utilisateurs connectés est atteint). ValidLicenseInformation : La licence est valide. Figure 11 : Modélisation simplifiée des informations de licence. 29

30 La particularité de cette implémentation réside dans l'utilisation du «pattern visitor», la méthode getlicenseinformation() renvoyant une variable de type LicenseInformation, il est nécessaire par la suite de tester le type réel de l'objet. La mise en place du visiteur se fait au moyen de la surcharge de la méthode accept() lors de l'implémentation des interfaces (ValidLicenseInformation dans l'exemple suivant) de la façon suivante : class ValidLicenseInformationImpl { public <T> T accept(final LicenseInformationVisitor<T> visitor) { return visitor.visitvalid(this); Il est ensuite possible d'utiliser l'interface LicenseInformationVisitor pour implémenter les traitements à effectuer pour chacun des types comme ceci : getlicenseinformation().accept( new LicenseInformationVisitor<T>() { public T visitvalid(final ValidLicenseInformation licenseinformation) { // code d'une licence valide public T visiterror(final ErrorLicenseInformation licenseinformation) { // code d'une licence erronnée public T visitinvalid(final InvalidLicenseInformation licenseinformation) { // code d'une licence invalide ); Deuxième rôle, le contrôle des droits se fait au moyen de la méthode hasrightfor() prenant en paramètre un prédicat (Predicate de la bibliothèque Guava) s'appliquant aux informations de la licence. La majorité de l'implémentation est donc faite dans le prédicat : public boolean hasrightfor(final Predicate<LicenseInformation> predicate) { return predicate.apply(getlicenseinformation()); Predicate<LicenseInformation> monpredicat = new Predicate<LicenseInformation>() { public boolean apply(final LicenseInformation input) { // traitements de vérification par rapport aux informations de licence ; Ce type d'implémentation a l'avantage de pouvoir être facilement modifié et d'être polyvalent. En effet Smartesting possède deux types de droits correspondant à deux éditions de la solution, «Basic» et «Enterprise», ce qui se traduit au final par deux prédicats avec chacun leur propre traitement. Par la suite, il suffit d'appeler la méthode hasrightfor() avec le prédicat souhaité pour vérifier que l'utilisateur a le droit d'effectuer une action. Typiquement, elle est appelée avant le traitement lancé par un clic sur un bouton (export du modèle, contrôle du modèle, ). 30

31 La consommation de PU quant à elle fut compliquée à mettre en place du fait de la quantité de travail et de l'aspect sensible du domaine de la gestion de licence. Elle a nécessité plusieurs «refactoring» avant d'aboutir à quelque chose de clair et fonctionnel. Ce système étant sensible en terme de sécurité, je ne détaillerai pas complètement son fonctionnement. Le système en place décompte les PU toutes les dix minutes de travail effectives, c'est à dire que le décompte se fait uniquement lors de l'utilisation du modeleur. Un objet JAVA est en charge de la consommation locale des PU. Il possède une méthode tic() qui à chaque appel, met à jour la quantité locale de PU par rapport au temps écoulé (de manière sécurisée de sorte à empêcher le décompte en modifiant l'horloge interne du système). L'objet possède également des méthodes suspend() et resume() afin de suspendre et reprendre le décompte de PU dans le but de gérer les cas où l'utilisateur garde son modeleur ouvert mais ne l'utilise pas Création du «plugin» Eclipse Les classes étant implémentées et le gestionnaire utilisable, il a fallu le lier au modeleur. Pour ce faire, l'équipe R&D a choisi de développer un «plugin» dont dépendront tous les autres «plugins» de Smartesting. De cette façon l'utilisation des «plugins» de modélisation oblige l'import du gestionnaire de licence sur la plateforme. La création d'un «plugin» Eclipse est un exercice de programmation particulier, il faut tout d'abord définir le point d'extension qui indique ce que va apporter le «plugin» à Eclipse. Ce point est techniquement intéressant puisque le point d'extension choisi permet à Eclipse de reconnaître le gestionnaire comme un module et de ce fait, il est utilisable par les autres «plugins» présents sur la plateforme. Ce module utilise l'injection de dépendances de la bibliothèque Guice (représenté par peaberry dans le code). L'injection de dépendances permet de créer à la volée des instances d'objets ou dans notre cas de récupérer le singleton du gestionnaire de licence (le singleton est préférable dans ce cas puisqu'il n'existe qu'un seul gestionnaire de licence pour chaque plateforme). On obtient donc le point d'extension suivant défini dans le fichier XML décrivant le «plugin» : <extension point="org.ops4j.peaberry.eclipse.modules"> <module class="com.smartesting.eclipse.licensemanager.licensemanagermodule"/> </extension> La classe LicenseManagerModule possède la méthode fournissant l'instance du gestionnaire de licence (ici de type ConfiguratbleLicenseManager) public ConfigurableLicenseManager provideslicensemanager() { return LicenseManagerPlugin.getInstance().getConfigurableLicenseManager(); Le étant une annotation peaberry permettant d'indiquer que cette méthode doit être appelée pour injecter un objet de type ConfigurableLicenseManager. A l'appel, on 31

32 retourne donc l'instance du singleton. Une fois cette implémentation faite, on peut utiliser le gestionnaire de licence dans une méthode en utilisant l'injection de dépendances comme suit public void mamethode(configurablelicensemanager licencemanager){ // traitement utilisant le gestionnaire de licence Le «plugin» créé, il est possible d'utiliser le gestionnaire de licence sur une plateforme Eclipse comme RSA/RSM ou Papyrus. Il reste néanmoins une chose sur laquelle j'ai travaillé dans l'implémentation du «plugin» : le lien avec les gestionnaires d'événements afin d'associer les méthodes suspend() et resume() décrites plus haut, dans le but de gérer l'inactivité de l'utilisateur. Eclipse a de nombreux événements associés à l'utilisation, j'ai choisi d'utiliser les événements liés à l'activité des composants graphiques de la fenêtre. J'ai ainsi associé la méthode suspend() à l événement envoyé lors de la dé-sélection d'un objet graphique intégré dans la fenêtre, et resume() lors d'une sélection d'un objet du même type. J'ai choisi un objet graphique de la fenêtre plutôt que la fenêtre elle-même car ce dernier type d événement a des comportements inattendus (lors du détachement d'un élément de la fenêtre principal vers un «pop-up» par exemple). display.addfilter( SWT.FocusIn, new Listener() { public void handleevent(final Event event) { licensemanager.resume(); ); display.addfilter( SWT.FocusOut, new Listener() { public void handleevent(final Event event) { licensemanager.suspend(); ); Écriture des tests de validation Dernière étape de l'implémentation du gestionnaire : les tests de ce-dernier. La majorité des tests de cette partie n'ont pas été implémentés dans le cadre de la programmation en TDD. En effet, les tests unitaires ne sont pas adaptés au test de ce genre de classe et dans ces cas particuliers, la R&D de Smartesting utilise ce qu'ils appellent des tests de validation. La différence étant qu'un test de validation teste davantage d'aspects qu'un test unitaire et peut par conséquent être plus lent. Plus d'une trentaine de tests ont été écrits afin de simuler les scénarios d'utilisation du gestionnaire de licence ; j'ai participé à l'élaboration de pratiquement tous les tests concernant le gestionnaire de licence flottante (un autre binôme s'occupant des tests du gestionnaire de licence fixe). 32

33 Voici un exemple de test de cette partie public void testcheckoutinvalidlicense() { final ConfigurableLicenseManager licensemanager = createfloatingmanager(**confidential (licence erronée)**); try { assertfalse(licensemanager.hasrightfor(**prédicat de droit**)); finally { licensemanager.stop(); Dans ce test, on vérifie qu'une licence erronée n'aura pas les droits d'utilisation ; le dispositif try/finally permet de s'assurer de la fermeture du gestionnaire de licence même si le test échoue Création d'ihm Le gestionnaire terminé et testé, la dernière partie de l'implémentation consiste à le rendre utilisable par les utilisateurs au travers d'une interface graphique. Le choix a été fait de mettre en place une page de préférences Eclipse dans laquelle l'utilisateur renseigne les champs nécessaires à la connexion au serveur ou à l'utilisation d'une licence propre à sa machine. L'implémentation de cette page de préférences se fait au moyen d'un «plugin» Eclipse dont le point d'extension est org.eclipse.ui.preferencepages. N'ayant pas moimême participé à la mise en place du «plugin», je ne m'étendrai pas sur cette partie. En revanche, j'ai été très actif dans le rendu des informations de la licence au niveau de cette page de préférences (Figure 12). 33

34 Figure 12 : Rendu des information de licence au niveau de la page de préférences. Les informations que l'on peut voir dans le cadre du bas de l'illustration ci-dessus donnent les caractéristiques de la licence, elles se basent sur les objets d'information de licence décrits auparavant. Afin de mettre en place ce rendu, j'ai utilisé avec mes binômes durant ce développement, la bibliothèque StringTemplate permettant de mettre en place un patron définissant l'emplacement 34

35 d'un élément. Ce patron est mis en place au moyen du fichier STG de StringTemplate, ce fichier se présente sous la forme de fonctions d'un langage propre à StringTemplate. Le code ci-dessous est celui de la fonction utilisée lors du rendu d'une licence valide comme sur la figure : valid(label, license) ::= << <if (license.valid)><display_validlicense(label, license)><endif> >> display_validlicense(label, license) ::= << <label.valid> <license.edition> <display_remaininglicenseduration(label, license)> <if (license.pumonitoring)> <display_licensepu(label, license)><endif> <if (license.options.restriction)> <label.restriction> <license.options.restriction><endif> <if ((license.expiring) (license.exhausting))> <display_licensewarnings(label, license)><endif> >> Le patron en place, il est possible de l'utiliser dans le code JAVA. On l'utilise ainsi dans la fonction renderlicenseinformation() retournant la chaîne formatée par StringTemplace : public static String renderlicenseinformation(final LicenseInformation licenseinformation) throws IOException { final STGroup group = new STGroupString( IOUtils.toString(LicenseInformationToString.class.getResourceAsStream("information.stg"))); group.registerrenderer(pu.class, new PuRenderer()); return licenseinformation.accept( new LicenseInformationVisitor<String>() { public String visitvalid(final ValidLicenseInformation license) { return group.getinstanceof("valid").add("label", new LabelBundle()).add("license", new ValidLicenseModel(license)).render(); ); On retrouve l'appel à la fonction valid() et au fichier STG. Un premier point important de ce code est l'utilisation d'un Renderer. En effet StringTemplate ne peut manipuler que types String et ne sait pas afficher un autre type d'objet. Dans notre cas, on souhaite afficher des PU et pour cela, on utilise la classe PuRenderer. Cette classe est implémentée de la façon suivante : private static final class PuRenderer implements AttributeRenderer { public String tostring(final Object o, final String formatstring, final Locale locale) { return ((Pu)o).toDoubleAs(Pu.TimeUnit.PU) + " PU"; Les objets de type PU sont ainsi convertis en un type String et peuvent être utilisés par StringTemplate qui saura automatiquement transformer ce type. 35

36 Le second point important de ce code est l'internationalisation du rendu. Smartesting est actuellement disponible en deux langues : l'anglais et le français. Afin d'internationaliser le rendu, j'ai utilisé le même système que la R&D a coutume d'utiliser. Les phrases et mots à traduire sont stockées dans un fichier PROPERTIES dans lequel on retrouve ce genre d'informations (ici le libellé du statut de la licence) : license.label.error = License error license.label.valid = Valid license license.label.invalid = Invalid licence Pour récupérer ces informations, on utilise le code suivant : final MessageTranslator translator = createmessagetranslator(preferencepageimpl.class); On obtient ainsi un objet ayant accès aux données du fichier PROPERTIES (ce type de fichier étant relatif à une classe, on indique la classe concernée et non pas directement le fichier, ici la classe PrefrencePageImpl) ; il faut ensuite transmettre ces informations à StringTemplate. Pour ce faire, j'ai utilisé le passage de paramètre de StringTemplate qui permet à un objet JAVA d'être transmis au fichier STG. Par exemple, pour récupérer le statut, il faut procéder de la manière suivante : On créé l'objet ici représenté par la classe LabelBundle. public static final class LabelBundle { private final MessageTranslator translator = createmessagetranslator(preferencepageimpl.class); public String geterror() { return translator.getmessage("license.label.error"); public String getinvalid() { return translator.getmessage("license.label.invalid"); public String getvalid() { return translator.getmessage("license.label.valid"); On indique à la fonction qu'elle reçoit en paramètre l'objet comme ceci : group.getinstanceof("valid").add("label", new LabelBundle()).render(); On a ainsi accès à cet objet dans la fonction du fichier STG et on peut utiliser ses données suivant la norme JavaBeans selon laquelle on appelle la méthode getvalid() de l'instance label par label.valid. 36

37 Cette partie a été développée en utilisant le TDD, elle s'accompagne donc de tests de la fonction renderlicenseinformation() afin de valider le comportement de celle-ci. Le test ci-dessous est un de ceux qui ont été écrits public void testerrorlicense() throws IOException { assertthat( renderlicenseinformation(errorlicense("reason")), is("license error\n\n\treason")); Les autres tests sont similaires, suivant l'objet de type LicenceInformation qu'ils reçoivent, ils testent le rendu «Packaging» La dernière chose sur laquelle j'ai travaillé dans cette partie fut le «packaging». Lors de l'utilisation finale, le système de gestion de licence s'accompagne du serveur qui est déployé chez les clients. Pour installer ce serveur, il faut exécuter certains scripts système (Batch et Shell respectivement pour Windows et Linux). J'ai travaillé sur les scripts permettant de créer la base de donnée du serveur. Je ne peux malheureusement pas en dévoiler le code pour des raisons de confidentialité. La conception d'un gestionnaire de licence fut la plus grosse partie du stage et elle a occupé les développeurs de la R&D pendant de nombreuses semaines. Il a souvent fallu revenir sur des éléments au gré des nouveaux besoins et de comportements parfois hasardeux des bibliothèques (Orion par exemple comportait certains problèmes qui ont été corrigé suite aux retours de la R&D). Aujourd'hui le gestionnaire de licence est utilisé par les consultants pour une première phase de test en interne, avec succès jusqu'à maintenant Maintenance Parallèlement au développement des fonctionnalités sus-citées, j'ai participé à de nombreuses tâches de maintenance qui incluent la correction de «warning» signalés par les outils d'intégration continue mis en place, le «refactoring» du code, ou encore la correction de «bugs» qui arrivent parfois en fiche rouge. Les tâches dans ces domaines sont nombreuses et généralement succinctes et pour cette raison, je ne détaillerai que les plus importantes ou marquantes Correction de «warnings» La correction de «warnings» est une pratique qui peut paraître anodine mais au-delà de l'alerte par rapport aux standards JAVA, un «warning» peut indiquer un problème de conception dont la correction peut simplifier une portion de code. Ce type d'alerte est indiqué, pour le code JAVA, par l'application PMD qui émet un rapport consultable en utilisant Jenkins (Figure 13). 37

38 Figure 13 : Liste des «warnings» détectés par PMD via Jenkins. Pour ma part, j'ai corrigé près d'une cinquantaine de «warnings» de plusieurs types et d'importance variable : Optimisation : Dans certaines circonstances, des mots clés JAVA tels que «static» ou «final» sont recommandés ; cela permet notamment à la JVM d'effectuer certaines optimisations ce qui a pour effet un gain de performance (pas forcement perceptible). Il peut aussi arriver qu'au fil des modifications successives du code JAVA que certaines portions du code soient inutilisées, il convient donc de les supprimer en s'assurant que c'est bien du code mort. J'ai donc eu l'opportunité d'alléger quelque peu le code en corrigeant ce type d'alerte. Conception : L'utilisation des sorties standards (System.out et System.err) peut être génératrice d'alertes. En effet, ce genre de pratique généralement utilisée pour le «debug» est 38

39 déconseillée car elle n'est adaptée ni à un véritable rendu d'information, ni à une analyse ; l'utilisation de «loggers» sur lesquels peuvent s'effectuer plus d'opérations et configurations est préférée. Smartesting a mis en place un «logger» Log4J mais il reste parfois des utilisations des sorties standards qu'il convient de corriger. Les développeurs de la R&D utilisent donc : Logger LOGGER = Logger.getLogger(Launcher.class); try { final Multimap<String, Requirement> requirements = retrieverequirements(new File(args[0])); final FileOutputStream fos = new FileOutputStream(new File(args[1])); catch (IOException e) { LOGGER.error("error during convertion", e); au lieu de : try { final Multimap<String, Requirement> requirements = retrieverequirements(new File(args[0])); final FileOutputStream fos = new FileOutputStream(new File(args[1])); catch (IOException e) { System.err.println("error during convertion"); En JAVA, il est recommandé de tester l'égalité sur deux objets en utilisant la méthode equals() plutôt que l'opérateur ==. Il est parfois nécessaire d'utiliser l'opérateur comme lors de la comparaison de références d'objets mais dans de nombreux cas, la méthode est plus adaptée. L'imbrication de blocs peut également parfois être simplifiée, par exemple, faire un if suivi d'un autre if peut être simplifié par un seul if à deux conditions. Dans la même idée, l'instruction switch ne devrait pas être utilisée s'il y a moins de 3 cas à tester. Ce genre de correction rend le code plus clair et concis. Certaines classes ne comportent que des méthodes statiques, ce genre de classe est utilisée comme une classe utilitaire et n'a donc pour autre vocation de simplifier le code qui les utilise en remplaçant une séquence d'instruction par une méthode. Dans ce genre de cas, il faut penser à intégrer un constructeur par défaut privé afin d'interdire l'instanciation d'une telle classe. 39

40 Sécurité : L'utilisation de méthodes statiques et de singletons nécessite une attention particulière du point de vue de la concurrence. Le code ci-dessous donne un exemple de ce qu'il faut éviter : private static Element root = null; public static Diagram parse(final Element targetroot, final Diagram diagram) { if (root == null) { return diagram; else { indiagram = diagram; root = targetroot; gettargetinterfaces(); getlinkedtasks(); return mapinterfaces(); Dans le cas d'un contexte «multi-threads», deux exécutions simultanées peuvent aboutir à un résultat faux. Dans ce genre de cas, les données critiques de la méthode sont encadrées avec le dispositif synchronized de JAVA comme ceci : private static Element root = null; private static final Object mutex = new Object() ; public static Diagram parse(final Element targetroot, final Diagram diagram) { synchronized(mutex) { if (root == null) { return diagram; else { indiagram = diagram; root = targetroot; gettargetinterfaces(); getlinkedtasks(); return mapinterfaces(); La visibilité des classes, méthodes et attributs est aussi parfois améliorable. Certaines classes n'ont pas besoin d'une visibilité trop importante si elle n'est pas utilisée. Lorsque la classe, la méthode ou l'attribut n'est pas fourni en tant qu'api, il convient de vérifier que son accès n entraîne pas de faille de sécurité. La manipulation des données est également un point sensible qui peut générer des alertes. En effet lors de l'accès ou la transmission d'une donnée, il est souvent important de se demander si cet objet peut être modifié ailleurs que dans son emplacement de création. Ainsi le contrôle sur les données est souvent limité en transférant des copies plutôt que l'objet lui même. C'est donc ce genre de code qui sera utilisé : private List<String> fixtures; public List<String> getfixtures() { return newarraylist(fixtures); 40

41 plutôt que celui-ci : private List<String> fixtures; public List<String> getfixtures() { return fixtures; Finalement, ces corrections ont été utiles pour la maintenabilité du code et ont fait baisser le nombre de «warning» sur le projet (Figure 14). Figure 14 : Courbe PMD représentant le nombre de «warnings» en fonction de l'avancement de la version «Refactoring» La correction de «warnings» est un travail que j'ai effectué pendant les périodes où les fiches étaient ou prises ou terminées, et dans ces mêmes périodes, une autre tâche pouvait être effectuée pour nettoyer le code, le simplifier ou le modifier de sorte à intégrer des améliorations telles que l'utilisation d'une nouvelle bibliothèque par exemple : le «refactoring». 41

42 Comme évoqué, cela permet de revoir le code pour le rendre plus propre, la majorité des «refactorings» se fait à la fin du développement d'une fiche mais parfois le développement met en évidence une possible amélioration d'une portion de code pas forcément liée à la fonctionnalité développée. C'est de cette seconde pratique que je veux parler ici ; généralement sous l'impulsion et les conseils d'olivier ALBIEZ, j'ai eu l'occasion de faire une refonte d'une partie du code. Je ne peux bien sûr pas lister l'ensemble des refontes mais par exemple, certains tests j'ai pu mettre en place bénéficient d'un système dont Olivier m'avait démontré la clarté, permettant d'améliorer la lisibilité du test : A l'origine, le test ci-dessous utilisait un «mock» (objet simulant le comportement d'un autre) afin de simuler l'avancement du temps, mais comme l'illustre le code ci-dessous, ce «mock» n'est pas spécialement intuitif à lire et surtout ne permet d'avancer que de 5, puis 10, puis 5, etc minutes et est donc spécifique au public void withsimpletimeconsumption() { final Supplier<Stopwatch> stopwatchsupplier = new Supplier<Stopwatch>() { public Stopwatch get() { final Stopwatch stopwatch = Mockito.mock(Stopwatch.class); Mockito.when(stopwatch.getElapsedDuration()).thenReturn( Durations.newDuration(5, DurationUnit.MINUTES), Durations.newDuration(10, DurationUnit.MINUTES) ); return stopwatch; ; final OrionLicenseManager newlicensemanager = createorionlicensemanager(stopwatchsupplier); assertthat(newlicensemanager.getrightfor(null), valid()); assertthat(newlicensemanager.getdetail(), LicenseHelper.details("default-nuser")); final long quotabalanceinitial = getquotabalanceinminutes(newlicensemanager.getdetail()); newlicensemanager.consume(); assertthat(getconsumedquota(newlicensemanager, quotabalanceinitial), equalto(60)); newlicensemanager.close(); assertthat(getconsumedquota(newlicensemanager, quotabalanceinitial), equalto(60)); J'ai donc remplacé ce système par une méthode permettant de gérer l'avancement du temps ; ce même test devient alors public void simpletimeconsumption() { withfloatinglicensemanager(**confidential**).checks( hasrightfor(**prédicat de droit**)), serverpudecreased(), localpu(equalto(60l))).ticafter(10, MINUTES).checks(serverPuUnchanged(), localpu(equalto(50l))).closes().checks(localpu(equalto(50l))); La gestion du temps s'en trouve plus précise, la pratique réutilisable dans d'autres tests et le code plus concis et clair. Bien sûr il n apparaît ici que le résultat c'est à dire le test transformé mais il y a de nombreuses autres refontes sous-jacentes. 42

43 Autre exemple, sur la gestion de licence dans Eclipse j'ai utilisé le «pattern decorator» qui permet de rendre testable une fonctionnalité en supprimant les éléments qui ne le sont pas : public final class LicenseManagerImpl implements ConfigurableLicenseManager { public LicenseManagerImpl( final File workspace, final Display display, final String licensekey, final String serverurl, final String product) { this.workspace = workspace; licensemanager = createmanager(licensekey, serverurl, product, workspace); display.addfilter( SWT.FocusIn, new Listener() { public void handleevent(final Event event) { licensemanager.resume(); ); display.addfilter( SWT.FocusOut, new Listener() { public void handleevent(final Event event) { licensemanager.suspend(); ); Ici la classe a besoin de Display qui est un objet SWT de gestion d'affichage pour ajouter un listener. Or cet objet est trop difficilement intégrable dans un test pour le peu d'intérêt qu'il a à l'être. J'ai donc utiliser un décorateur comme ceci : public final class LicenseManagerImpl implements ConfigurableLicenseManager { public LicenseManagerImpl( final File workspace, final String licensekey, final String serverurl, final String product) { this.workspace = workspace; licensemanager = createmanager(licensekey, serverurl, product, workspace); public ConfigurableLicenseManager withfocusmanager(final Display display) { display.addfilter( SWT.FocusIn, new Listener() { public void handleevent(final Event event) { licensemanager.resume(); ); display.addfilter( SWT.FocusOut, new Listener() { public void handleevent(final Event event) { licensemanager.suspend(); ); return this; La classe peut ainsi être créée sans Display et peut ainsi être testée ; hors des tests, il suffit d'utiliser la méthode withfocusmanager() pour obtenir les mêmes fonctionnalités. 43

44 Voilà quelques exemples de refontes que j'ai pu effectuer, mais il y en a eu plusieurs autres d'un volume variable comme l'utilisation de tag JUnit (@Before pour les tests plutôt que des méthodes en début de test ou encore l'utilisation du «pattern visitor» pour le traitement d'un objet JAVA plutôt que des tests sur le type de celui-ci Correction de «bugs» Outre la correction des «warnings» et le «refactoring», qui sont des tâches que les développeurs effectuent dans les périodes «creuses», une tâche très importante est la correction des «bugs» à laquelle j'ai pris part. Avant de développer la procédure en cas de «bug», il convient de définir ce qui est appelé de la sorte. Pour la R&D, un «bug» est une anomalie décelée après la phase de validation d'une fonctionnalité et donc quand celle-ci est considérée comme terminée. Une fonctionnalité terminée est dans un premier temps utilisable par les consultants et les clients XP puis suite à la sortie officielle de la fonctionnalité, par les utilisateurs finaux. Bien que les «bugs» soient plutôt rares grâce au système d'intégration continue et de tests mis en place, certains sont parfois décelés principalement par les consultants ou les clients XP et dans de rares cas, par les utilisateurs finaux de la solution Smartesting. Une fois le «bug» identifié, le client XP émet une fiche rouge qui doit être traitée en priorité par la R&D. Le traitement se passe en plusieurs étapes : dans un premier temps, les développeurs en charge de la correction tentent de le reproduire, dans le cas où personne de la R&D n'arrive à le reproduire, il est considéré comme causé par un élément extérieur sans rapport avec les outils de Smartesting. Une fois l'anomalie reproduite, la fiche suit le cours normal c'est à dire correction et validation. Pour ma part, j'ai fait quelques corrections de «bugs» dont certaines sans avoir besoin de binôme ; la première fut la correction d'un problème des «plugins» sous Eclipse : lors de la simulation (Figure 15 : bouton 1) d'un scénario d'utilisation (Figure 15 : sélection 3), le simulateur ne sélectionnait pas la suite qui contenait le scénario (Figure 15 : la sélection 2 doit être la même que la sélection 4). Au cours de la correction, j'ai pu me rendre compte que cela n'arrivait que lorsque deux scénarios portaient le même nom, la sélection étant faite sur ce critère, cela pouvait mener à la sélection d'une suite portant le même nom. J'ai corrigé ce problème en changeant le critère de sélection reposant non plus sur le nom mais sur l'identifiant qui lui est unique. 44

45 Figure 15 : Vues du «Scenario Manager» et du Simulateur dans RSM. La correction de ce «bug» a mis en évidence un autre problème graphique qui entraînait, lors de la fermeture et de la réouverture du simulateur, la sélection anormale de la suite. Ce problème est gênant dans le cas où de nombreuses suites sont ouvertes et que l'on souhaite retrouver la dernière suite sélectionnée. Ce problème était plus compliqué qu'il n'y paraissait : la sélection était faite une première fois correctement (la dernière suite sélectionnée le restait) mais un «event» Eclipse arrivait de façon décalée et, après sa récupération et traitement dans un listener, entraînait la dé-sélection de la suite. Cet événement décalé était dû au fait que lors de sa première émission, il ne pouvait pas être géré car un autre traitement était en cours ; le système d'eclipse, et donc SWT, le déplace alors automatiquement dans une file pour être traité lorsque cela sera possible. Pour régler ce problème, j'ai du revoir la gestion des événements afin que l événement décalé arrive en temps réel. Le dernier «bug» marquant sur lequel j'ai travaillé est un problème important qui a occupé beaucoup de développeurs de par sa complexité. En effet ce problème entraînait un «crash» de l'application CertifyIt (Figure 16) sous certaines conditions que je ne peux pas détailler pour des raisons de confidentialité. Pour résumer, le moteur de preuve de CertifyIt rendait un résultat de façon décalée par rapport à ce qui était attendu et donc cela entraînait au mieux une réponse erronée et au pire un «crash». La complexité de la correction de ce bug résidait dans le fait que celui-ci survenait dans un contexte «multi-threads» ce qui rend le «debug» difficile. Au final, les membres de la R&D dont moi-même avons réussi à corriger ce «bug» en resynchronisant la 45

46 réponse du moteur avec l'application CertifyIt. Figure 16 : Génération de tests sous CertifyIt avant le «crash». Pour être complet sur la correction de «bugs», je dois ajouter qu'il y eut quelques autres corrections d'ordre linguistiques : traductions erronées, ou fautes d'orthographe ainsi que quelques ajustements graphiques mineurs : rectification du positionnement d'éléments. Bien que la maintenance ne soit pas la partie la plus stimulante dans le processus de développement, elle est cependant nécessaire est participe à la qualité finale du produit ; il est parfois nécessaire de faire appel à sa créativité pour résoudre un problème et au final le fait de corriger, d'alléger et clarifier le code est très gratifiant. 46