Développement de plug-ins Eclipse en contexte agile

Transcription

1 MASTER 2 INFORMATIQUE UNIVERSITE DE FRANCHE-COMTE RAPPORT DE STAGE Développement de plug-ins Eclipse en contexte agile BENOIT BERNARDIN Responsable enseignant : Fabien Peureux Responsable entreprise : Christophe Grandpierre Membre du jury : Fabrice Bouquet 2012 / 2013

2 Remerciements Pour commencer, je tiens à remercier Laurent Py et Stéphane Werba pour m avoir accueilli au sein de leur société et de m avoir fait participer à des réunions stratégiques sur l entreprise. Merci à Bruno Legeard et Fabien Peureux pour leur suivi et leurs conseils tout au long du stage. Je remercie aussi l ensemble de l équipe R&D de Smartesting pour leur accueil, leur soutien et leur bonne humeur de travail. Merci à notre manager Séverine Darlot, pour la confiance accordée durant ces six mois de stage et pour l écoute dont elle a fait preuve afin que je réalise un stage dans les meilleures conditions qu il soit. Des remerciements particuliers et sincères à : Christophe Grandpierre, tuteur durant toute cette période, et où, à ses cotés, j ai pu acquérir de nombreuses et précieuses connaissances dans le domaine du développement logiciel. Merci pour l aide et les connaissances que tu m as apprises, pour la confiance que tu m as apportée ainsi que pour la disponibilité dont tu as fais preuve. Arnaud Bouzy et Dooley Nsewolo Lukula, respectivement product-manager et consultant, qui étaient à mes cotés et avec qui j ai pu collaborer et échanger de nombreuses idées sur les fonctionnalités développées. Merci pour vos précieux conseils et pour votre confiance. Julien Botella et Romain Sibre, consultants travaillant aussi dans notre environnement de travail et avec qui j ai échangé : aussi bien avec Julien qui m a permis de comprendre le fonctionnement de la solution Smartesting CertifyIt, que Romain avec qui j ai binômé. Merci à vous pour votre bonne humeur qui a fait de ce stage, un réel plaisir d apprendre au quotidien. 2

3 Table des matières Introduction... 5 I. Contexte et objectifs du stage... 7 A. La société Smartesting... 7 B. La solution Smartesting CertifyIt... 8 C. L équipe R&D D. Missions et objectifs du stage II. Méthodes agiles et outils de travail A. L agilité B. Les pratiques Smartesting III. Développements réalisés A. Regroupement d éditeurs B. Smartesting Viewer Bilans et conclusion A. Difficultés rencontrées B. Bilan technique C. Bilan humain D. Conclusion générale Bibliographie Sitographie

4 Table des illustrations Figure 1 : Vision multidimensionnelle de l'activité de test... 7 Figure 2 : La solution Smartesting CertifyIt... 9 Figure 3 : Logo UML Figure 4 : Organisation de l'équipe CertifyIt Figure 5 : Cycle en «V» Figure 6 : Outil de gestion de backlog Kanbanpad Figure 7 : Logos Jenkins - Subversion Figure 8 : Processus de développement d'une tâche Figure 9 : Exemple de collection immutable Figure 10 : Exemple d'utilisation des Google Collections Figure 11 : Phases de développement Figure 12 : Anciens éditeurs OCL Figure 13 : Aperçu des idées de conception graphique des nouveaux éditeurs Figure 14 : Nouvel éditeur OCL développé Figure 15 : Release de la solution Smartesting CertifyIt Figure 16 : Architecture de l outil Smartesting Viewer Figure 17 : Construction du noyau «Viewer» Figure 18 : Résultat de l'exécution du noyau Eclipse Figure 19 : Architecture Eclipse - Représentation du workbench Figure 20 : Aperçu du «shell Viewer»

5 Introduction Dans le cadre du Master 2 Informatique à l Université de Franche-Comté, un stage doit être réalisé afin d appliquer l ensemble des connaissances acquises tout au long de notre cursus. Ce stage, d une période minimale de quatre mois, est l occasion pour chaque étudiant de confronter ses aptitudes au monde professionnel et de lui permettre d assimiler de nouvelles notions afin d obtenir une base solide pour son entrée dans le monde du travail. Pour cette dernière ligne droite, je souhaite réaliser un stage différent des trois derniers réalisés au cours de ma formation initiale. En effet, jusqu à présent, mes stages se présentaient sous la forme d un objectif précis, à atteindre en plusieurs mois de travail et à concevoir de «A à Z». Par conséquent, je passais, plus ou moins rapidement, par toutes les étapes logiques du développement d applications : étude du sujet, analyse et conception, développement, validation jusqu à la mise en production. Cette année, je désire faire de ce stage une réelle expérience professionnelle à la fois représentative du parcours effectué, en mettant en pratique les connaissances étudiées à l Université, et en même temps novatrice. Parmi les différentes phases de développement citées précédemment, la validation logicielle notamment par le développement de tests, ne m était pas familière. Effectivement, ce vaste domaine a été abordé, pour la première fois, au cours du Master et sa seule mise en œuvre a été faite durant un projet universitaire. Développer une application est plutôt aisé mais construire une application testée dans laquelle nous avons confiance est une chose beaucoup plus difficile. Cela est l une des raisons de mon choix pour ce stage que j ai effectué au sein de la société Smartesting, éditrice de solutions informatiques de tests. A cela s ajoutent aussi de nombreux autres critères. On peut notamment citer le développement JAVA sur lequel j ai envie d évoluer et de poursuivre mon implication. Ainsi que le développement en contexte agile qui est l une des nouveautés, introduites durant cette seconde année de Master, que j ai tout de suite trouvé motivante. Enfin, un de mes derniers critères était l idée de ne pas avoir un sujet précis, de ne pas avoir une application à réaliser de bout-en-bout mais plutôt d être intégré directement dans une équipe qui travaille à maintenir et faire évoluer une solution existante. Par conséquent, mon objectif personnel est d apprendre un maximum : autant sur le plan technique avec l acquisition et le perfectionnement de concepts et de bonnes pratiques que sur le plan humain en travaillant en équipe et en partageant les différentes idées de chacun. Bien entendu, nous reviendrons sur toutes ces spécificités tout au long de ce document. 5

6 Nous allons, dans un premier temps, présenter l entreprise Smartesting et décrire le contexte dans lequel le stage va se dérouler, à savoir l équipe R&D chargée de maintenir et développer la solution Smartesting CertifyIt. Toujours dans la même partie, nous décrirons les différents objectifs et la mission du stage. Dans un second temps, nous poursuivrons sur une brève description des méthodes agiles et nous nous attarderons davantage sur leur application au sein de la société. Dans une troisième partie, nous nous pencherons sur le travail réalisé à savoir les diverses améliorations apportées à la solution Smartesting CertifyIt. Nous en profiterons pour détailler, en particulier, deux fonctionnalités. Enfin, nous terminerons par un bilan autant technique qu humain afin de récapituler les développements réalisés et de conclure sur l ensemble des compétences acquises. 6

7 I. Contexte et objectifs du stage L Informatique a, aujourd hui, pris une place prépondérante dans notre vie de tous les jours en automatisant des tâches quotidiennes, bien souvent répétitives, mais en participant aussi à notre sécurité grâce, par exemple, aux nombreux systèmes d aide à la conduite. Dans ce processus d automatisation, les logiciels jouent un rôle indispensable. Si le dysfonctionnement d un appareil photo peut être désagréable, l arrêt de l ABS («antiblockiersystem» ou système antiblocage des roues) ou même du contrôle dynamique de trajectoire d un véhicule peut avoir des conséquences dramatiques. Le développement de logiciels se trouve face à de nouveaux enjeux où il ne suffit pas tant d innover que d assurer la qualité des logiciels produits. En effet, la fiabilité des résultats obtenus résulte de la fiabilité même du logiciel utilisé. C'est là tout l'intérêt du test logiciel et c est précisément là où se positionne la société Smartesting en proposant une solution d automatisation de la conception de tests sur laquelle nous reviendrons dans la partie I.B : La solution Smartesting CertifyIt. A. La société Smartesting Créée, en 2003, par Bruno LEGEARD et Laurent PY, Smartesting est une entreprise française d'édition de logiciels. Implantée à Besançon et à Paris, elle tend aujourd'hui à se développer à l international grâce à des agences situées à Bangalore en Inde et à Boston aux États-Unis. L'entreprise est, aujourd'hui, dirigée par Laurent PY - Président Directeur Général et Stéphane WERBA - Directeur opérationnel. L activité de test est multidimensionnelle comme le montre ci-après la Figure 1 : Vision multidimensionnelle de l'activité de test, proposée par Jan Tretmans (Université Nijmegen, Pays- Bas). Smartesting propose une solution de génération de tests fonctionnels. Figure 1 : Vision multidimensionnelle de l'activité de test 7

8 Les tests, dits fonctionnels, peuvent intervenir à tout moment dans le cycle de vie d un logiciel. Leur rôle est de simuler des actions dans un contexte réel d utilisation afin d identifier d éventuels problèmes : aussi bien des erreurs que des problèmes freinant l utilisateur. Ils visent à démontrer qu un logiciel effectue ce pourquoi il est fait, en recherchant d éventuelles défaillances, en le sollicitant avec des valeurs d entrée et en examinant le résultat donné. Le test fonctionnel vérifie que l objectif du code est atteint sans en connaitre ses détails. Néanmoins, ce type de test présente certains inconvénients s il doit être réalisé manuellement : mobilisation de ressources, temps de réalisation important, vue subjective du testeur et non réutilisable la plupart du temps. La solution CertifyIt de Smartesting propose de remédier à ces défaillances en permettant de produire et de maîtriser des tests fonctionnels à partir d exigences métier. Smartesting compte plus d une trentaine de salariés dont une dizaine compose l équipe R&D (Recherche et Développement), basée au siège social à Besançon. Le reste est constitué de consultants et de commerciaux présents notamment sur Paris et sur les agences internationales. Tous, travaillent à faire évoluer et à promouvoir la solution Smartesting CertifyIt. Après avoir couvert de nombreux secteurs durant quelques années, la société se positionne aujourd hui sur le secteur IT («Information Technology» ou technologies de l information) où elle recense majoritairement des grands comptes parmi ses clients : Accenture, BNP Paribas, CAP Gemini, DGA (Direction Générale de l Armement), Dassault Systems, Gemalto, Steria B. La solution Smartesting CertifyIt Smartesting CertifyIt est un logiciel permettant la génération de cas de tests fonctionnels à partir d une modélisation UML 1 des exigences. Cette activité, aussi appelée MBT pour «Model-Based Testing», présente de nombreux avantages : modélisation abstraite et partielle des comportements attendus d un logiciel ce qui ne nécessite pas forcément d être développeur, maintenance facilitée des tests puisque la génération est automatisée et que, par conséquent, seul le modèle doit être modifié pour mettre à jour les suites de tests, réduction des risques d erreurs liés à l implémentation même du test avec un gain sur les coûts de processus et bien d autres que nous listerons pas ici. 1 UML pour «Unified Modeling Language» ou langage de modélisation unifié est un langage de modélisation graphique à base de diagrammes couramment utilisé en génie logiciel dans le cadre de la conception orientée objet. 8

9 La solution se compose d un logiciel permettant la génération automatique et d un «plug-in 2» intégré à un environnement de modélisation UML avec des contraintes écrites en OCL 3. L ensemble produit des cas de tests et ce, en plusieurs étapes détaillées en Figure 2 : La solution Smartesting CertifyIt. Spécifications et exigences 1 Conception du modèle IBM - Rational Software Architect 2 PLUG-IN SMARTESTING Fichier «.smtmodel» Exportation du fichier 3 Export Check Génération 4 SMARTESTING CERTIFYIT Publication 5 Figure 2 : La solution Smartesting CertifyIt 2 Plug-in (plugiciel en français) est un module d extension qui complète un logiciel pour lui apporter de nouvelles fonctionnalités. 3 OCL pour «Object Constraint Language» est un langage formel d expression de contraintes utilisé par UML. 9

10 Au départ, un modèle comportemental est réalisé à partir des spécifications clientes. Ce dernier se compose de trois diagrammes issus de la notation UML : 1 - Le diagramme de classes qui contient l ensemble des concepts et variables d états du système sous test, appelé SUT («System Under Test»), - Le diagramme d états/transitions qui contient les comportements du système et qui décrit les évolutions des variables d états (définies dans le diagramme précédent), Figure 3 : Logo UML (Unified Modeling Language) - Et le diagramme d objets qui est utilisé pour définir l état initial et les données de test. Ces diagrammes sont réalisés grâce à l environnement de modélisation Rational Software Architect d IBM. 2 Ce logiciel est basé sur la plateforme Eclipse, ce qui permet justement à Smartesting d y intégrer son «plug-in» permettant, dans une seconde partie, la vérification et l exportation du modèle créé. 3 Le résultat de cette dernière opération est un fichier spécifique (de type «smtmodel»). C est ce fichier qui constitue le point d entrée du logiciel Smartesting CertifyIt. Il suffit alors de le charger et de lancer la génération des tests. 4 Si la procédure se passe sans défaut c est-à-dire que l ensemble des tests passent, la troisième et dernière étape vise à publier les tests 5 sous différentes formes (HTML, JUnit) et pour différents environnements de gestion de tests : TestLink (projet open-source), Quality Center d HP ou Rational Quality Manager d IBM. A noter, tout de même, que ces deux dernières solutions couvrent 95% du marché à elles seules et permettent de manager, gérer et «versionner» les tests. C. L équipe R&D Depuis peu, l équipe R&D, composée d une dizaine de personnes, est scindée en deux équipes : la première est dédiée au maintien et à l évolution des solutions commercialisées (Smartesting CertifyIt ) tandis que la seconde équipe se charge de la définition et du développement de solutions nouvelles. C est dans la première équipe que le stage s est déroulé : c est pourquoi nous nous y attacherons dans la suite du document. L équipe «CertifyIt» est composée de trois personnes dont un développeur à temps plein, Monsieur Christophe Grandpierre (responsable de stage) et de deux personnes, Monsieur Dooley Nsewolo Lukula, développeur/consultant et Monsieur Arnaud Bouzy travaillant pour moitié en tant que développeur/product-manager. 10

11 Le schéma suivant (Figure 4 : Organisation de l'équipe CertifyIt ) détaille l organisation et les interactions de l équipe. EQUIPE R&D Réalisation des tâches Collaboration pour définir si une évolution est réalisable et estimer son estimation en temps afin de mettre à jour la feuille de route Feuille de route roadmap backlog Suivi et échange sur l avancement général DIRECTION PRODUCT-MANAGER Echange sur de nouvelles fonctionnalités Echange sur de nouvelles fonctionnalités CONSULTANTS CLIENT FINAL - UTILISATEUR Liens internes à l entreprise Liens externes (avec les clients) Relations permanentes Communications ponctuelles Equipe dans laquelle ce stage s est déroulé Figure 4 : Organisation de l'équipe CertifyIt Dans cette organisation, chacun joue son rôle. L équipe R&D participe à l estimation des coûts de développement, rend compte du point de vue technique et assure le développement du produit. Le product-manager, ou client XP, centralise l ensemble des fonctionnalités à développer ce qui lui permet de déterminer les fonctionnalités du logiciel, de gérer les priorités, de valider les développements réalisés d un point de vue fonctionnel et enfin de gérer le projet dans sa globalité. La partie «consulting» a pour rôle de mettre en œuvre la solution chez l utilisateur final. Directement lié à ce dernier, les consultants peuvent ainsi remonter certaines améliorations possibles (bugs, nouvelles fonctionnalités ) afin d adapter la solution. Ainsi, ils jouent les intermédiaires entre R&D/product-manager et le client. Le product-manager, régulièrement au contact de l utilisateur final, centralise et filtre les retours-clients pour les prioriser, en collaboration avec les développeurs, afin de constituer une roadmap 4», appelée ici feuille de route. Celle-ci se présente sous la forme d un tableau de tâches («backlog») qu on détaillera plus tard dans ce document. 4 Roadmap est un mot anglais signifiant littéralement calendrier de lancement. En génie logiciel, on parle de feuille de route pour désigner la direction de développement à suivre. 11

12 Les développeurs se chargent, ensuite, de développer les tâches définies dans la feuille de route en respectant une qualité satisfaisante qui est définie au départ et qui est obtenue, en autres, grâce aux méthodes de travail mises en place (voir la partie II : Méthodes agiles et outils de travail). Bien entendu, ce schéma indique le fonctionnement général en soulignant les relations entre chaque acteur car il faut garder à l esprit que la communication au sein de l entreprise est un facteur majeur de réussite et cela grâce aux méthodes de gestion pratiquées. D. Missions et objectifs du stage Intégré au sein de l équipe «CertifyIt», mon rôle sera de maîtriser la solution Smartesting CertifyIt pour ensuite développer des améliorations sur celle-ci et notamment sur le «plug-in» Eclipse qu elle intègre. A noter que ce dernier regroupe lui-même plusieurs «plugins», c est pourquoi ma mission est le : DEVELOPPEMENT DE PLUG-INS ECLIPSE EN CONTEXTE AGILE Par conséquent, nous allons reprendre les termes de cet objectif pour définir la suite de ce document. Nous commencerons par définir le contexte agile dans lequel j ai évolué durant ces mois de stage puis nous poursuivrons par l étude des développements réalisés et, en particulier, deux fonctionnalités : le regroupement d éditeurs et l outil Smartesting Viewer. 12

13 II. Méthodes agiles et outils de travail Les méthodes agiles sont des méthodes de développement utilisées notamment pour les projets en Informatique. Apparues au début des années 2000, elles sont aujourd hui de plus en plus utilisées dans le monde logiciel de par leur pragmatisme face aux méthodes traditionnelles comme le célèbre «cycle en V» dont le schéma est présenté Figure 5 : Cycle en «V». Le modèle du «cycle en V» est une gestion de projets particulière permettant de limiter un retour aux étapes précédentes. Elle tire son nom du fait de descendre d une réalisation générale à une réalisation détaillée puis de remonter en testant à différents niveaux. Néanmoins, ce modèle présente certains inconvénients : attentes, retards, problèmes de transmission d informations, processus inutiles, multitâches, travail partiellement fait, présence de défauts L apparition des méthodes dites «agiles» permet de résoudre ces inconvénients. Figure 5 : Cycle en «V» A. L agilité L agilité est une notion qui regroupe un certain nombre de pratiques avec la promesse d'une qualité de production et une réactivité élevée face aux nouvelles demandes. Plusieurs méthodes existent aujourd hui comme «extreme programming» (appelée XP) ou bien «Scrum» et reposent sur une structure (cycle de développement) commune (itérative, incrémentale ou adaptative) et quatre valeurs communes déclinées en douze principes fondamentaux. Nous ne listerons pas ici ces douze principes mais nous nous attacherons aux quatre valeurs représentatives afin de montrer l objectif visé de l agilité. Les quatre valeurs communes (extraites du Manifeste agile 5 ) : - L équipe : «Les individus et leurs interactions, plus que les processus et les outils» - L application : «Des logiciels opérationnels, plus qu'une documentation exhaustive» - La collaboration : «La collaboration avec les clients, plus que la négociation contractuelle» - L acceptation du changement : «L'adaptation au changement, plus que le suivi d'un plan» 5 Le Manifeste agile est un texte rédigé par des experts du développement d applications informatiques sous la forme de plusieurs méthodes dites agiles en détermine leurs points communs. Datant de 2001, il est aujourd hui défendu par l Agile Alliance. 13

14 L approche agile adoptée par Smartesting se base sur les principes de l'«extrem Programming». Effectivement, la méthode XP regroupe treize pratiques : règles de codage, restructuration du code, conception simple, tests unitaires, intégration continue, responsabilité collective du code, travail en binôme, langage commun, rythme régulier, client sur site, tests de recette, planification itérative et enfin livraisons fréquentes. Il faut noter que ces pratiques ne sont pas figées et elles évoluent selon le contexte dans lequel elles s appliquent. L équipe CertifyIt compte peu de membres (trois en l occurrence) : c est l une des raisons qui explique que l ensemble des pratiques prônées par la méthode XP n est pas appliqué et adapté, en général, à des équipes de dix à quinze personnes. On peut citer, par exemple, le travail en binôme qui est pratiqué aussi souvent que possible mais difficilement dû au nombre de développeurs pour constituer les binômes. B. Les pratiques Smartesting A présent, nous allons nous focaliser sur les diverses méthodes de travail de l équipe R&D en faisant le parallèle avec les différents pratiques prônées par l extreme Programming. 1. Planification itérative et déroulement des itérations Afin d être un maximum réactif et de pouvoir s adapter rapidement à la demande du client, les équipes fractionnent généralement le développement en courtes itérations de quelques semaines (une à deux le plus souvent), validées au fur-et-à-mesure de leur avancement. Durant cette courte période, le product-manager tient à jour un tableau de tâches, considéré comme la «roadmap» précédemment (Figure 4 : Organisation de l'équipe CertifyIt ). Charge, ensuite, à chaque développeur de choisir une tâche et de la développer. Dans le cas du développement de la solution Smartesting CertifyIt, nous sommes sur une phase de maintenance et d évolution du produit. Par conséquent, les itérations ne correspondent plus à un nombre déterminé de semaines mais s accordent par rapport aux «releases 6» du produit. Le tableau de tâches («backlog»), quant à lui, est géré grâce à l utilisation d une application Web appelée «Kanbanpad». Cette plateforme permet de gérer des projets, et notamment des tâches, et de les affecter à des développeurs en charge de leur réalisation. L illustration (Figure 6 : Outil de gestion de backlog Kanbanpad) en montre un aperçu. L équipe l utilise pour avoir, à tout moment, une vision globale de l avancement des fiches et donc des tâches de développement. 6 Release est un mot anglais signifiant sortie. En Informatique, on parle de versions d un logiciel. 14

15 Projet sélectionné Cycle de vie des tâches Catégories (feature, bug, technic, doc ) représentées par un système de couleurs et pouvant correspondre à une priorité. Equipe de développeurs Exemple de tâche Figure 6 : Outil de gestion de backlog Kanbanpad Les bugs détectés et les nouvelles fonctionnalités demandées par le client final sont considérés comme des améliorations à la solution. Chacune d entre elles fait l objet de la création d une fiche (une tâche) qui est étudiée par le product-manager et les développeurs afin de déterminer sa faisabilité et estimer son coût de développement. Cette opération est appelée le «planning game 7». Charge, ensuite, à chaque développeur de choisir une tâche du «backlog» et de mettre à jour son avancement : de sa planification («planning» sur la Figure 6 : Outil de gestion de backlog Kanbanpad) à son développement en passant par une phase de conception («design»), si nécessaire. Bien entendu, l ensemble de l équipe communique en permanence pour connaitre les choix de chacun et l environnement de travail en «open space 8» facilite cette procédure. On rappelle ici que l outil décrit ne sert qu à obtenir une vision instantanée du travail réalisé. En aucun cas, la communication de l équipe ne se substitue à cet outil. 7 Planning game (appelé aussi «planning poker») pour jeu du planning est une façon efficace de produire des estimations sur la complexité des fonctionnalités à produire. Cette pratique est surtout utilisée par les méthodes agiles et a été introduite pour la première fois en 2002 par James Grenning. 8 Open space : anglicisme qui désigne une façon d organiser un espace de travail à plusieurs. 15

16 Le développement d une tâche consiste à écrire les tests unitaires, dans un premier temps, puis de développer la fonctionnalité le plus simplement possible pour que les tests réussissent. On parle alors d approche TDD («Test Driven Development» ou développement piloté par les tests) permettant ainsi de développer une tâche sous couvert de tests. Une fois dans la colonne «Testing» de la Figure 6 : Outil de gestion de backlog Kanbanpad, une tâche est dite développée et testée unitairement. Elle doit encore passer une phase de validation avant d être mise en «release». L idée est qu une personne, autre que le développeur, valide cette tâche. Généralement, cette validation fonctionnelle se fait avec une technique de «boite noire» c est-à-dire sans connaitre l implémentation réelle de la tâche. Néanmoins, chacun peut juger bon de regarder le code suivant l importance de la modification et des modules touchés par cette dernière. Dès lors, une revue de code ou un «refactoring 9» est effectué afin de détecter d éventuelles erreurs de programmation ou de trouver des vulnérabilités potentielles. Si cette dernière étape de validation se révèle sans défaut, la tâche est mise en «release» et pourra donc être intégrée à la prochaine version de la solution. Dans le cas contraire, la tâche est repassée au stade de développement avec les commentaires justifiant ce retour et le développeur en est averti. La correction se fait alors par un binôme constitué du développeur et d un tiers (voir partie II.B.3 : Travail en binôme). J ai pu appliquer cette méthodologie tout au long de mon stage à chaque développement de tâches. Elle permet d avoir une réelle organisation avec la gestion des priorités et permet d obtenir une vision globale à chaque instant. On notera qu on utilise ici un outil (de gestion de tâches) plutôt que de privilégier la communication et les interactions entre tous avec l utilisation d un tableau de fiches papier. Ce choix a été fait car le product-manager, régulièrement en déplacement, peut ainsi visualiser le «backlog» à tout moment. 2. Intégration continue et phase de tests En parallèle, le développement se fait sur un mode d intégration continue. Cette notion, prônée par les méthodes agiles, est un ensemble de pratiques utilisées pour vérifier à chaque modification du code source que le résultat de ce changement ne produit pas de régression dans l application. La modification se doit d être une amélioration et non une altération du produit final. Cela permet d avoir, à tout moment, une solution fonctionnelle et potentiellement livrable. Figure 7 : Logos Jenkins - Subversion 9 Le refactoring est un terme anglais qui désigne le fait de retravailler le code source sans lui ajouter de fonctionnalité ni même de corriger des bugs mais en améliorant sa lisibilité pour simplifier sa maintenance. 16

17 Un serveur d intégration continue (Jenkins) est mis en place avec un dépôt unique du code source «versionné» grâce à l utilisation du logiciel de gestion de version Subversion (abrégé SVN). Ainsi, lorsqu une tâche est testée unitairement et développée, les modifications sont immédiatement intégrées dans le produit final. Quand tous les tests passent (unitaires et d intégration), l intégration est terminée. La tâche reste encore à être validée par un tiers. Néanmoins, cette procédure permet d éviter la surcharge de travail liée à l intégration de plusieurs éléments en même temps. Le schéma, présenté en Figure 8 : Processus de développement d'une tâche, détaille le processus complet d intégration continue en faisant le parallèle avec le cycle de vie d une fiche. Création et planification d une tâche Product-manager Choix d une tâche Développeur Analyse et conception KO Tests unitaires Serveur d intégration / dépôt Commit Développement KO OK Validation («testing») OK Tierce personne Mise en «release» * Commit : action utilisée par les logiciels de gestion de versions (ici SVN) pour désigner la validation d une transaction permettant de transférer son code source local sur le dépôt commun pour le rendre accessible à tous. Figure 8 : Processus de développement d'une tâche 17

18 Dans cette course à la qualité, les outils ne suffisent pas. Comme l évoque la première valeur des méthodes agiles : «Les individus et leurs interactions, plus que les processus et les outils». C est pourquoi, d autres pratiques, se basant sur l interaction des personnes, sont aussi mises en place avec pour objectif la qualité, la communication et la simplicité Nous rappelons ici que la qualité avec le slogan «zéro défaut» n existe pas mais l objectif est de produire et maintenir un logiciel dans lequel nous avons suffisamment confiance. En outre, certaines phases de qualité peuvent être omises car leur mise en œuvre peut s avérer trop coûteuse par rapport au bénéfice estimé. 3. Travail en binôme L idée est de travailler en binôme sur une tâche souhaitée. Ce procédé permet ainsi une meilleure qualité du travail accompli en privilégiant la communication entre les membres de l équipe qui interagissent avec leur propre vision des choses. Concrètement, le binôme travaille sur le même poste et partage les périphériques d entrée (clavier et souris) et chacun partage ainsi son point de vue. Durant le stage, cette pratique a été régulièrement utilisée avec mon tuteur notamment sur des problèmes où la solution n était pas toute trouvée. Ainsi, nous recherchions diverses solutions en confrontant nos idées afin de trouver la mieux adaptée au problème qui se posait. Cette pratique m a permis d acquérir des notions et des concepts beaucoup plus rapidement. Côté logiciel, elle permet une harmonisation du code source et une détection des erreurs plus tôt, à l écriture du code. En effet, lorsqu un développeur écrit, son binôme peut ainsi le corriger directement. Sur le plan humain, cette méthode de binôme permet une certaine interactivité entre les membres, l échange d idées et le partage de connaissances. 4. Conception simple, remaniement de code et règles de codage A noter que le «binômage» a été aussi appliqué avec Romain Sibre, stagiaire consultant chez Smartesting durant la même période. Nous avons eu l occasion de travailler ensemble sur le projet financé RASEN afin de réaliser une revue de code et du «refactoring». La première notion permet d examiner le code source afin de détecter d éventuelles erreurs de conception et d améliorer la qualité et la sécurité du logiciel. La seconde, quant à elle, consiste à retravailler le code source sans lui ajouter de fonctionnalité ni corriger de bugs mais juste en amélioration sa lisibilité. 18

19 Ce binôme était différent de celui réalisé avec mon tuteur dans le sens où je jouais davantage le rôle du correcteur. Ainsi, j ai pu corriger objectivement des erreurs qu il m arrive de faire aussi. Cette opération m a été très utile car j ai pris conscience de la difficulté à reprendre du code que nous n avons pas écrit nous-mêmes et dont la compréhension s avère parfois assez complexe. Je comprends, à présent, l utilité d un code clair et concis découpé en courtes méthodes avec chacune un rôle précis. Cela facilite aussi l écriture des tests unitaires. D ailleurs, nous avons pu compléter les tests unitaires écrits jusqu à ce que nous ayons réellement confiance dans le code. Là aussi, j ai pu comprendre la difficulté d écrire des tests lorsque le code, au départ, n est pas sûr. Ainsi, lorsque les tests ne passent pas, il est difficile de savoir si cela vient du code ou des tests eux-mêmes. L approche «tests-first» et ses variantes permettent de remédier à ce genre de problèmes. Un binôme qui a très bien fonctionné et qui nous a permis de partager des visions et des idées différentes à certains moments. Nous nous sommes rendu compte au final que le code était harmonisé, beaucoup plus simple à appréhender, et surtout qu il donnait davantage confiance. D autres méthodes de travail ont été utilisées et citées implicitement précédemment. Nous pouvons citer le travail en équipe ou l appropriation collective du code car l équipe est collectivement responsable de l application. Chaque développeur peut modifier des portions de code qu il n a pas forcément écrites. Les tests se chargeront de révéler ensuite d éventuelles erreurs. Une autre pratique qui permet une certaine qualité du code concerne les conventions puisque tous les développeurs interviennent sur le code source et il est indispensable de respecter certaines normes. Plusieurs exemples peuvent être cités : convention de nommage, utilisation du mot-clé «final» pour des questions d optimisation et afin d obtenir des objets immuables, tout comme l usage de listes non modifiables en retour de méthodes comme le montre la Figure 9 : Exemple de collection immutable. Le respect de ces normes est un ensemble de bonnes pratiques de développement Java [CR11]. Figure 9 : Exemple de collection immutable 19

20 Enfin une dernière pratique est liée directement à l une des valeurs des méthodes agiles : «Des logiciels opérationnels, plus qu'une documentation exhaustive». Ainsi, nous avons un code source sans aucun commentaire car l idée est que l usage de ces derniers est une conséquence d un code complexe et difficile à appréhender. Hors, l objectif est d obtenir un code clair et concis. Un exemple concret est l utilisation du «framework 10» Google Collections issu du projet Guava 11 et qui m était inconnue jusqu alors. Cette bibliothèque permet de manipuler assez simplement des collections Java et, par conséquent, améliore la lisibilité du code. Elle permet, en autres, de rechercher des éléments et de filtrer, de transformer ou de composer des collections. Au lieu d avoir des boucles dont les conditions et les incréments sont difficiles à visualiser de prime-abord, elle permet une certaine visibilité sur l objectif d une méthode ou d une partie précise du code. La Figure 10 : Exemple d'utilisation des Google Collections présente un exemple de code où l on cherche à r etourner, parmi une collection, tous les films de l année Deux méthodes sont écrites : la première est l écriture «naïve» du problème posé tandis que la seconde est la solution utilisant les Google Collections. S A N S Compréhensible mais plus difficile à appréhender A V E C Une ligne de code suffit Figure 10 : Exemple d'utilisation des Google Collections 10 Framework (littéralement cadre de travail) est un mot anglais qui désigne un kit de composants logiciels qui servent à créer les fondations et les grandes lignes de tout ou partie d un logiciel (son architecture). 11 Le projet Guava regroupe dans sa majorité les Google Collections qui est un «framework» s intéressant aux problématiques de bas-niveau et apportant un support fiable aux développeurs sur le sujet des collections Java. 20

21 La première méthode n est peut-être pas la plus efficace pour réaliser un filtre sur une collection mais c est la solution «naïve» que j aurais écris avant de connaitre le framework Google Collections. Nous constatons, dans la seconde méthode, que l utilisation de ce framework permet d avoir un code source simple, clair et concis tandis que dans la première, des informations supplémentaires faussent la compréhension comme les conditions. A noter aussi que la première méthode devra sûrement être testée afin de se rassurer sur le résultat retourné contrairement à la seconde puisqu on réutilise une méthode existante (filter) qui nous permet de ne pas gérer la structure complexe (la boucle et sa conditionnelle). Qualité, simplicité, interaction et communication sont donc des valeurs prônées par les méthodes agiles et appliquées au sein de l équipe chargée du maintien de la solution Smartesting CertifyIt. Maintenant que nous avons défini l environnement de travail dans sa globalité, nous rentrons dans le vif du sujet en étudiant le travail réalisé au cours de ces mois de stage. 21

22 III. Développements réalisés L axe majeur de mon travail tout au long de ce stage a été le développement JAVA lié à la solution Smartesting CertifyIt et plus particulièrement à la plateforme Eclipse/Eclipse RCP sur laquelle elle repose. Pour rappel, RCP est un outil permettant la conception d applications autonomes en développant des «plug-ins» adaptés à la plateforme Eclipse. Mon stage s est déroulé en plusieurs phases comme l illustre la Figure 11 : Phases de développement. La première s est faite durant les premières semaines et m a permis de découvrir l ensemble des outils et des méthodes utilisés. De plus, elle m a permis de me familiariser à la notion de «plug-ins» et de connaitre certains éléments de l architecture Eclipse comme la zone d éditeurs. La seconde, quant à elle, constitue une phase de développement d améliorations (bugs, fonctionnalités ) qui s est déroulée aussi sur plusieurs semaines. Ces deux premières phases m ont ainsi permis de participer à la sortie de la release de la solution Smartesting CertifyIt. Enfin la dernière phase constitue le début d un projet avec la création d un «shell viewer». Début de stage Présentation de stage Fin réelle de stage 6 semaines PHASE 1 Regroupement d éditeurs 1 mois 2 mois 6 semaines PHASE 2 Améliorations PHASE 3 diverses Projet «Smartesting Viewer» temps Figure 11 : Phases de développement A présent, nous allons nous concentrer sur deux fonctionnalités précises à savoir le regroupement d éditeurs (phase 1) et le projet Smartesting Viewer (phase 3). La phase 2 a permis de poursuivre l amélioration de la solution, débutée au début de stage, en continuant notamment à faciliter son utilisation et en résolvant des bugs. Nous pouvons citer, entre autres, quelques exemples comme la gestion du double-clic sur les arbres afin d ouvrir plus rapidement les éditeurs, la gestion d une complétion sur la documentation ou encore la création d une option de recherche globale sur l ensemble des projets ouverts. 22

23 A. Regroupement d éditeurs Le premier objectif à mon arrivée au sein de Smartesting était de prendre connaissance du code et de maîtriser la solution Smartesting CertifyIt en prenant des exemples et en appliquant de bout-en-bout le processus décrit précédemment (voir la Figure 2 : La solution Smartesting CertifyIt ). En parallèle, l objectif était de proposer des améliorations possibles sur la solution. Après quelques semaines d utilisation, j ai proposé une amélioration sur le regroupement d éditeurs. En effet, lors de la conception du modèle UML, une phase d édition des «pré» et «post» conditions est requise sur les opérations, les états et les transitions du diagramme d états/transitions afin de déterminer le comportement du système sous test. Cette édition est réalisable grâce au «plug-in» Smartesting via des entrées dans le menu. Le problème, illustré à la Erreur! Source du renvoi introuvable., est la répétition des actions pour arriver à éditer les différents comportements. En effet, si l on veut éditer les actions d une seule opération du modèle, il faut afficher le menu en cliquant sur l opération, sélectionner tout d abord «edit precondition» puis renouveler la manipulation deux fois en sélectionnant «edit postcondition» et «edit documentation». Le résultat étant l ouverture de trois éditeurs distincts. L amélioration proposée était une question d ergonomie et de facilité d utilisation. Ainsi, pourquoi ne pas avoir une seule entrée dans le menu qui ouvrirait une seule page regroupant plusieurs éditeurs? On remarque la présence de trois éditeurs indépendants avec en plus, pour la «postcondition», la présence d un éditeur de texte et d un tableur. Figure 12 : Anciens éditeurs OCL 23

24 Une fois l amélioration proposée, nous l avons soumis aux consultants et au productmanager pour connaitre leur opinion et éventuellement obtenir des idées de réalisation. Leur avis était indispensable pour savoir si la fonctionnalité pouvait répondre à un besoin. Après échange, nous avons convenu que la fonctionnalité devait être implémentée. Plusieurs idées ont été suggérées comme par exemple : - Une seule entrée dans le menu avec l ouverture simultanée de plusieurs éditeurs - Une seule entrée et une seule page avec une décomposition des éditeurs en sections - Une seule entrée et une seule page avec une décomposition des éditeurs en onglets Figure 13 : Aperçu des idées de conception graphique des nouveaux éditeurs Une analyse de l existant a été faite pour comprendre le fonctionnement de la plateforme Eclipse et notamment de ses éditeurs puisqu on le rappelle, nous travaillons ici sur le «plug-in» (Eclipse) de la solution Smartesting CertifyIt. Celle-ci a permis aussi d écarter certaines idées non réalisables, par rapport à l architecture Eclipse, ou tout simplement non satisfaisantes comme la décomposition d éditeurs sous forme de sections au sein même d une seule et même page car ne laissant que trop peu de places à l édition. En réalité, la fonctionnalité s est avérée plus difficile à développer qu elle n y paraissait. En effet, il ne suffisait pas de créer une nouvelle entrée dans le menu et d ouvrir une seule page. L architecture Eclipse est plus complexe à appréhender et chaque éditeur est associé à des modèles et des stockages spécifiques. Par conséquent, la combinaison de trois éditeurs en un seul nous a obligés à revoir la conception depuis le début. A la fin de l étude, le choix s est porté sur une entrée menu donnant accès à une page regroupant des éditeurs via des onglets comme le montre la Figure 14 : Nouvel éditeur OCL développé. 24

25 Ouverture d une seule page comportant tous les éditeurs regroupés en onglets Figure 14 : Nouvel éditeur OCL développé Le résultat en est une facilité d utilisation notamment pour un modèle comportant un nombre sensible d opérations. A noter aussi que l on prend pour exemple ici les opérations mais il faut avoir à l idée que les états et transitions du diagramme d états/transitions peuvent faire l objet d une édition OCL. A présent, un seul clic suffit dans le menu pour voir apparaitre toutes les informations. On ne s attardera pas ici à détailler l implémentation de la fonctionnalité mais celle-ci fût développée sur une période de quatre semaines pour arriver à un résultat validé par les consultants et le product-manager avec lesquelles j ai été en collaboration tout au long du développement. A présent, cette amélioration fait partie intégrante de la «release» de la solution CertifyIt de Smartesting. Son développement m a permis d appréhender le code existant en apprenant, en même temps, de nouveaux concepts et de nouvelles méthodes de programmation. Aussi, j ai pu commencer à développer avec Eclipse RCP en abordant les «plug-ins» par le biais de fichiers XML (pour les entrées menu) et en me familiarisant avec son architecture. Ayant repris la conception depuis le départ, j ai eu l occasion d améliorer mes compétences en JAVA et notamment sur le plan graphique avec l utilisation de SWT 12 et JFace SWT (Standard Widget Toolkit) est une bibliothèque graphique libre pour Java sur laquelle se repose, en autre, la plateforme Eclipse. Elle permet notamment l implémentation native spécifique à chaque système d exploitation. 13 JFace est une bibliothèque graphique qui se repose sur SWT pour fournir des composants de plus haut niveau. 25

26 Après cette réalisation et comme cité précédemment (voir la Figure 11 : Phases de développement), ma mission était de poursuivre l amélioration de la solution Smartesting CertifyIt en continuant à faciliter son utilisation et en résolvant des bugs. De nombreuses fonctionnalités qui m ont permis sans cesse d apprendre sur le langage JAVA et qui ont été intégré directement sur la «release» de la solution comme le montre la Figure 15 : Release de la solution Smartesting CertifyIt. Fonctionnalités développées Figure 15 : Release de la solution Smartesting CertifyIt 26

27 Au bout de quelques mois et après plusieurs remontées clients, une nouvelle fonctionnalité sur la solution Smartesting CertifyIt était envisagée. En effet, certains utilisateurs, notamment des chefs de projet et des experts métier utilisent la solution mais seulement à titre consultatif. Aujourd hui, cette utilisation particulière leur pose certains problèmes (achat de licence, difficultés d installation ) et la société doit, par conséquent, adapter sa solution aux diverses utilisations qui lui en sont faites. Afin de répondre à ce besoin, l idée est de créer une application basée sur la plateforme Eclipse et permettant exclusivement de consulter certains projets (de la même façon que Rational Software Architect d IBM). La seule différence résidera dans la facilité d utilisation et l impossibilité de modifier les projets puisque seule la consultation sera fonctionnelle : un mode «read-only» en quelque sorte. B. Smartesting Viewer Cette application, appelée «viewer» en référence à la visualisation, doit être vue comme une nouvelle fonctionnalité puisqu elle sera intégrée à la solution Smartesting CertifyIt. A titre de comparaison, nous pourrions prendre la suite Adobe pour la gestion des fichiers PDF. Il existe, aujourd hui, un logiciel payant d édition de fichiers PDF appelé Adobe CreatePDF et un logiciel gratuit de consultation Adobe Reader. Au final, la solution Smartesting CertifyIt comprendra aussi deux fonctionnalités : un outil d édition et un outil de visualisation (le «viewer»). Ce «viewer» se devra de résoudre les problèmes rencontrés actuellement par les chefs de projet et les experts métier. Tout d abord, une question d ordre financier en n obligeant pas l utilisateur final à acheter une licence globale relativement élevée aujourd hui pour de la consultation. Ensuite, des difficultés d installation et de prise en main pour des utilisateurs ne maîtrisant pas le modeleur RSA (Rational Software Architect ) d IBM. En effet, cet outil complet, sur lequel se base la solution Smartesting CertifyIt, possède de nombreuses configurations et sa prise en main est assez difficile. C est ce point précis qui nous intéressera par la suite tout comme le dernier problème : le filtrage des informations selon le profil utilisateur. Ainsi, on peut penser qu un chef de projet appréciera une vue de statistiques et d indicateurs d avancement tandis qu un expert métier se concentrera davantage sur la validation des aspects fonctionnels en consultant les tables ou les énumérés. L idée est donc de créer une application basée sur la plateforme Eclipse et relativement facile à utiliser. Pour cela, nous devons partir d un noyau épuré d Eclipse. Le «viewer» sera ainsi principalement constitué de «plug-ins» adaptés à ce noyau. 27

28 L objectif, dans un premier temps, est de réfléchir sur la construction de ce noyau pour disposer d un exécutable prêt à l emploi. L objectif suivant et qui restera mon objectif jusqu à la présentation de ce stage est l ajout de «plug-ins» à ce noyau Eclipse afin de constituer un «shell» minimal sur lequel le «viewer» final se reposera comme le montre la Figure 16 : Architecture de l outil Smartesting Viewer. Smartesting Viewer Menu Editeurs Autres SHELL VIEWER «Shell» minimal Explorateur de projets Noyau Eclipse Plug-in Smartesting «core» Plug-in Smartesting «publisher» Plug-in Smartesting «licence» / Plug-ins ou modules à développer Plug-ins existants Figure 16 : Architecture de l outil Smartesting Viewer Le «shell viewer» se repose sur le noyau Eclipse pour faciliter l intégration d autres «plug-ins» déjà existants. Après étude avec les consultants et le product-manager, ce «shell» doit comporter plusieurs composants dont un menu de base et un explorateur de projets pour les principaux. Il constituera une application minimale : notre propre noyau en quelque sorte. Néanmoins, avant de le développer, l objectif est de réfléchir sur sa construction afin de faciliter l intégration de nouveaux «plug-ins» au fur-et-à-mesure de son développement et d avoir un exécutable à tout moment. 28

29 Construction du «shell Viewer» Un «product» est un exécutable Eclipse résultant d une construction des sources. Sa création est relativement aisée par le biais du PDE (Plug-in Developement Environment) 14 Eclipse car gérée via une interface graphique. Il suffit d y indiquer les paramètres de construction et c est l IDE qui se charge de concevoir l exécutable. Néanmoins, cette opération n est pas détaillée et, même après plusieurs recherches, il est difficile de connaitre le mode opératoire. Au départ, nous sommes parti sur une construction automatique de l exécutable. Par conséquent, à chaque modification du code, un «build 15» aurait permis de construire automatiquement un «product». Cette idée a fait l objet d une étude afin de déterminer les solutions possibles. Deux possibilités se dégagent de cette analyse : - La construction avec ANT : historique, cette solution annexe est apparemment difficile à mettre en œuvre dû à des scripts complexes, tout comme son utilisation dans un outil d intégration comme Jenkins. - La construction avec Maven et Tycho : Maven est un outil comparable à ANT sauf qu il est plus facile de le prendre en main et de comprendre son fonctionnement. Seul, il ne peut être utilisé pour construire des exécutables Eclipse car tout deux présentent une incompatibilité (architecture OSGi sur laquelle se base Eclipse et que Maven ne reconnait pas). C est pourquoi Tycho est requis. Ce dernier est un «plug-in» Maven qui permet de construire des binaires de «plug-ins» Eclipse. La première construction a tout de suite été écartée car elle semblait beaucoup trop complexe et difficile à appréhender. Ce choix a été fait afin de ne pas perdre trop de temps à trouver la meilleure solution au problème de construction du «shell Viewer». La combinaison de Maven et Tycho a été retenue et utilisée pour savoir si elle était conforme à notre objectif. Nous arrivions bien au résultat escompté à savoir un exécutable Eclipse mais des difficultés ont été rencontrées lorsqu il a fallu intégrer ce processus dans l outil d intégration continue Jenkins. Avec consultation du product-manager, nous nous sommes alors tournés vers une troisième solution qui est la plus appropriée à notre cas : la construction manuelle d un «product» de noyau Eclipse (via l IDE Eclipse) et y intégrer automatiquement des «plug-ins» qui constitueront notre «shell». Ce choix a été fait après avoir analysé justement l intégration de «plug-ins» au sein d un exécutable Eclipse : celle-ci est relativement aisée. La Figure 17 : Construction du noyau «Viewer» présente le fonctionnement de cette solution de construction. 14 PDE («Plug-in Development Environment») pour environnement de développement de «plug-ins» est un assistant de création de «plug-in» qui permet, en autre, d éditer les fichiers de configuration. 15 Un build est, comme son nom le suggère, une construction d une version exécutable de tout ou partie d un logiciel. 29

30 «SHELL VIEWER» Noyau Eclipse Construction manuelle via l IDE Eclipse Résultat de la construction Plug-in Menu Plug-in Console Plug-in Editeurs Plug-in Explorateur Exécutable Figure 17 : Construction du noyau «Viewer» Par conséquent, nous avons construit une et une seule fois le noyau Eclipse pour avoir en résultat un répertoire avec notamment l exécutable et un sous-répertoire «plugins». A ce stade, si nous lançons l exécutable, une fenêtre s affiche avec seulement les contrôles de redimensionnement et de fermeture (Figure 18 : Résultat de l'exécution du noyau Eclipse). Afin de constituer notre «shell Viewer», il suffira donc d intégrer, manuellement ou automatiquement, des extensions dans le sous-répertoire «plugins» sous la forme de fichiers JAR 16. Figure 18 : Résultat de l'exécution du noyau Eclipse 16 JAR (Java Archive) est un format de fichier utilisé pour distribuer un ensemble de classes Java. Cette archive stocke les définitions des classes, des métadonnées et l ensemble d un programme. 30

31 Développement du «shell Viewer» Le développement de cette application minimale est principalement d ordre graphique. Comme cité précédemment, le «shell» se devra de proposer un menu avec des options basiques et relatives à de la consultation. On aura donc des entrées comme «open file», «export» et non «sauvegarder sous» qui résulte d une modification. De plus, un explorateur de projet permettra des actions sur les différents fichiers comme l ouverture dans une zone d éditeurs. Mais avant tout, intéressons-nous à l architecture Eclipse via un aperçu d écran. Menu Barre d outils (toolbar) La zone d éditeurs Une vue Ici, l explorateur de projets Là, d autres vues Une page composant une perspective La barre de statuts Figure 19 : Architecture Eclipse - Représentation du workbench 31

32 La Figure 19 : Architecture Eclipse - Représentation du workbench détaille l ensemble des composants de l architecture Eclipse. Dans notre cas, nous avons besoin du menu et d une page composée d une vue «explorateur de projets» et d une zone d éditeurs. C est ces éléments qui constitueront notre «shell». Le menu est construit via le PDE Eclipse. En réalité, c est un fichier XML qui est écrit au fur-età-mesure et qui regroupe toutes les informations nécessaires à la création d un menu (items, sous-items, raccourcis clavier ). Le «shell» propose un menu des plus basiques avec des items «file» (gestion de l application et des fichiers), «edit» (recherche ou sélection de termes), «window» (gestion de la zone d éditeurs), «project» (gestion des projets) et enfin «help» (aide, préférences). Celui-ci constitue, pour l instant, une base et il sera sûrement amené à changer au fur-et-à-mesure selon les besoins. La page principale, développée aussi avec le PDE Eclipse, regroupe deux zones : - Une zone d éditeurs permettant d ouvrir des fichiers. La particularité ici est le mode «read-only» (lecture seulement) de ces éditeurs afin d interdire leur modification. - Un explorateur de projets qui est le module le plus important du «shell» et qui constitue la base du «viewer». Cette vue associée à un «workspace 17» permet de gérer des projets. Cette page est associée à une perspective. On ne s attardera pas ici sur ce dernier terme puisque le «shell» ne propose qu une seule perspective afin de faciliter l utilisation de l application. En effet, afin de répondre au besoin de filtrage des informations selon le profil utilisateur, nous avons réfléchi (développeurs, consultants et product-manager) sur les diverses solutions possibles à l implémentation de cette fonctionnalité. Plusieurs possibilités se dégageaient de cette réflexion : - Développer plusieurs versions de «viewers» adaptés à certains utilisateurs. - Avoir un seul «viewer» avec plusieurs perspectives. - Une seule application avec une seule perspective mais plusieurs vues. C est cette dernière idée que nous avons retenu afin de proposer une application des plus simples possibles. L utilisateur final n aura qu à gérer un ensemble de vues selon ses besoins et la compréhension en est facilitée. Ainsi, il n y a pas plusieurs versions de «viewers», ni plusieurs perspectives à gérer. Après une longue phase d analyse et de tests de l architecture Eclipse, j ai développé l ensemble du «shell» par l intermédiaire du PDE Eclipse : du menu à l explorateur de projets en passant par toute la configuration des pop-up menus. La plateforme Eclipse RCP propose, en effet, de nombreuses configurations qui nous permettent d avoir une application minimale sans écrire aucune ligne de code. Un aperçu du résultat est visible en Figure 20 : Aperçu du «shell Viewer». 17 Workspace pour espace de travail est un répertoire créé à l ouverture de l application et regroupant l ensemble des projets gérés via l application. 32

33 Figure 20 : Aperçu du «shell Viewer» Ce «shell» minimal est une base solide à l ajout de «plug-ins» existants afin de constituer le «viewer» qui sera intégré à la solution Smartesting CertifyIt. Cette application de base représente une petite partie du projet global de «viewer» que je suis entrain de développer au moment où j écris ces lignes. En effet, maintenant que nous avons notre noyau, deux nouveaux objectifs sont fixés. Le premier se concentre sur l explorateur de projets en permettant l ouverture de fichiers spécifiques comme les suites (fichiers avec l extension «.smartsuite» propres à Smartesting) ou les fichiers «emx» propres à RSA d IBM. Le second est l ajout de premiers «plug-ins» déjà existants au sein de la solution Smartesting CertifyIt comme le «tag browser» qui est une vue listant les différents tags présents dans les suites. Le développement de ces objectifs est en cours de réalisation et sera terminé pour la fin réelle de stage à savoir fin Juillet. Pour conclure, nous allons réaliser un bilan technique en listant quelques difficultés majeures rencontrées puis en récapitulant toutes les notions et concepts appréhendés tout au long de ce stage. Nous terminerons par un bilan humain et une conclusion plus générale. 33