Clément DAVID, Pierrick KNECHT, Pierre LALLEMENT, Ronan PRESLE

Transcription

1 Skilldr Approfondissement Technique Clément DAVID, Pierrick KNECHT, Pierre LALLEMENT, Ronan PRESLE TotoAndCo

2 Sommaire 1. Introduction Qui sommes-nous?... 2 A. Clément DAVID... 2 B. Pierrick KNECHT... 3 C. Pierre LALLEMENT... 3 D. Ronan PRESLE Les sujets... 3 A. Clément DAVID Les méthodes Agiles ) Les méthodes agiles, qu est-ce-que c est? ) La méthode Scrum ) Pratique ) Projet de Recherche et d Innovation ) Conclusion B. Ronan PRESLE Intégration continue ) Pourquoi ce sujet? ) Intégration continue ) Les tests ) Les outils de l'intégration continue ) Installation sur le serveur ) Processus d'intégration continue ) Conclusion ) Annexes C. Pierrick KNECHT Impact des EJBs sur les phases de développement ) Approfondissement théorique ) Approfondissement pratique ) Conclusion sur l'approfondissement technique D. Pierre LALLEMENT Single Page Application ) Introduction ) Qu est-ce qu une Single Page Application? ) L intérêt des SPA ) Les inconvénients des SPA ) Développement et mise en place ) La communication avec le serveur ) Outils : les différents frameworks

3 1. Introduction Dans la cadre de la cinquième année à l exia.cesi de Lyon, il nous a été demandé de réaliser un projet d approfondissement technique. Ce projet est un travail à réaliser sur quatre mois sous la forme d un fil rouge, tout ceci en parallèle de nos séances pédagogiques hebdomadaires. Nous devons réaliser ce projet en groupe de plusieurs étudiants de 5 ème année. Les objectifs de ce projet d approfondissement technique sont : Bien approfondir un des domaines techniques considérés par les Systèmes d Informations ; Confirmer l ensemble des aspects conceptuels, organisationnels et économiques du cadre étudié ; Synthétiser et restituer toute l étude menée sous la forme d un rapport écrit, complet, bien pertinent et pédagogique, bien entendu suivi d une conférence publique. D autres domaines connexes vont être abordés durant ce projet. En effet, les points suivants vont également être évalués : S exprimer efficacement à l écrit, et produire des rapports techniques de haute qualité, exhaustifs, synthétiques et pertinents ; S exprimer efficacement à l oral, conduire une prestation orale de haute qualité et fournir des supports de présentation utiles et pertinents. Pour réaliser ce projet, nous avons donc constitué une équipe de quatre personnes aux profils complètement différents. 2. Qui sommes-nous? Comme dit ci-dessus, nous sommes un groupe de quatre étudiants en 5 ème année à l exia.cesi de Lyon : Clément DAVID ; Pierrick KNECHT ; Pierre LALLEMENT ; Ronan PRESLE. A. Clément DAVID «Actuellement en 5 ème année à l exia.cesi de Lyon, j ai opté pour une spécialisation dans le monde du développement logiciel en fin de 2 ème année. Durant les 3 années qui ont suivi, j ai d abord réalisé pas mal de projet en C#. Aujourd hui j ai pris goût à la gestion de projet et je souhaite être le plus performant possible afin d obtenir le poste de chef de projet peu de temps après mon entrée dans le monde professionnel.» 2

4 B. Pierrick KNECHT «Je suis étudiant dans une école supérieure d'informatique, actuellement en préparation d'un diplôme de Manager des Systèmes d'information. Passionné par le paradigme de programmation orienté objet (POO) je suis continuellement à la recherche de nouveaux défis techniques (Algorithmique / Architecture logicielle). Fort soucieux de ma polyvalence je cherche à m'ouvrir constamment à toutes les technologies populaires qui me sont encore inconnues.» C. Pierre LALLEMENT «Étudiant à l exia.cesi de Lyon, j ai suivi la formation de développeur. Passionné par toutes les technologies tournant autour du web, et particulièrement du front-end, je cherche à suivre toutes les nouveautés dans le domaine, ainsi que tout ce qui se rapproche de l expérience utilisateur en général.» D. Ronan PRESLE «Passionné par le développement logiciel, je recherche une réelle expertise technique dans les technologies Java EE. Afin d'atteindre mes objectifs professionnels et de satisfaire ma curiosité, je réalise des projets personnels qui m'apportent des compétences complémentaires que ce soit en développement Java ou sur le système GNU Linux Debian. Ces projets me poussent toujours plus loin vers la technique et son cadre en entreprise.» 3. Les sujets Comme vous avez pu le voir, nous possédons tous des profils très différents dans le monde du développement. Nous avons donc cherché un sujet qui pourrait englober la spécialisation de chacun tout en respectant les contraintes du projet. Dans cette partie, nous allons chacun notre tour, vous présenter de manière la plus précise possible, les sujets que nous avons choisis. Vous retrouverez également ce que chacun a fait durant ce projet pour essayer d en apprendre un peu plus sur l approfondissement technique de la technologie associée. 3

5 A. Clément DAVID Les méthodes Agiles 1) Les méthodes agiles, qu est-ce-que c est? 1. Approche agile plutôt que méthode Le terme de «méthode» est trop réducteur pour parler de cette façon de concevoir, développer et délivrer un logiciel. En effet, ce sont bien plus que des méthodes. On parle plutôt d état d esprit Agile, de philosophie Agile, de culture Agile ou bien encore de d approche Agile ou de mouvement Agile. Cependant, dans la vie courante, on parle de «méthodes agiles» pour définir les méthodes de cette approche. Le terme «Agile» définit une approche de gestion de projet qui prend à revers les approches traditionnelles prédictives et séquentielles de type cycle en V. La notion même de «gestion de projet» est remise en question au profit de «gestion de produit». De façon à raisonner plus dans l optique d un «produit» que d un «projet». Après tout, l objectif d un projet est bien de donner naissance à un produit. 2. Une autre approche de la gestion de projet Une approche dite «traditionnelle» attend généralement du client une expression détaillée et validée du besoin en entrée de réalisation, laissant peu de place au changement. La réalisation dure le temps qu il faut et le rendez-vous est pris avec le client pour la recette. Cet effet tunnel peut être très néfaste et conflictuel, on constate souvent un décalage de phase entre le besoin initial et l application réalisée. Déphasage entre le besoin initial et le produit final 4

6 On se rapporte alors aux spécifications validées et au contrat. Certains projets se terminent dans la douleur (surtout dans le cadre d un forfait classique) au risque de compromettre la relation client. De plus il n est pas rare que certaines fonctionnalités demandées se révèlent finalement inutiles à l usage alors que d autres, découvertes en cours de route, auraient pu donner plus de valeur au produit. Une enquête de 1994 du «Standish Group» (très controversée du fait de la sensibilité du sujet) fait le constat suivant : «31 % des projets informatiques sont arrêtés en cours de route, 52 % n aboutissent qu au prix d un important dépassement des délais et du budget tout en offrant moins de fonctionnalités qu il n en était demandé ; seuls 16 % des projets peuvent être considérés comme des succès.». Cette même enquête renouvelée en 2008 indique un taux de réussite de 35 %, ce qui est plutôt positif mais demeure très faible. Le problème reste entier. Parmi les motifs d échecs, arrivent en tête : - Manque d implication des utilisateurs finaux : 12.8 % - Changement de spécification en cours de projet : 11.8 % L approche Agile propose au contraire de réduire considérablement voire complètement cet effet tunnel en donnant d avantage de visibilité, en impliquant le client du début à la fin du projet et en adoptant un processus de développement itératif et incrémental. Elle considère que le besoin ne peut être figé et propose au contraire de s adapter aux changements de ce dernier. Mais pas sans un minimum de règles. 3. Fonctionnement des méthodes agiles Les méthodes agiles partent du principe que spécifier et planifier dans les détails l intégralité d un produit avant de le développer (approche prédictive) est contre-productif. Cela revient à planifier dans le détail un trajet «Lyon Nantes» en voiture par les petites routes. Spécifiant chaque ville et chaque village traversé, l heure de passage associée, chaque rue empruntée dans les agglomérations, litres d essence consommés, déviations, travaux, etc. Rendant votre planification et vos spécifications très vite obsolètes. Combien de temps aurez-vous passé à planifier cet itinéraire, comment réagirezvous face à vos frustrations de ne pas pouvoir appliquer votre plan à la lettre? L idée consiste à se fixer un premier objectif à courts termes (une grande ville par exemple) et se lancer sur la route sans tarder. Une fois ce premier objectif atteint, on marque une courte pause et on adapte son itinéraire en fonction de la situation du moment. Et ainsi de suite jusqu à atteindre la destination finale. On parle donc d une approche empirique. Dans le cadre d un projet de développement logiciel, le client élabore sa vision du produit à réaliser et liste les fonctionnalités ou exigences de ce dernier. Il soumet cette liste à l équipe de développement, communique directement avec elle (plutôt que par papier) qui estime le coût de chaque élément de la liste. On peut ainsi se faire une idée approximative du budget global. L équipe sélectionne ensuite une portion des exigences à réaliser dans une portion de temps courte appelée itération. Chaque itération inclut des travaux de conception, de spécification fonctionnelle et technique quand c est nécessaire, de développement et de test. À la fin de chacune de ces itérations, le produit partiel mais utilisable est montré au client. Ce dernier peut alors se rendre compte par lui-même très tôt du travail réalisé, de l alignement sur le besoin. L utilisateur final, quant 5

7 à lui, peut se projeter dans l usage du produit et émettre des feedbacks précieux pour les futures itérations. La visibilité ainsi offerte est clé. Cette transparence peut également apporter d avantage de confiance et de collaboration dans la relation client/fournisseur. Les risques quant à eux sont levés très tôt. Si le client a priorisé avec soin son besoin, il peut saisir l opportunité d accélérer le «time to market» si il estime que le produit en l état (partiel) peut aller en production. Economisant ainsi son budget et récoltant un premier retour sur investissement. Il a aussi la possibilité de changer en cours de route la priorité des fonctionnalités qui n ont pas encore été développées (prévues pour les itérations futures). Afin de retarder une fonctionnalité dont le besoin n est pas mûr, ajouter une nouvelle fonctionnalité cruciale en échange du retrait d une autre (respectant ainsi le budget et délais). Cette souplesse ainsi offerte est donc un véritable atout pour le client. 4. Témoignage client Thierry Roche, DSI de l Apec Quels ont été les avantages de ces méthodes pour votre projet? «Déjà, on voit concrètement l évolution du projet car après chaque itération, les utilisateurs peuvent visualiser un bout de projet qui fonctionne, ça brise l effet tunnel des méthodes classiques. Cette évolution nous permet de prioriser nos réels besoins, l application s enrichit selon nos demandes. Le surplus n existe pas, on ne développe pas des fonctionnalités qui ne nous serviront jamais comme c est régulièrement le cas en adoptant des méthodes classiques. On atteint un bénéfice utilisateur plus rapidement mais aussi un gain financier non négligeable. Nous n imaginons même pas un retour avec des méthodes classiques.» Source : Le Monde Informatique 5. Historique des méthodes agiles Sans rentrer dans les détails, la première chose à savoir est que l approche Agile n est pas un effet de mode né de la dernière pluie. En effet, la première approche de gestion de projet de développement itératif date de La première mise en œuvre de la méthode Scrum (la méthode Agile la plus utilisée, documentée et éprouvée aujourd hui) date de La seconde concerne un évènement majeur rassemblant, en 2001, dix-sept figures éminentes du développement logiciel pour débattre du thème qui pourrait potentiellement réunir leurs méthodes respectives. De cet évènement est né le Manifeste Agile rassemblant à la lueur des expériences de chacun les critères pour définir une nouvelle façon de développer des logiciels. Le terme «Agile» pour qualifier ce type de méthode est également né à cette occasion. Aujourd hui ces méthodes ont fait leurs preuves. Tout le monde (dans le monde informatique) ou presque a au moins entendu parler d une méthode Agile (Scrum, extreme Programming, RAD, Chrystal Clear, ). L outillage associé est maintenant disponible sur le marché y compris dans le secteur Open Source. Les formations, certifications, conférences, livres, blogs se sont multipliés. Nous pouvons 6

8 également noter la prise de position en faveur de l approche Agile de la part des organismes faisant «autorité» en matière de gestion de projet informatique : Le Software Engineering Institute à l origine de CMMI en Le Projet Management Institute quant à lui créé en 2001 ses propres certifications Agile. En 2012, le Gartner invite à abandonner complètement le cycle en V. 6. Le Manifeste Agile, un changement culturel Le manifeste Agile contient l essence et la philosophie de l approche en question. Il illustre à lui seul le changement culturel profond qui est en jeu. Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser : Les individus et leurs interactions plus que les processus et les outils Des logiciels opérationnels plus qu une documentation exhaustive La collaboration avec les clients plus que la négociation contractuelle L adaptation au changement plus que le suivi d un plan Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers. La phrase précédente a son importance car si on néglige sa lecture, on peut tomber dans les idées reçues très répandues du style : «Sur un projet Agile, il n y a pas de spécifications, de plan, de processus, d outil et même pas de contrat». (a) Principe sous-jacents au Manifeste Agile Les personnes qui utilisent l approche Agile suivent ces principes : La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutées. Accueillir positivement les changements de besoins, même tard dans le projet. Les processus Agile exploitent le changement pour donner un avantage compétitif au client. Livrer fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. Réaliser les projets avec des personnes motivées. Leur fournir l environnement et le soutien dont ils ont besoin et leur faire confiance pour atteindre les objectifs fixés. La méthode la plus simple et la plus efficace pour transmettre de l information à l équipe de développement et à l intérieur de celle-ci est le dialogue face à face. Un logiciel opérationnel est la principale mesure d avancement. Les processus Agile encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant. Une attention continue à l excellence technique et à une bonne conception renforce l Agilité. La simplicité (c est-à-dire l art de minimiser la quantité de travail inutile) est essentielle. 7

9 Les meilleures architectures, spécifications et conceptions émergent d équipes autoorganisées. À intervalles réguliers, l équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. Pour réaliser ce projet, nous avons choisi d utiliser la méthode Scrum. La partie qui suit présente donc cette dernière. 2) La méthode Scrum Nous avons choisi d utiliser Scrum car, parmi les méthodes Agiles, c est de loin le plus utilisée. Elle est donc le plus éprouvée, documentée et supportée. Livres, blogs, formations, vidéos, associations, conférence traitant Scrum ne manquent pas et bon nombre de ces ressources sont accessibles gratuitement. On pourrait pratiquement parler d un standard Agile. Un autre atout important : Scrum est simple à comprendre. Sa maîtrise en revanche est difficile. 1. Le «package» Scrum Processus Scrum Scrum est considéré comme un cadre ou «framework» de gestion de projet. Ce cadre est constitué d une définition des rôles, de réunions et d artefacts. Scrum définit 3 rôles : Le «Product Owner» qui porte la vision du produit à réaliser (représentant généralement le client). Le «Scrum Master» garant de l application de la méthodologie Scrum. L équipe de développement qui réalise le produit. La vie d un projet Scrum est rythmée par un ensemble de réunions clairement définies et strictement limitées dans le temps (timeboxing) : 8

10 Planification du Sprint (sprint = itération) : au cours de cette réunion, l équipe de développement sélectionne les éléments prioritaires du «Product Backlog» (liste ordonnancée des exigences fonctionnelles du projet) qu elle pense pouvoir réaliser au cours du sprint (en accord avec le «Product Owner»). Revue de Sprint : au cours de cette réunion qui a lieu à la fin de chaque sprint, l équipe de développement présente les fonctionnalités terminées au cours du sprint et recueille les feedbacks du Product Owner et des utilisateurs finaux. C est également le moment d anticiper le périmètre des prochains sprints et d ajuster au besoin la plannification de release (nombre de sprints restants). Rétrospective de Sprint : la rétrospective qui a généralement lieu après la revue de sprint est l occasion de s améliorer (productivité, qualité, efficacité, conditions de travail, etc) à la lueur du «vécu» sur le sprint écoulé (principe d amélioration continue). Mêlée quotidienne : il s agit d une réunion de synchronisation de l équipe de développement qui se fait debout (elle est aussi appelée «stand up meeting») en 15 minute maximum au cours de laquelle chacun répond à 3 questions : «Qu est-ce que j ai fait depuis la dernière mêlée? Qu est-ce que j aurais terminé pour la prochaine mêlée? Quels problèmes j ai rencontré?». 7. L organisation générale (a) Travaux préparatoires L approche Scrum propose de commencer par lister les exigences du client afin de produire le «Product Backlog». Voir l exemple ci-dessous pour la réalisation d un site d e-commerce : Eléments du Backlog L unité de coûts (ou complexité) de la colonne «Estimation» est arbitraire, on procède généralement par relativité en définissant une valeur de base. Par exemple, «voir le détail d un article» étant une exigence simple, elle servira de valeur de base et son estimation sera par exemple de «1 point», «modifier les caractéristiques d un article» étant 2 fois plus compliquée, son estimation sera de «2 points», etc. Le recours à une telle unité (plutôt que de ) permet de faciliter l ordonnancement du Product Backlog, la planification des sprints et des releases. D autre part, il souligne le fait qu il ne s agit que d une estimation (par définition fausse) et non pas d un chiffrage en tant que tel. 9

11 Le Product Owner ordonnance ensuite la liste en fonction de la valeur ajoutée métier, du coût estimé de chaque exigence et des risques identifiés. Les exigences seront réalisées dans l ordre ainsi défini selon les contraintes de l équipe de développement et les éventuelles dépendances (exigence D à faire avant l exigence X). On fixe ensuite la durée des sprints durant laquelle un certain nombre d éléments du «Product Backlog» seront réalisés. L objectif de Scrum consiste à produire le plus tôt possible la plus grande valeur possible, afin de créer des opportunités d accélération du «Time to market». (b) Enchaînement des sprints Une fois que le Product Backlog est prêt et que la durée du sprint est fixée en accord avec le client, il n y a plus qu à remplir le sprint avec des éléments du Product Backlog (planification de sprint). C est également à ce moment que le Product Owner exprime plus précisément son besoin (qu il aura affiné au préalable) pour permettre à l équipe de développement d estimer plus précisément la charge de travail du sprint. Inutile pour autant de réaliser la conception détaillée en séance, des ateliers dédiés pourront avoir lieu en cours de sprint. Le Product Owner peut à tout moment revoir la priorité des exigences qui n ont pas encore été planifiées dans le sprint en cours. En revanche, les exigences engagées dans le sprint en cours sont «sanctuarisées», seule l équipe de développement à le pouvoir de modifier le périmètre du sprint en cas d avance ou de retard. Chaque sprint se termine par la revue de sprint suivie de la rétrospective. Le sprint suivant s enchaîne à la suite selon le même cycle et ainsi de suite jusqu au dernier sprint de la release. (c) Mesure de l avancement Grâce aux estimations individuelles des exigences du «Product Backlog» ainsi qu à la segmentation en sprints, on peut aisément produire un graphique de suivi d avancement représentant l évolution du travail accompli en fonction du temps. 3) Pratique 1. Définition du projet Dans un premier temps, il nous a fallu définir les rôles de chacun. Pour cela nous avons repris les 3 rôles principaux d un projet gérer avec la méthode Scrum. J ai endossé le rôle de Scrum Master afin de vérifier la bonne application de la méthode. Il a également été nécessaire de «simuler» un client. Pour cela j ai également joué le rôle de «Product Owner» afin de se mettre dans de réelle condition de gestion de projet. J ai donc tout naturellement fournit un cahier des charges afin que l équipe de développement puisse lancer le projet. Enfin l équipe de développement, a été constitué des 3 autres membres du groupe. 10

12 Voici un tableau récapitulatif des rôles du projet du point de vue de Scrum : Rôles Product Owner Scrum Master L équipe de développement Attribution Clément DAVID Clément DAVID Pierrick KNECHT, Pierre LALLEMENT, Ronan PRESLE 2. Planification et définition des sprints Avant de se lancer tête baissée dans le projet, nous avons commencé par définir l intégralité du «Product Backlog». Pour ce faire, nous avons divisé l ensemble des tâches à accomplir en 8 grandes parties : 8 grands groupes du «Product Backlog» Pour réaliser ce travail et tous les travaux qui vont suivre, je me suis créer un espace en ligne gratuit par l intermédiaire de la version en ligne de visual studio qui propose de la gestion Scrum. C est alors que nous avons démarré notre premier sprint pour une durée de 2 semaines (du 29 septembre au 13 octobre). Au final, nous avons réalisé 5 sprints, 2 d une durée de 2 semaines et 3 d une durée d un mois : 1. Lancement du projet : 29 septembre octobre 2014 ; 2. Analyse du sujet : 13 octobre octobre 2014 ; 3. Architecture et Intégration : 27 octobre 24 novembre 2014 ; 4. Développement : 24 novembre décembre 2014 ; 5. Rapport et soutenance : 22 décembre janvier

13 3. Tableau de bord Durant un sprint, afin de vérifier que tout se passe bien, il est possible de passer en mode de vue tableau de bord (qui correspond à la représentation numérique des post-it sur le mur). Ce tableau est divisé en 4 parties. La première partie va regrouper un ou plusieurs grands groupes du «Product Backlog» avec le temps encore nécessaire pour finir toutes les tâches. Première partie du tableau de bord Le «+» de couleur verte, nous permet d ajouter directement une tâche depuis ce mode de vision. La deuxième partie peut être considérée comme une «To Do liste». En effet, cette partie va regrouper toutes les tâches qui n ont pas encore été commencée. On peut également voir le nombre d heure encore nécessaire pour terminer le projet. Deuxième partie du tableau de bord Cette vision permet aussi de voir quelle tâche est attribuée à quelle personne. En effet, ici, les deux tâches sont assignées à Clément DAVID. D autre part, les chiffres présents dans les «post-it» représentent la durée évaluée de chaque tâche. Pour la troisième partie, on pourra parler de «travail en cours». C est ici que vont être placées toutes les tâches en cours de réalisation. Dans cette partie l utilisateur mettra régulièrement (généralement en fin de journée) à jour la durée restante pour terminer la tâche. Cela permet également de s intéresser à une autre tâche du même sprint pendant quelques heures (ou journées) sans ralentir l avancée du projet. 12

14 Troisième partie du tableau de bord Comme vous pouvez le voir, on retrouve toujours le nombre d heure restant pour chaque tâche ainsi que la personne en charge de la réaliser. Enfin, pour la dernière partie, on retrouve toutes les tâches déjà effectuées pour ce sprint. Dernière partie du tableau de bord 4. Courbe d avancement En plus du tableau de bord, il existe un autre moyen de vérifier l état d avancement du sprint en cours. Il s agit de la courbe d avancement ou de «burndown». Ce graphique calcule automatiquement une droite «idéale» qui définit une valeur de référence à ne pas dépasser pour finir le sprint dans les délais. Cette courbe permet également d adapter la charge de travail pour un sprint à savoir rajouter ou supprimer des tâches ou tout simplement augmenter le temps passer sur le projet. Il faut savoir que normalement, la mise à jour du temps de travail restant à faire sur chaque tâche se fait en fin de journée. C est donc à ce moment-là que la courbe sera mise automatiquement à jour. Ici on peut voir que la première journée de travail a été très productive puisque nous cumulions environ 50h de travail d avance sur la courbe «idéale». Le pic qui arrive ensuite correspond à une période de vacances pendant laquelle nous n avons pas travaillé sur ce projet, c est donc logiquement que la charge de travail restante à augmenter. 13

15 Courbe de «burndown» 5. Réunion Dans la méthode Scrum, il est demandé de faire des mêlées quotidiennes. Etant donné que nous ne travaillions pas tous les jours sur ce projet, nous les faisions avant chaque début de séquence de travail. Cela nous permettait de se «remettre dans le bain» afin de reprendre plus vite nos activités. 4) Projet de Recherche et d Innovation À l exia.cesi en 4 ème et 5 ème année, nous avons une thèse à rédiger. Il se trouve que ma thèse (Projet de Recherche et d Innovation = PRI) a également pour thème les méthodes Agiles et notamment la méthode Scrum. Les informations qui vont suivre n engage que moi, je vous prierai donc de ne pas voir ceci comme des généralités sur les méthodes Agile ou toute autre méthode mais bien un projet d innovation d un étudiant. Il se peut donc certaines informations ne correspondent pas totalement avec la réalité ou même que certains soient fausses. Dans cette thèse je remets en cause les méthodes existantes et je dis qu il est possible de les améliorer en ajoutant une dimension financière. Cet ajout serait visible durant les sprints en associant un coût à un sprint en fonction du temps que prendraient les différentes tâches. Pour calculer ces coûts, je suis partie du fait qu un ingénieur d étude en BAC +4 gagne 31 par heure et que nous étions tous les 4 des ingénieurs d étude. 14

16 Si on prend par exemple le dernier sprint : Tableau de bord du dernier sprint Ce sprint va coûter 92 heures de travail à notre entreprise. Comme nous avons tous les 4 le même profil : 92h x 31 = Cette méthode permet ainsi de voir quel sprint va être important ou non pour le projet, et donc sur quel sprint on va devoir mobiliser plusieurs membres de l équipe de développement afin de pouvoir ou non faire des bénéfices. Coûts du projet 15

17 Comme vous pouvez le constater ci-dessus, on se rend bien compte que les sprints les plus importants concernent l architecture et l intégration de la solution, le développement de l application et enfin le rendu des rapports et la soutenance. 5) Conclusion Vous vous demandez surement où est l approfondissement technique ici. Et bien tout simplement, jusqu à présent et grâce à la formation fournie par l école, nous n avions qu une approche théorique des méthodes Agiles. Etant intéressé par ces dernières après les avoir côtoyées durant un de mes stages, j ai souhaité mettre en pratique les connaissances que j avais précédemment acquises. 16

18 B. Ronan PRESLE Intégration continue L'intégration continue est un processus appliqué aux projets de développement logiciel pour s'assurer de la continuité du fonctionnement du projet à tout moment de son développement. Il est de plus en plus utilisé en entreprise pour permettre l'amélioration de la qualité du code et la collaboration entre les différents acteurs du projet. 1) Pourquoi ce sujet? Lors de mon précédent stage, j'ai appris l'existence d'un ensemble d'outils Java réservés à l'intégration continue. Ces outils n'étaient pas beaucoup utilisés sur notre application car celle-ci était assez ancienne et le temps disponible était insuffisant pour les mettre en place. Cependant, j'ai décidé de les appliquer dans le cadre d'un projet personnel. Ils m'ont permis d'améliorer mon code et d'éviter des erreurs qui dans le cadre d'un projet en groupe auraient été bloquantes pour les autres développeurs. Mon choix de sujet d'approfondissement technique s'est donc porté sur ce domaine avec la volonté d'approfondir ma connaissance de celui-ci. Je souhaite également élargir mes compétences à l'ensemble des processus techniques mis en place autour du développement d'applications Java afin d'améliorer et d'optimiser mes propres développements. Enfin, l'intégration est une problématique que de plus en plus d'entreprises souhaitent simplifier. L'intégration continue est un moyen assez simple d'améliorer la productivité de tous les développeurs en assurant la continuité dans le fonctionnement de l'application. 2) Intégration continue L'intégration est le processus de partage de code entre développeurs sur un dépôt commun. A chaque intégration, les codes sont réunis et échanger entre eux. L'intégration continue est une pratique de vérification du code à chacune de ses intégrations ayant pour but d'éviter la régression du code ou l'apparition d'une anomalie au sein de celui-ci. Le code est vérifié par un système automatisé de construction qui va valider son bon fonctionnement et sa bonne intégration au reste de l'application existante sur le dépôt. Cela permet de s'assurer que le code peut être compilé sans erreur après chaque partage. Les tests réalisés par les développeurs sont également exécutés après la construction pour valider le fonctionnement de l'application. Ce processus peut être mis place tout au long d'un projet, il est cependant conseillé de le mettre en place dès le début du projet. L'intégration de code individuel peut être une tâche extrêmement compliquée dépendant principalement de la communication entre les développeurs et le travail effectué avant le projet. Chaque développeur doit récupérer le code des autres par un moyen non adapté (clé USB) et vérifie qu'il s'intègre bien à son propre travail. L'intégration continue permet de s'assurer qu'à tout moment, nous sommes capables d'avoir une version fonctionnelle de l'application. Cela évite d'avoir des erreurs dû à un travail trop indépendant de tous les développeurs. En effet, des travaux menés trop longtemps en parallèle sans intégration mènent souvent à une longue période durant laquelle il faut rendre ces ensembles fonctionnels entre eux. Ce n'est pas un outil mais une pratique issue de l'extreme Programming. 17

19 Pour résumer les principaux avantages de l'intégration continue sont les suivants : 1. Compilation du code et valide son bon fonctionnement 2. Réalisation de tests unitaires et de tests d'intégration 3. Mise à disposition d'une version testable de l'application 4. Rédaction de rapport sur la qualité du code, la couverture des tests... Il me paraît important de souligner le second point. Un programme, notamment en développement Java EE, peut-être compilé sans erreur et cependant lever une erreur dès son déploiement. Dans la procédure de construction de l'intégration continue, la compilation et l'exécution des tests sont deux étapes très importantes pour la vérification du fonctionnement de l'application. 3) Les tests Il existe deux types de tests en fonction du cadre de leur exécution et de leurs objectifs : les tests unitaires et les tests d'intégration. 1. Les tests unitaires Les tests unitaires sont des procédures destinées à vérifier le bon fonctionnement d'une petite partie de code source, ou unité de code. Les tests unitaires doivent être rédigés en parallèle du code métier d'une application. Pendant longtemps, les tests unitaires ont été considérés comme étant secondaires par rapport au code principal d'une application. Aujourd'hui, ils ont une importance majeure, une méthode les met d'ailleurs au premier plan : TDD (Test Driven Développement). Dans cette méthode, les tests sont rédigés avant les fonctionnalités. Les tests correspondent aux spécifications de la fonction testée, celle-ci doit répondre exactement ce qui est attendu par le test. Les tests unitaires permettent de détecter très rapidement si une erreur a été commise lors du développement. Qu'ils soient rédigés avant la fonctionnalité testée ou en même temps, leur exécution doit détecter les différences entre le fonctionnement actuel et ce qui est attendu de la part de ce code. Ils sont conservés tout au long du développement du projet et exécutés de manière régulière afin de détecter les possibles régressions. Dans un projet où plusieurs développeurs travaillent sur le même code source, il est possible qu'un développeur modifie le code d'un second pour sa propre utilisation sans savoir où ce code était utilisé auparavant. Si cette modification a un impact sur les fonctionnalités précédemment développées, les tests unitaires correspondant ne seront plus validés. Les tests permettent donc d'assurer la stabilité du code source tout au long de sa vie, du développement jusqu'à la maintenance. Lors de l'exécution des tests unitaires, il est possible d'avoir des statistiques sur les temps d'exécution d'une fonctionnalité particulière. Ceci permet de réaliser une optimisation des blocs de code qui sont les plus longs à exécuter dans le programme. Pour être pertinents, les tests unitaires doivent couvrir un maximum des fonctionnalités de l'application. Les rapports de couverture de code aide les responsables à identifier quelle partie du code n'est pas assez testée en fonction de la sensibilité du code en question. Réaliser trop de tests n'est pas un bon comportement non plus. Lors de la maintenance d'un projet, il peut être nécessaire de modifier certaines anciennes classes entrainant des erreurs dans les tests. Il faut donc modifier les tests pour qu'ils correspondent aux nouvelles exigences de l'interface. Si des tests non pertinents ont été écrits cela va allonger le temps nécessaire à cette phase de maintenance. 18

20 2. Les tests d'intégration Les tests d'intégration sont exécutés à la suite des tests unitaires. Ces tests ont pour objectif de tester le fonctionnement de l'application dans des conditions similaires aux conditions de production. L'objectif n'est plus de tester le fonctionnement unitaire de chaque bloc de code mais plutôt un cas d'utilisation de l'application, une fonctionnalité utilisant plusieurs blocs unitaires. Ainsi ces tests accèdent à ces interfaces comme à des boîtes noires et doivent déterminés si tous les cas d'utilisation de cette fonctionnalité répondent bien aux spécifications définies. Tout comme les tests unitaires, ils doivent être réalisés en parallèle des fonctionnalités et toutes les tester. Mais un nombre trop important de tests peut ralentir certaines phases du projet. Les tests d'intégration sont plus complexes à mettre en place en fonction de la technologie utilisée. Certaines technologies ont besoin d'être exécutées au sein de conteneurs complexes comme les EJBs du Java EE. Il peut être plus complexe donc de réaliser des tests automatisés car une phase de déploiement supplémentaire est nécessaire. Les tests d'intégration complexes sont donc généralement exécutés manuellement par des utilisateurs avant la mise en production. 4) Les outils de l'intégration continue Dans cette partie, je vais présenter tous les outils que nous avons utilisés pendant notre projet afin d'assurer l'intégration continue. Certains de ces outils n'ont qu'un lien limité avec le sujet mais ils ont leur importance dans le fonctionnement général des processus d'intégration de l'application et doivent donc être mentionnés ici. 1. Apache Maven L'Apache Software Foundation est un acteur très important du monde Java. Elle a développé de nombreux outils et librairies pour le développement d'applications Java et Java EE. Apache Maven est l'un d'entre eux. Cet outil est réservé à la gestion et à l'automatisation de la production des projets en Java. Il permet la production d'un logiciel à partir de ses sources en optimisant les tâches intermédiaires et en garantissant le bon ordre de fabrication. Il permet de supprimer les tâches difficiles du processus de build. Les versions 1 et 2 de Maven ont été créées en parallèle. Les versions suivantes du logiciel utiliseront le modèle de Maven 2. Ce logiciel est publié sous licence libre Apache 2.0. Je ne parlerai ici que de Maven 2 et 3 qui apparaitront sans distinction sous le nom générique de Maven. Maven se base sur une approche déclarative grâce à un fichier XML situé à la base du projet, le Project Object Model ou POM. Chaque projet est configuré dans ce fichier à travers plusieurs balises. L'architecture de ce document XML permet aux projets Maven d'être divisés en sous-modules. Ces sous modules possèdent chacun un pom.xml et héritent de la configuration établie dans le pom parent situé à la racine du projet. Ce fonctionnement permet le bon découpage de la configuration mais aussi sa factorisation. 19

21 Maven permet la déclaration de dépendances qui seront résolues lors de la compilation du projet. Ainsi, lorsqu'une librairie est nécessaire pour le fonctionnement du projet, elle doit être déclarée en dépendance dans le pom.xml. Maven va la télécharger et la stocker dans un dépôt local. Il pourra ainsi l'insérer dans le package final de l'application dans le dossier lib. Un dépôt central de Maven est disponible en ligne et paramétré automatiquement à chaque installation. Ce dépôt contient de nombreuses librairies avec leurs versions. Ce dépôt est ouvert ce qui peut entrainer des erreurs ou des incohérences sur certains projets qui ne sont pas beaucoup utilisés. Ce fonctionnement simplifie grandement le développement sur plusieurs postes de développement. En effet, les développeurs n'ont pas besoin de télécharger eux-mêmes les librairies qui sont trop imposantes pour passer par l'outil de gestion de versions. Des profils sont également paramétrables via ce document XML. Ils apportent une configuration dynamique en fonction du profil choisi lors de la construction (par exemple : la définition de propriétés contenant les accès à la base de données pour avoir une base par environnement de travail). Les créateurs de Maven ont vraiment souhaité simplifier son fonctionnement en utilisant des conventions plutôt que des configurations complexes. Ainsi, l'architecture des projets Maven respecte la convention suivante : / : racine du projet contenant le pom.xml /src : les sources du projet. /src/main : les fichiers l'application principale du projet /src/main/java : les sources java /src/main/resources : les ressources du projet (configuration, propriétés,...) /src/main/webapp : les fichiers liés aux applications Web (HTML, JavaScript, CSS, et configuration web.xml) /src/test : les fichiers de tests de l'application /src/test/java : les fichiers Java de tests de l'application /src/test/resources : les ressources des tests (jeux de données, configuration,...) /target : tous les fichiers résultats, les résultats des tests, les packages générés (War, Jar Cette convention peut être modifiée par l'ajout de configuration. Maven possède un cycle de vie assez strict mais dont chaque étape passe obligatoirement après la validation de la précédente compile test package install deploy Ainsi, l'exécution d'une étape va tout d'abord vérifier si l'étape précédente a bien été exécutée et elle sera lancée si c'est le cas. Ces étapes du cycle de vie de Maven sont appelées des goals. D'autres goals sont disponibles mais ils ne font pas partie du cycle de vie normal de construction de Maven (clean, assembly, site...). Ils permettent principalement d'ajouter des actions à réaliser en plus de la construction du projet, comme par exemple la suppression des anciennes constructions. Apache Maven est l'outil le plus utilisé aujourd'hui dans la gestion de construction de projets Java. Son principal concurrent est Apache Ant mais celui-ci est beaucoup plus complexe à configurer. Contrairement à Maven qui se base sur des conventions pour simplifier la configuration, Ant va nécessiter une configuration poussée pour réaliser un projet simple. 20

22 2. Git La gestion de version ou Versionning est un système très important dans le cadre de développement de projets logiciels. Chaque développeur va partager de manière régulière son code sur un dépôt commun pour le projet. Chaque partage, appelé commit, va contenir les nouvelles versions des fichiers de code. Ces versions sont conservées tout au long de la vie du projet pour permettre un suivi de l'évolution du code. En cas d'erreur provoquée à une certaine version, il est donc possible de revenir à une version antérieure à l'erreur. Pour réaliser cette gestion de versions, il existe de nombreux logiciels : Git, Subversion, Mercurial, CVS... Tous ces logiciels ont un fonctionnement commun qui est le partage des codes sources sur un dépôt. Mais deux branches majeures se détachent par la suite. Les systèmes de gestion de versions centralisés sont orientés autour d'un unique dépôt de versions de référence. Seul le dépôt central délivre des numéros de versions pour les partages effectués. Ce type de gestion est plus léger car il limite le nombre de versions mais est plus contraignant car il empêche le travail hors connexion ou le travail sur des branches expérimentales. Subversion est un système de gestion de versions centralisé. Le second type de gestion est la décentralisée qui permet le travail individuel et désynchronisé et par la suite le partage entre collaborateurs. Il existe plusieurs dépôts pour un même logiciel, le principal et celui de chacun des développeurs. Chacun de ces dépôts peut générer des numéros de versions qui seront récupérés par les autres en cas de partage du code. Ce type de gestion possède de nombreux avantages : pas de point sensible unique, le dépôt central n'est pas le seul à posséder toutes les versions permet le travail hors connexion le merge-request est une demande faite au dépôt central pour ajouter son code à la branche principale, l'administrateur donne les droits sur le dépôt après avoir vu le travail réalisé le travail brouillon ou expérimental est réalisé en local le dépôt central ne possède que des versions de partage en théorie fonctionnelles Son principal inconvénient est le fait que le nombre de versions soit beaucoup plus important. Si chaque utilisateur réalise plusieurs versionning de son coté, lors de la mise en commun, l'historique des versions grandit d'autant. La récupération du dépôt est donc plus longue et lourde à cause du téléchargement de toutes ces versions. Git est un des systèmes de gestion décentralisée les plus important aujourd'hui. Il est notament très utilisé dans le cadre des projets open sources. Le projet a été initié par Linus Torvald, créateur de la première version du noyau Linux, et est publié sous licence libre GPL2. Il est disponible sur toutes les plateformes et possède plusieurs interfaces graphiques entièrement conçues par la communauté de développeurs du projet ou par des entreprises. GitLab est une interface Web développée par l'entreprise GitLab B.V. sous licence MIT. Cette interface permet la gestion des dépôts de code Git sur une machine GNU/Linux. Il rend facilement accessible la gestion des utilisateurs et de leurs droits d'accès aux dépôts ainsi que le parcours du code et la gestion de demandes de fusion. En juillet 2013, le projet a été scindé par l'entreprise en deux projets distincts GitLab Community Edition sous licence libre et GitLab Enterprise Edition sous licence propriétaire. Nous avons choisi de travailler avec Git car c'est un système que nous avons l'habitude d'utiliser et que nous souhaitons maitriser. Cet outil est de plus en plus utilisé et ses fonctionnalités notamment au niveau du travail hors connexion nous paraissaient très intéressantes. Pour l'interface graphique client, nous utilisons l'interface graphique fournit avec le logiciel. Cela nous permet d'être plus précis 21

23 dans les fichiers qui composeront la version et évite l'ajout de fichiers de tests modifiés par chaque développeur. Pour le choix de l'interface Web, nous avons cherché l'outil possédant la documentation la plus claire. Le premier essai avec Gitorious n'ayant pas été concluant, nous avons choisi d'installer GitLab qui répond à tous nos besoins en matière de gestion des dépôts Git. 3. Jenkins Jenkins est un projet open sources écrit en Java. Il est originaire du projet Hudson initié par SunMicrosystems. Au rachat de Sun par Oracle, ce dernier a souhaité imposer une licence restrictive sur le projet Hudson. La communauté a alors décidé de réaliser un fork, c'est à dire récupérer le code libre de Hudson pour continuer le projet sous le nom de Jenkins. Cet outil permet la réalisation de l'intégration continue de projets de développement logiciels. Il s'exécute sur un serveur grâce un conteneur de servlet comme Apache Tomcat. A la réception d'un message, il va exécuter une procédure de construction du logiciel. Cette procédure de construction va suivre différentes étapes importantes dont la réalisation des tests (avec Junit par exemple qui est intégré nativement). Différents plugins permettent le paramétrage de ces procédures de construction. Il est possible d'utiliser Maven pour réaliser la construction ce qui permet de bénéficier de tous ses avantages concernant la configuration et la gestion des dépendances. Le message initiateur de la construction peut prendre plusieurs formes : un commit sur le système de gestion de versions du projet, l'activation d'une tâche périodique (CRON), la fin de la construction d'un autre projet ou à l'appel d'une URL spécifique. Ainsi, il est possible de réaliser une construction à chaque partage de code afin de vérifier que le code envoyé ne cause pas d'erreur sur l'application entière. Cela permet de s'assurer du bon fonctionnement de l'application à tout moment de son cycle de vie. Mais la réalisation d'une construction et de tous les tests associés est une activité consommatrice de ressources serveurs. Il faut donc paramétrer la construction en fonction des besoins et des ressources que l'on peut allouer à Jenkins. Une fois le message reçu, Jenkins va lancer la procédure paramétrée de construction. Si une erreur est rencontrée lors de la construction, par exemple une erreur de compilation des sources du projet, la construction est marquée en échec. Les personnes désignées reçoivent un mail indiquant l'échec avec un lien vers le rapport de la construction. Dans ce rapport est présent le log complet de la construction qui permet aux personnes responsables de l'intégration d'identifier l'erreur. En cas de succès, les tests sont exécutés. En cas d'échec de l'un des tests, la construction est indiquée instable. En cas de succès de toute la procédure, tous les rapports sont publiés. Parmi les concurrents de Jenkins, on retrouve CruiseControl publié sous licence BSD. Cet outil permet la construction de code source Java et.net via CruiseControl.NET. Il possède une interface graphique illustrant l'évolution de la construction mais la configuration doit être réalisée manuellement dans les fichiers XML du logiciel. Apache Continuum est également un concurrent de Jenkins qui est souvent revenu lors de nos recherches. Lui aussi open sources, Apache Continuum est principalement dirigé vers le Java. Tout comme CruiseControl la configuration se fait directement dans les fichiers XML. La majeure partie des fonctionnalités reste très similaire entre ces outils. On remarque que tous fonctionnent avec des plugins qui permettent de personnaliser l'outil et de lui ajouter des fonctionnalités notamment avec les outils de gestion de versions, l'envoi de mails, ou la construction par Maven. 22

24 4. Jacoco Jacoco (Java Code Coverage) est un outil destiné à analyser les tests durant leur excéution afin de fournir des rapports de couverture de code. Il est installable sur l'environnement de développement Eclipse et permet la récupération des rapports directement au sein de l'outil. Il est distribué sous licence Eclipse Public Licence. Pour la réalisation de son étude de couverture, Jacoco va ajouter des instructions au bytecode lors de son exécution. Pour cela, il est lancé en tant que Java Agent, c'est à dire qu'il est exécuté dans la JVM en parallèle des tests avec un accès privilégié à la zone mémoire réservée aux tests. Cette instrumentation du code permet la récupération de données d'utilisation du code source et donc avoir un rapport très détaillé. Les rapports de Jacoco sont générés en HTML, ils sont donc visualisables très facilement. Jenkins permet d'avoir une synthèse des rapports de couverture ainsi qu'un accès facilité aux fichiers de HTML de Jacoco. Dans notre recherche d'un outil de couverture de code, nous avons aussi rencontré Cobertura. Cobertura propose des fonctionalités semblables à Jacoco en termes de rapport de couverture de code. Son fonctionnement est différent car pour faire une étude de la couverture, il faut exécuter une commande Maven particulière qui va modifier le code généré lors de la construction. Ce code va permettre la récupération des données de couverture. Malheureusement, cette commande Maven relance une construction complète de l'application ce qui consomme beaucoup trop de ressources serveur. La configuration de Jacoco est donc plus légère que Cobertura pour des qualités de rapports équivalentes. 5. Qualité logicielle et SonarQube La qualité logicielle est une appréciation générale du logiciel basée sur plusieurs indicateurs. La manière dont les fonctionnalités sont implémentées en respectant l'architecture spécifiée lors de la définition des spécificités fonctionnelles est un indicateur orienté vers le fonctionnel du logiciel. La qualité structurelle est la manière dont les besoins non-fonctionnels permettent l'atteinte des objectifs fonctionnels comme par exemple la maintenabilité du code ou sa résistance. Tout l'aspect fonctionnel d'un logiciel ne peut être évalué que par des utilisateurs informés des spécifications attendues et par les tests réalisés tout au long de la vie de l'application. Le structurel en revanche peut être évalué au niveau du code source du logiciel par des outils externes. Le Consortium for IT Software Quality (consortium souhaitant créer un standard de la qualité logicielle) a défini cinq principales caractéristiques nécessaires au code source d'un logiciel pour apporter une plus-value à leur créateur : Fiabilité : mesure le risque que l'application s'arrête de manière non contrôlée Efficacité : assure les performances de l'application Sécurité Maintenabilité : contient les notions d'adaptabilité, de portabilité et de transférabilité à une autre équipe de développement Taille adaptée aux besoins De nombreuses théories ont été énoncées sur le sujet de la qualité logicielle. Je n'irai pas plus loin sur ce sujet puisque ce n'est pas le cœur de cet approfondissement technique. 23

25 Dans le cadre de ce projet, nous avons mis en place un outil d'analyse de la qualité du code : SonarQube, publié sous licence LGPL. Cet outil réalise des analyses du code source à la demande. Il utilise un Sonar Runner qui va parcourir tous les fichiers sources afin d'analyser leur contenu et identifier les défauts. Les relevés concernent principalement les indicateurs de qualité structuraux du code source. Une interface Web permet de voir les rapports présentés dans différents widgets. Si les analyses sont réalisées régulièrement, il est possible d'avoir un historique de l'évolution de tous les indicateurs. Cette interface permet également la visualisation des défauts directement dans le code source et l'attribution des défauts à certains développeurs pour correction. De nombreux plugins sont disponibles afin de compléter les analyses de Sonar. Par exemple, le plugin Jacoco récupère les rapports fait par Jacoco lors de la construction pour afficher les résultats au sein de l'interface de Sonar. Ces plugins offrent également un large éventail de langages couverts par les analyses, plus de 25 aujourd'hui. SonarQube est soutenu par une communauté importante ce qui lui permet d'être intégré à de nombreux outils comme Jenkins ou même l'environnement de développement Eclipse. L'analyse de SonarQube est composée de deux étapes : la récupération de données statiques et la comparaison à des règles prédéfinies. Dans les données statiques, on retrouve le taux de commentaires par rapport aux lignes d'instruction, le taux de méthodes publiques commentées, le taux de code dupliqué ou la complexité des classes et méthodes. Ces données sont purement informatives et doivent être analysées par un responsable pour en tirer les conclusions nécessaires. Par exemple, un code dont toutes les méthodes et classes publiques sont commentées peut être de qualité même si cela représente peu de lignes de commentaires. De même, la duplication peut apparaitre sur des méthodes mais ne pas être gênante, certaines d'entre elles étant très proches dans leur implémentation comme par exemple la méthode equals(). La comparaison avec des règles prédéfinies fait référence aux profils de qualité. Dans SonarQue, il est possible de choisir un profil contenant un ensemble de règles de code associées à une criticité. Par exemple, la convention de nommage de Java pour les variables est une règle de criticité Majeure dans le profil par défaut. Cette règle, si elle est activée lors de l'analyse, va alors lever un défaut pour toutes les variables ne respectant pas cette convention. Les défauts seront visibles dans l'interface avec un texte explicatif concernant cette règle. Les règles sont entièrement paramétrables, il est donc possible de les désactiver si elles ne sont pas pertinentes pour le projet. Il est également possible de définir ses propres règles afin de personnaliser l'analyse. Cet outil d'analyse de la qualité ne peut pas vérifier toute la partie fonctionnelle de l'application mais en revanche elle peut permettre d'uniformiser les développements et donc assurer une meilleure maintenabilité. La performance est également améliorée autour de certains tests. Par exemple, un test sur une valeur NULL va être considéré comme un défaut si une NullPointerException avait été levée plus tôt dans le code. Les concurrents de SonarQube sont assez nombreux. Nous en avons étudié quelques-uns avant de faire notre choix. JTest, Structure101, Coverity et JArchitect sont des outils de qualité propriétaires développés par Parasoft, Headway, Coverity Inc et CoderGears. Leur fonctionnement est assez proche de celui de Sonar et ils fournissent des analyses complètes sur tous types de défauts. Pour tous ces produits le prix des licences est assez élevé, de 400$ pour une licence personnelle à 4000$ pour un poste de développement. Jdepend est lui sous licence BSD, il permet une analyse complète du code mais son interface est moins facile à prendre en main que celle de SonarQube et la navigation et la recherche des défauts sont plus complexes. Le choix de SonarQube était économique et fonctionnel. 24

26 Son intégration aux autres outils et ses fonctionnalités nous permet de pousser plus loin la qualité de nos développements. 6. Arquillian Dans le cadre de notre projet, nous utilisons des Enterprise Java Beans (EJB) et des EntityManager. Ce sont des objets qui sont injectés par le serveur d'applications lorsque l'application a besoin de l'un d'entre eux. Ce fonctionnement est optimisé pour que l'application ne soit pas ni ralentie par des conflits sur un nombre d'instances limitées, ni ralentie par un nombre trop important d'instances. Leur utilisation est donc intéressante mais elle complique notre travail au niveau des tests. En effet, les tests unitaires ne sont pas réalisés au sein d'un serveur d'applications. Il nous fallait donc réaliser de nombreux tests d'intégrations pour couvrir notre application. Afin de simplifier la réalisation de ces tests d'intégration, nous avons utilisé Arquillian. C'est un Framework de test développé par JBoss qui permet la réalisation des tests à l'intérieur d'un conteneur embarqué ou distant. Arquillian s'intègre parfaitement aux Frameworks de tests comme JUnit ou TestNG ainsi qu'aux environnements de développement ou plugins de tests Maven. Grâce à cette intégration, il est facile de créer des tests d'intégration car ils sont très semblables aux tests unitaires. Lors de l'écriture du test JUnit, il suffit de paramétrer le lanceur d'arquillian. Ce lanceur va tout d'abord exécuter une méthode annotée qui va lister les classes nécessaires à l'exécution de ce test et créer une archive. Il va déployer l'archive sur le conteneur paramétré et lancer le test d'intégration. Une fois le test terminé, l'archive est supprimée du conteneur. Dans le cas d'un serveur embarqué, Arquillian sera chargé de son démarrage et de son arrêt. L'objectif principal des développeurs d'arquillian est vraiment de fournir un outil simple d'utilisation pour réaliser des tests d'intégration. Son architecture permet une grande souplesse de paramétrage. Son fonctionnement permet d avoir de véritables rapports de tests automatisés sur des classes situées dans un environnement fonctionnel. Il permet d'accéder à nos EJBs directement depuis nos classes de tests sans configuration supplémentaire que n'en ont les classes métiers. 25

27 Lors de nos développements, nous n'avons pas trouvé d'alternatives automatisées à Arquillian. Plusieurs outils existent afin de réaliser des déploiements automatisés d'une application sur un conteneur (Cargo) puis lancer les tests JUnit mais leur fonctionnement est moins intégré au processus complet des tests JUnit. Arquillian fournit l'avantage d'automatiser les tâches d'injection de dépendances et les connections aux conteneurs, ce qui simplifie le travail des développeurs qui peuvent se concentrer sur les tests fonctionnels. 5) Installation sur le serveur Dans le cadre de nos études, notre équipe de projet loue un serveur chez l'hébergeur OVH. Ce serveur fonctionne avec une version Debian 7 de GNU/Linux. Pour la réalisation de notre projet, j'ai donc mis en place tous les outils Maven, Git et son interface GitLab CE, Jenkins, Jacoco et SonarQube sur notre serveur. Le paramétrage de tous ces outils est assez facile. Etant tous open sources et possédant une communauté assez active, la documentation pour procéder à leur installation est assez claire. Pour notre application Java EE, nous avons choisi JBoss AS en tant que serveur d'applications. Notre souhait était d'apprendre à maitriser cet outil qui est aujourd'hui le premier serveur d'applications certifié Java EE utilisé en entreprise. JBoss est développé par RedHat qui a séparé la version Application Server de la version Enterprise Application Platform. A partir de la version 8 de JBoss AS, il a été décidé de changer son nom pour WildFly afin d'éviter les erreurs. Nous utilisons la version JBoss AS 7.1 sortie en Février 2012 et entièrement certifiée Java EE. Pour notre base de données, nous utilisons MySQL qui est open sources sous licence GPL Cette base de données est très simple à installer, la configuration de sécurité est plus complexe mais très rapidement mise en place pour un accès uniquement local. 6) Processus d'intégration continue Le processus d'intégration continue se déroule tout au long de la phase de développement sur les postes de développement et sur le serveur. Nous avons mis en place trois environnements afin de réaliser nos développements. Le premier est constitué des postes de développement de tous les développeurs. Chaque utilisateurs a installé les outils nécessaires à son travail sur son poste (Eclipse, NetBeans, Git, Jboss, Maven...). Cet environnement contient donc une base de données avec uniquement des données de tests. Sur le serveur, nous avons deux environnements fonctionnant en parallèle. L'environnement d'intégration est celui sur lequel sont exécutés tous les tests serveurs. Une base de données est allouée spécifiquement pour l'intégration. Le dernier environnement est celui de production sur lequel sera déployée la version cliente de l'application. Cette version permettra l'inscription des utilisateurs. Dans notre processus de développement, les versions de l'application passent des environnements de développement à l'intégration sur lequel elles sont testées en profondeur. Une fois les tests réalisés, une nouvelle version peut être publiée en production. Ce fonctionnement nous permet de nous assurer du bon fonctionnement de l'application dans un environnement semblable à celui de production avant de le mettre à disposition des utilisateurs. Les bases de données sont séparées afin d'éviter le mélange des données de tests et les données réelles des utilisateurs. Chaque environnement possède un profil Maven qui nous permet de paramétrer les éléments tels que la base de données et les fichiers de logs de sortie. 26

28 1. Poste de développement Dans le cadre de ce projet nous avons mis en place de nombreuses règles de développement afin d'assurer une continuité des différents fichiers de code. Notre volonté première était de réaliser une application open sources. Pour cela nous avons décidé que l'ensemble du code doit être rédigé en anglais afin de le rendre compréhensible par le maximum de personnes. Puis, nous avons mis en place des conventions de nommage qui sont celles des applications Java en général. Chaque poste possède une référence aux dépôts Git commun avec la possibilité de créer plusieurs branches en fonction du travail accompli. Les branches sont des concepts de gestion de versions qui permettent d'avoir des chemins parallèles de l'historique des versions. Ces chemins parallèles évoluent donc en même temps mais ne partagent que ce qui précède la création de la branche. La fusion de branches permet de réunir des branches en fusionnant les codes sources de celles-ci. Ce système permet de travailler en parallèle sur la branche principale et sur des tâches plus lourdes, plus volumineuses sans qu'elles ne se gênent les unes les autres. L'architecture générale du projet est définie en avant du projet avec le découpage en sousmodule pour avoir un réel découpage des ensembles basé sur les fonctions qu'ils contiennent. Ce sous découpage est facilité par l'utilisation de Maven qui permet très facilement de faire des liens entre les différents sous-modules. Chaque développeur Java du projet possède une instance de Maven sur son poste. Lors de la phase de développement un profil particulier est utilisé pour les développeurs. Ce profil leur permet de réaliser leurs tests de développement sur un serveur d'application et une base de données locale. Ce profil permet le paramétrage des accès à la base de données ainsi que différentes propriétés pour les tests et les logs. En cas de besoin d'une librairie externe, un ajout de dépendance aux pom.xml du projet leur permet de très facilement l'ajouter. Cette modification est presque transparente pour les autres développeurs. Lorsqu'ils récupèrent la nouvelle version du pom.xml à partir du dépôt Git, leur Maven sera mis à jour et la dépendance téléchargée. 2. Serveur L'intégration continue au niveau du serveur commence au moment où un développeur partage du code sur le dépôt Git. A ce moment, Git va réaliser ces traitements de versionning et de sauvegarde d'historique. Il va ensuite appeler une URL précisée dans la configuration du projet avec un certain nombre d'informations sur le projet. Cette adresse est liée à l'instance Jenkins du serveur. A la réception de cette requête, Jenkins va se servir du contenu de la requête pour identifier le projet concerné. Ensuite, l'outil va lancer une construction pour le projet. Cette construction est exécutée avec Maven. Le profil d'intégration est choisi afin que les paramètres utilisés ne soit plus ceux du profil développeurs défini par défaut. Maven va donc démarrer la construction de tous les modules les uns après les autres dans l'ordre nécessaire à la résolution des dépendances. Après la construction de chacun des modules, Maven va exécuter tous les tests du module. Dans le profil d'intégration, on retrouve la configuration pour Jacoco. Ce dernier est lancé en tant que Java Agent pour pouvoir récupérer les données concernant la couverture des tests. Si une erreur a lieu dans cette phase de tests, la construction continue mais elle sera indiquée comme instable. Dans l'interface graphique de Jenkins les erreurs au sein des tests sont très visibles et on retrouve des comptes rendus individuels de chacun d'entre eux ainsi que leurs logs très utiles en cas d'erreur. Les tests unitaires et d'intégration sont exécutés en même temps avec JUnit et Arquillian. Les tests menés par Arquillian 27

29 sont exécutés sur le serveur d'applications JBoss AS installé sur le serveur. Il est possible de séparer les résultats des tests unitaires et des tests d'intégration mais dans notre cas, cette division n'est pas pertinente. Une fois les tests exécutés, Jenkins va faire une demande d'analyse à SonarQube. L'analyse est réalisée sur tous les fichiers du projet. Sonar va alors faire un rapport avec cette analyse afin de relever tous les défauts qu'il a rencontré. Ces défauts seront visibles dans l'interface Web de Sonar et devront être corrigés. A la réception du mail de Sonar, le responsable de l'intégration continue attribue les défauts aux personnes qui les ont créés ou à des personnes plus à même de les corriger. Enfin, certains cas sont déclarés Faux Positifs car dans la situation dans laquelle ils sont relevés par SonarQube, ils ne relèvent pas de défauts de qualité. Jenkins va récupérer une partie des logs émis par SonarQube lors de son analyse et va les insérer dans sa propre sortie. La prochaine étape de Jenkins est le déploiement de l'archives de l'application. Dans ce projet nous travaillons sur de multiples environnements côté serveur. Ceci nous permet de déployer une version d'intégration du projet afin de réaliser nos tests. Jenkins va se charger de réaliser ce déploiement. Pour cela, il va faire appel à un script Bash qui va copier le War généré par la construction dans un dossier spécifique à JBoss. Le script va également créer un fichier vide. Ce fichier va être détecté par JBoss qui va automatiquement déployer l'archive associée. L'application est alors accessible depuis un navigateur Web. Ainsi les nouvelles versions de l'application sont toujours en ligne, disponibles pour les développeurs afin de réaliser des tests d'intégration manuels. 7) Conclusion Tout au long de notre projet, l'intégration continue que nous avons mise en place nous a permis de gagner du temps et d'améliorer notre code. A travers tous les outils que nous avons mis en place durant ce projet, nous pouvons nous assurer du bon fonctionnement de l'application à tout moment. Le développement est lui-même simplifié par l'utilisation d'un outil qui gère lui-même les dépendances du projet. Git et la gestion des versions permet aux développeurs de travailler sur le même code sans avoir de difficultés à les partager. Jenkins nous assure la viabilité de l'application tout au long de son développement. Les tests unitaires et d'intégration réalisés avec JUnit et Arquillian assure la non régréssion et le bon fonctionnement de l'application et de l'environnement serveur. La qualité de notre code et l'uniformité de celui-ci sont garanti par les analyses SonarQube, ce qui rend le projet plus viable à long terme grâce aux indicateurs de sécurité, de performances et de maintenabilité. Le déploiement automatique de l'application sur le serveur d'applications JBoss permet à tous les membres de l'équipe de voir l'évolution du projet, de faire des tests directement sur l'environnement d'intégration et s'assurer du bon fonctionnement de celui-ci. L'intégration continue est un élément majeur de la phase de développement d'une application. Son emploi systématique dans des projets d'envergure peut réduire les coûts de maintenance qui peuvent être très importants dans le cas de projets clients volumineux. Pour les développeurs, l'intégration continue fournit une évaluation permanente du travail ce qui leur permet de l'améliorer en continue et de ne pas ralentir les autres membres du projet. 28

30 8) Annexes Ces annexes sont des prises d'écran des interfaces de nos outils. Ils illustrent certains cas d'utilisations que nous avons cités plus haut. 1. GitLab GitLab est l'interface Web de dépôts Git que nous avons choisi d'installer sur notre serveur. Cette interface permet d'accéder aux détails des dépôts présents sur le serveur. Ici, on peut voir la page d'accueil du projet Skilldr avec la liste des dernières actions. 29

31 GitLab permet le parcours des fichiers présents sur le dépôt. A chaque fichier est associé son historique et une comparaison est alors possible entre différentes versions du fichier. Des rapports de statistiques sont générés et permettent de voir l'évolution des partages de code réalisés pour l'ensemble du projet et par développeur. 30

32 2. SonarQube L'interface Web de SonarQube permet la lecture des rapports générés par Sonar. Ces rapports sont affichés sous la forme de cadres paramétrables. On peut donc choisir les indicateurs les plus pertinents pour le projet. Ici, nous avons une courbe indiquant le nombre de ligne, le pourcentage d'api publique commentée et le nombre de défauts identifiés, la liste des règles les plus enfreintes, les taux de documentation du code... 31

33 Les défauts identifiés par Sonar sont relatifs à une ligne ou un bloc de code précis ce qui permet une correction rapide. Chaque règle est documentée pour être plus facilement comprise par les développeurs. 32

34 L'écran Point Chauds liste les fichiers dans lesquelles les indicateurs sont les plus négatifs. Cet écran permet surtout de faire de l'amélioration continue du code fichier par fichier. 33

35 Des écrans de synthèses sont également disponibles afin de voir l'évolution globale du projet entre deux dates. 34

36 Les règles de Sonar sont entièrement éditables. Il est possible de les désactiver dans le cas où elles ne seraient pas pertinentes pour le projet. Actuellement, pour le profil de qualité Sonar way with Findbugs, nous avons 495 règles prédéfinies. 35

37 3. Jenkins Sur la page d'accueil du projet dans Jenkins, on retrouve différentes informations : la liste des dernières constructions avec leur statut, des accès à Sonar, aux fichiers du projet et aux logs, un aperçu des résultats de test et des rapports de couverture de Jacoco. 36

38 Les rapports de Jacoco sont visibles dans Jenkins. Ils permettent d'identier rapidement les zones du code qui ne sont pas couvertes par les tests. La précision de ces rapports est importante, il est possible d'identifier exactement les instructions testées. Dans le détail d'une construction, il est possible d'avoir des informations sur la version du Git ou les temps de construction de chacun des modules. Ceci permet l'optimisation des traitements au niveau applicatif. 37

39 C. Pierrick KNECHT Impact des EJBs sur les phases de développement 1) Approfondissement théorique J'ai décidé de profiter de ce projet sur les développements J2EE pour approfondir ma connaissance théorique des EJBs. J'ai jugé nécessaire d'expliquer l'ensemble de ces connaissances car elles sont nécessaires à la compréhension de mon approfondissement technique. Dans cette première partie nous allons aborder l'aspect théorique qu'il fut nécessaire de maîtriser pour avancer sur ce projet. En première partie nous verrons les EJBs, en commençant par une définition théorique de l'ejb, des différents types d'ejb existants (avec un bref détour sur les notions de Stateless et Stateful), pour finir par les conteneurs d'ejb. En seconde partie nous verrons les différentes annotations J2EE utilisées dans le cadre d'un développement d'application distribué basé sur un serveur d'ejb, et ceux en nous focalisant sur celles utilisées durant notre projets. 1. Définition des EJBs Enterprise JavaBeans (EJB) est une architecture de composants logiciel côté serveur. Cette architecture est composée d'un ensemble de spécifications d'un modèle édité par Sun. Ces spécifications définissent une architecture. Si elle est respectée cette architecture permet d'utiliser les EJBs de façon indépendante du serveur d'application J2EE dans lequel ils s exécutent. Le but des EJBs est de faciliter la conception d'application distribuée. Les EJBs permettent aux développeurs de se focaliser sur la logique métier de l'application et de laisser la gestion des transactions, la persistance des données et la sécurité aux EJBs et à l'environnement dans lequel ils s exécutent. Les EJBs fonctionnent dans le serveur d'ejbs, celui-ci fournit un ensemble de fonctionnalités utilisés par le/les conteneurs d'ejbs situé dans le serveur d'ejbs. Un EJB ne s'exécute uniquement que dans un conteneur d'ejbs, il ne peut pas s'exécuter en dehors. (a) Définition des conteneurs d'ejbs 38

40 Le serveur d'application (ou Serveur d'ejbs) offre un environnement qui supporte l exécution d'application développé avec des EJBs. Il gère et coordonne l'allocation des ressources de l'application. Le serveur d'application peut contenir un conteneur d'ejbs ou plus. Un conteneur d'ejbs va prendre en charge le ou les EJBs présent en son sein. Pour chaque EJB, le conteneur est responsable de la création et la destruction des instances des objets, de fournir une interface distante des objets, de vérifier la sécurité de l'objet, de gérer l'état actif des objets et de maîtriser la coordination des transactions distribuées. Optionnellement, le conteneur peut aussi gérer la persistance des données de tous les objets contenus. Pour synthétiser, le rôle d'un conteneur d'ejbs permet d'assurer la gestion : du cycle de vie du bean ; de l accès au bean ; de la sécurité d'accès ; des accès concurrents ; des transactions. Il est important de se souvenir que les accès aux EJBs se font obligatoirement par le conteneur, aucune entité externe au serveur ne peut faire appel à un EJB. Il existe plusieurs types de conteneur d'ejbs tel que : GlassFish, Jboss, TomEE, etc. Image n 1 : Disposition du Serveur, des conteneurs et des EJB Il existe trois types d'ejbs : (b) Différents types d'ejbs Les Session beans : Les EJBs en charge de la logique métier de l'application ; Les Entity beans : Les EJBs en charge de la persistance des données ; Les Message-Driven beans : Les EJBs en charge de la gestion des messages asynchrones dans l'application (Ils ne seront pas utilisés dans le cadre de notre application). 39

41 (c) Définition des Session beans Les EJBs session (Session bean) sont des objets proposant des services au contexte qui les appels. Ils définissent la logique métier de l'application. Ils proposent donc un ensemble de méthodes préalablement développés par un développeur. L'instance d'une Session bean ne sert qu'un client à la fois. Il existe deux types d'ejbs session : Stateful et Stateless. Définition Stateless session bean Le Stateless est l'un des deux types de Session bean. Le Stateless permet entre autre le fonctionnement du Session bean sans conserver l'état de la session ou du client entre différents appels. Le seul état qu'il peut conserver doit obligatoirement ne pas avoir de lien avec le client, une instance, une connexion avec la base en cache ou une référence avec un autre EJB. De plus un Stateless peut stocker l'état que pour une durée équivalente à celle de la méthode invoquée. Quand la méthode est terminée, l'état de l'information n'est pas retenu. Les Stateless peuvent permettre de meilleur performance que les sessions Stateful car une Stateful peut avoir à supporter plusieurs clients, alors que le Stateless qu'un à la fois. Définition Stateful session bean Image n 2 : Cycle de vie du Stateless Le Stateful est l'un des deux types de Session bean. Le Stateful permet entre autre le fonctionnement du Session bean tout en conservant l'état de la session (ou du client) entre différents appels. L'état de cette information représente les interactions entre le bean et un client spécifique (un client qui serait en train de parcourir les méthodes et les transactions mis à disposition par le Session Bean). Un Stateful permet de gérer les interactions entre un client et un autre EJB. La création d'un Stateful se fait lorsqu'un client tente par le biais d'une session d'accéder à une méthode du bean. Quand la session est terminée l'instance du Stateful est détruite. Tant que la session est en cours, l'instance est dans le cache (en mémoire). 40

42 Stateless VS Stateful Stateless Session Bean Le Stateless est stocké dans une pool en mémoire, pour éviter de créer un bean à chaque fois qu'il est utilisé. Le serveur utilise une instance du bean quand c'est nécessaire et repose dans la pool quand le travail est terminé. Les Stateless offre de meilleur performance en terme de vitesse par rapport au Stateful. N'a aucune identité et aucune association au client ; ils sont anonymes. N'a aucune persistance. Le bean n'a plus aucun état entre deux appels. Stateful Session Bean Chaque client crée une instance du bean et il peut arriver qu'il finisse par le supprimer. Les instances doivent être inscrites sur le disque si le cache est rempli. Les Stateful ne sont pas aussi performante que les Stateless. Ils sont liés à une instance d'un client en particulier. Chaque bean à une identité implicite. A chaque fois qu'un client interagi avec une Stateful durant la session il s agit du même objet. Il persiste. L'état d'un Stateful est conservé durant toute la session. En général les Stateless sont un bon choix pour une application qui n'a pas besoin de maintenir l'état de plusieurs clients entre deux appels de méthodes. Les Stateless sont préféré pour la légèreté de leur implémentation. C'est le bon choix pour des applications fonctionnant avec des beans autonomes qui ne nécessitent pas d'interactions entre eux. C'est le type que nous aurons favorisé principalement dans notre application. Les Stateful sont un meilleur choix si vous nécessitez de conserver l'état des beans durant toute la durée de la session. (d) Définition des Entity beans Les EJBs entité (Entity bean) sont des beans ayant pour but généralement d'être persistants, d'être donc stockés sur un support physique entre deux sessions. Le client peut utiliser l'entity bean pour accéder aux données stockées de marnière persistante. Une Entity bean encapsule les mécanismes d'accès à la base de données, isolant ainsi la complexité pour ses clients. Il permet aussi de découpler la base de données de la logique métier. Il existe deux sortes d'ejbs entité : Les BMP (Bean Managed Persistence) Les EJBs BMP sont des beans dont la persistance a dû être programmée par le développeur. Les CMP (Container Managed Persistence) Les EJBs CMP sont des beans dont la persistance est assurée par le conteneur d'ejbs. 41

43 2. Annotation & Injection de dépendances Le conteneur est à même d'assurer l'injection de dépendances de certaines ressources requises par un EJB. L'injection de dépendances est faite au moment de l'instanciation du bean par le conteneur. L'injection de dépendances permet de simplifier le travail des développeurs. Le conteneur va prendre en charge grâce à des annotations l'instanciation des dépendances. Ils existent plusieurs types d'annotations qui permettent la mise en œuvre d'une injection de dépendances. (a) L'injection de L'annotation EJB permet de demander au conteneur d'ejbs l'injection d'une référence sur un EJB sans avoir appel à faire appel explicitement à l'annuaire du serveur avec JNDI. En somme il permet de préciser dans le code qu'on souhaite la prise en charge de l'instanciation d'un EJB par le conteneur. L'EJB peut présenter trois utilisations différentes : 1. Si une variable est précédée de cette annotation et que la classe de cette objet est un EJB, aucune instanciation n'est nécessaire plus tard dans le code puisqu'en elle a été faite par le conteneur à notre demande. 2. Si une méthode est précédée de cette annotation et que c'est une méthode de type setter sur la classe de l'ejb alors l'ejb injecté sera du type de l'objet en paramètre de la méthode. 3. Si une classe est annotée cela permet de déclarer que la classe sera utilisée sous forme d'ejb lors de l'exécution. (b) L'injection de L'annotation permet d'injecter des instances de ressources gérées par le conteneur telles qu'une DataSource JDBC ou une destination JMS (queue ou topic) par exemple. Cette annotation est utilisable sur une classe, une méthode ou un champ. Si l'annotation est utilisée sur une méthode ou un champ, le conteneur injecte les références au moment de l'initialisation du bean. (c) Les On utilise 3 autres types d annotations utilisables dans le cas de la déclaration d'un Session bean. Lorsque l'on par exemple on peut le succéder avec l'une de ces 3 annotations : Cette annotation signifie que la classe est un Session bean locale sans utilisation d'interface. Cette annotation s'oppose à Exemple : 42

44 @Local : Cette annotation est utilisée pour préciser que l'interface annotée est l'interface locale d'un Session bean. Exemple : Cette annotation permet d'étendre la visibilité d'un EJB à une autre application. Elle offre à l'ejb un ensemble de méthodes permettant d'assurer l'utilisation du Session bean depuis une autre application déployant des EJBs. La possibilité de rendre un EJB Locale que ce soit signifie que l'ejb n'est pas perceptible depuis un autre déploiement d'ejbs (à l'inverse (d) Quelques annotations communes Il existe beaucoup d'annotations que nous n'avons pas eu la nécessité d'utiliser dans le cadre de notre projet. Voici quelques exemples : Resource : Utilisé dans le cas d'une injection de dépendances avec une ressource du type DataSource, JMS Objects, etc... PostConstruct : Utilisé lors de la déclaration d'une méthode liée au cycle de vie (Précède la construction de l'objet). PreDestroy : Utilisé lors de la déclaration d'une méthode liée au cycle de vie (Précède la construction de l'objet). security.runas : Utilisé pour le code relatif à la sécurité. security.rolesallowed : Utilisé pour le code relatif à la sécurité. security.permitall : Utilisé pour le code relatif à la sécurité security.denyall : Utilisé pour le code relatif à la sécurité security.declareroles : Utilisé pour le code relatif à la sécurité jws.webserviceref : Utilisé dans le cas d'une injection de dépendance de Web Service. persistence.persistenceunit : Utilisé dans le cas d'une injection de dépendances d'un EntityManagerFactory. 43

45 2) Approfondissement pratique Dans cette partie de l'approfondissement technique nous allons plus nous focaliser sur la mise en pratique des EJBs. Parce qu'au-delà de la théorie j'ai constaté que le développement sur un serveur d'ejbs (serveur d'application) était une expérience très différente de celle que l'on connaît peut connaître. Lors de nos travaux nous avons très rapidement du révisé notre façon de concevoir les architectures, nous avons estimé intéressant de partager notre raisonnement. Avec la présence d'une architecture EJB (Serveur d'ejbs, conteneur d'ejbs, beans,...) notre vision du développement orienté objet a nécessité d'être révisé. Nous allons donc voir dans cette partie l'impact des EJBs sur la phase d'analyse. 1. Diagramme de package Pour commencer nous avions souhaité partir sur une application distribuée. Nous aurions donc un front-end géré avec du PHP, un middlewar en J2EE basé sur un serveur d'intégration et pour finir une base de données MySQL. Image n 3 : Diagramme de Package initial Afin de s'assurer la lisibilité du projet nous avons choisi de partir sur une architecture constituée de plusieurs sous-modules : Un package nommé «War» : Package qui contient l'ensemble du front-end. Les différentes pages HTML, son code CSS, et du JavaScript. Un package nommé «RS» : Package qui contient l'ensemble des Web Services exposés au front-end. Ces Web Services basés sur un protocole REST permettent le pilotage de la logique métier présente sur le middleware. Un package nommé «Service» : Package qui renferme 3 autres packages : un package Business, un package Exception, et un package FileManager. Ce package sert de passerelle avec la base de données puisque c'est à travers le package Service que le package RS peut accéder au package DataAccess. 44

46 Un package nommé «DataAccess» : la présence d'une base de données nécessitera d'isoler son accès grâce à un package différent, «DataAccess». DataAccess contient donc un ensemble de classes permettant l'accès aux tables de données situées dans la base de données. DataAccess aurait pu au premier abord être juste présent dans le package Business, mais nous avons pensé qu'il pourrait être utilisé possiblement par les Web Services (RS). Un package nommé «DataModel» : Package qui contient l'ensemble des modèles de données contenus dans la base de données (ex : User, Skill, Job, Domain, etc.). L'ensemble des classes sont des EntityBean, ils vont permettre la gestion de la persistance des données. Un dernier package nommé «Properties» : Le package Properties ne sera présent que pour permettre à l'application d'avoir un espace où stocker ses différents fichiers de paramétrages. 2. Diagramme de classe A présent nous allons entrer dans le détail des différents diagrammes de classes. Dans ces derniers nous auront l'occasion de voir la mise en place des différents packages présentés plus haut. J'ai choisi certains packages dans lesquels apparaissaient les notions d'ejb. C'est à partir de ces différents packages que j'ai pu mettre en pratique la mise en place de Sessions beans et d'entity beans dans une application distribuée. Ici les Sessions beans seront présents dans le package RS, Service et DataAccess. Les Entity beans ne seront présents que dans le DataModel. Nous allons donc prendre le soin de voir le rôle que vont jouer ses différents beans dans ce projet. 45

47 (a) RS (Session Bean) Comme expliqué précédemment le Package RS est le package renferment l'ensemble des Web Services. Image n 4 : Diagramme de classe RS Nous avons décidé de le redécouper en différents packages de la manière suivante : Un package EndPoint qui renfermera un ensemble de classes. Ces classes, dont le nommage termine par «EndPoint», sont toutes des classes constituées de Web Services. L'ensemble des Web Services sont appelés depuis le package War (le front-end) par une requête Ajax grâce à leur exposition en protocole REST. Elles sont découpées en fonction des services qu'elles exposent. Par exemple : «AuthenticationEndPoint» va contenir tout ce qui traite de la connexion et de l'inscription au site. La classe est car son instanciation est générée par le conteneur d'ejb et aussi parce que nous avons fait le choix technique de n'utiliser que des Stateless dans notre application. Nous avons voulu bénéficier des performances en termes de vitesse qu offraient les Stateless. Nous n'avions pas la nécessité de conserver les données entre deux appels. Un package Provider qui va s'occuper d'intercepter les exceptions levées dans l'application, de les identifier et de constituer une trame de réponse HTTP correspondant à l'erreur levée (401, 403, 500). 46

48 (b) Service (Session Bean) Le package Service est un package important car il contient la logique métier de notre application. De plus il est le seul qui puisse piloter le package DataAccess. Image n 5 : Diagramme de classe Service Ici se présente 3 autres packages. Le package Business contient un ensemble de packages représentant la logique métier. Il se découpe en 3 sous-packages : UserBusiness ; AdminBusiness ; SkillBusiness. Ici les 3 sous-packages vont prendre en charge tous les calculs, tous les algorithmes et tous les appels de DataAccess. Les différentes classes présentes dans ces sous-packages sont des Stateless. Ici nous laissons encore une fois le conteneur prendre en charge l'instanciation des objets nécessaires au fonctionnement de la logique métier. Le package Exception contient un ensemble de classes constituant une gestion des exceptions. Ce package est un ensemble de classes d'exceptions que l'on utilise dans notre application. Le package FileManager est contient les classes nécessaires à la conception d'un export PDF. C'est un package mineur non-nécessaire au fonctionnement général de l'application. 47

49 (c) DataAccess (Session Bean) Le package DataAccess est le package clé pour ce qui concerne la base de données. Image n 6 : Diagramme de classe DataAccess Ici la complexité de ce package trompe facilement. En terme d'architecture logiciel le package ne contient qu'un package qui ne contient lui-même qu'une classe. La raison de la présence de ce package intermédiaire est basé sur le fait nous avons pensé que DataAccess pourrait finir par accueillir d'autres package, comme par exemple un package Exception similaire à celui présent dans Service. Dans un souci de future modification nous avons donc créé volontairement plusieurs niveaux. La classe ModelManager<T> est lui aussi un Stateless. L'instanciation de celui-ci est donc prise en charge par le conteneur d'ejb. Le type générique de ModelManager<T> est nommé T, il lui permet de piloter la base de données sans prendre en compte le type d'objet manipulé. Nous avons donc mis en place des méthodes pour pouvoir sauvegarder, mettre à jour, supprimer, ou même récupérer des données dans la table. Il ne reste plus qu à appeler ModelManager de la manière suivante pour manipuler le type User par exemple : ModelManager<User> L'objet «em» de types EntityManager va être instancié par une injection de dépendances grâce à L'appel de cette annotation va fixer sur la variable une instance du Framework Hibernate (dans le cas de notre application). Cette injection va permette en un objet d'encapsuler toute la gestion de la base de données. Ce qui revient en soit à permettre la gestion de la connexion à la base de données, la construction des requêtes SQL, leurs envois et la gestion de toutes les erreurs pouvant être rencontrés lors du pilotage. Au final toutes les méthodes présentes dans le ModelManager<T> vont manipuler l'objet de types EntityManager grâce aux méthodes public de ce dernier. 48

50 (d) DataModel (Entity Bean) Le package DataModel est un package important car il est manipulé par plusieurs autres packages : RS, Service et DataAccess. Image n 7 : Diagramme de classe DataModel Le package est donc constitué par 2 packages : Le package Model contient un ensemble de modèles de données en respectant le format de ces dernières en bases de données. Ici toutes les classes sont précédées de pour préciser que ce sont des Entity beans. Il est primordiale que ce soit le cas car il faut que les données soit persistantes, d'être donc stockés sur un support physique entre deux sessions. L'Entity bean encapsule donc les différents mécanismes d'accès à la base de données, en plus permettre de découpler la base de données de la logique métier. Le package Data ne contiendra quant à elle qu'un enum nommé «Role». La classe Role est isolé dans le Package Data car nous avons voulu faciliter son accès dans le cas d'une gestion des Exceptions. On anticipe ainsi un futur découpage du code. 49

51 3) Conclusion sur l'approfondissement technique L'utilisation des EJBs apporte une dimension très particulière au projet. La prise en charge de la création et la destruction des EJBs par le conteneur d'ejbs est quelques choses de très utile mais aussi de très différent à ce qui se fait sur nos projets habituellement. L'utilisation des annotations tels est quelque chose de vraiment puissant. La possibilité d'injecter l'intégralité du Framework dans un EntityManager pour assurer le pilotage de la base de données en une seule annotation est remarquable. Néanmoins j'ai gardé le sentiment qu'il me reste encore beaucoup de chose à apprendre sur le sujet. Les EJBs sont quelques choses que j'ai tenté d'approfondir ces quelques mois et malgré cette étude je garde toujours la sensation d'avoir à peine creusé le sujet. 50

52 D. Pierre LALLEMENT Single Page Application 1) Introduction Durant ces dernières années, deux principaux facteurs ont joué un rôle majeur dans la transformation d Internet : le nombre de personnes ayant un accès à ce média, ainsi que les technologies relatives à ce dernier. Ces deux causes ont différentes conséquences, tant sur la façon de présenter les sites web avec l importance croissante de notions telles que l ergonomie et le design, que la manière dont ces sites récupèrent, traitent ou envoient les informations. Cette évolution d Internet est flagrante dès que l on prend un peu de recul, et que l on contemple le bond fait entre le «point de départ» que furent les premiers newsgroups des années 80 sans serveur centralisant toutes les informations, et les SPA qui commencent aujourd hui à se démocratiser et qui semblent être extrêmement prometteuses, une énorme avancée technologique a été faite. Cette avancée s est bien évidemment faite en plusieurs temps, avec plusieurs étapes marquantes pour pouvoir arriver aux applications web modernes. 2) Qu est-ce qu une Single Page Application? Le but principal d une single page application (SPA) est de fournir à l utilisateur une expérience plus fluide et se rapprochant de celle des logiciels de bureau plus classiques. En effet, supporter des interactions riches avec des composants multiples (un menu, des bannières, etc.) implique que tous ces composants ont beaucoup plus d états intermédiaires (menu déroulé, sous-menu A mis en surbrillance, item B mis en surbrillance, item C cliqué, etc.). Demander au serveur de faire un rendu pour tous ces états intermédiaires et les envoyer à l utilisateur à chaque fois qu un de ces états est déclenché serait une démarche extrêmement lourde, tant en terme de mise en place que de travail pour le serveur et de transfert d informations entre le client et le serveur. Une des caractéristiques des SPA est que ces pages sont capables de modifier n importe quelle partie de l interface de l utilisateur (menu, encart, texte, ) sans avoir à faire un aller-retour complet avec le serveur. En effet, dans les pages web «classiques», le serveur va générer une page HTML qui sera renvoyée à l utilisateur. Quand celui-ci effectue une action (comme par exemple cliquer sur un lien), l information est envoyée au serveur, qui va la traiter, générer une nouvelle page HTML en fonction de l instruction reçue, et la renvoyer au client. À l inverse, les SPA ne chargent la page qu une seule fois, et lorsque l utilisateur émet une requête, une page complète n est pas générée, mais seulement les informations demandées par l utilisateur, et le cas échéant du code HTML partiel, qui correspond à une partie précise de la page, sont retournés (ce qui explique le terme «single» du sigle SPA : on ne demande au serveur une page complète qu une seule fois). 51

53 Schéma comparatif : page web «classique» (gauche) et SPA (droite) Ce genre de rafraîchissement partiel des pages est rendu possible par la séparation des données de la page de la présentation de ces données, ce qui passe par la mise en place d une couche «modèle» qui va gérer les données et d une couche «vue» qui va lire les données sur le modèle, comportement similaire aux applications de bureau plus classiques. Il existe plusieurs exemples de SPA très utilisés aujourd hui, comme notamment Gmail et de nombreuses Google Apps (Google Drive, Spreadsheets, etc.), des produits Microsoft tels que Excel Online ou encore Outlook, etc. 3) L intérêt des SPA Si les SPA ont autant d importance aujourd hui, c est parce que les avantages qu elles proposent sont nombreux, et affectent aussi bien le serveur sur lequel le site est hébergé que la vitesse d affichage et d exécution du site chez le client. 1. Moins d échanges avec le serveur Le premier point à noter est effectivement le nombre plus réduit d échanges avec le serveur. En effet, un seul chargement «complet» de la page sera effectué au moment où l utilisateur ira sur le site web, durant lequel toutes les informations (HTML, CSS, JavaScript) nécessaires seront récupérées. Cela signifie que toutes les modifications de la vue entraînées par une action de l utilisateur (comme par exemple un clic sur un item d un menu) sont d ores et déjà chargées sur sa machine et n ont qu à être exécutées, sans avoir besoin de consulter le serveur. 2. Volume de données échangées réduit Un second avantage vient du fait que moins de données sont échangées entre le client et le serveur. En effet, alors que dans un site web classique, une page web complète est générée par le serveur et transmise au client pour l affichage, le cadre des SPA permet de n avoir que des informations à transmettre, sans HTML, CSS ou JavaScript supplémentaire. 52

54 Comme vu précédemment, toute la structure de la page est chargée sur le client lors de l affichage initial de la page, et qu une action de l utilisateur qui engendre une modification de la vue sera gérée par sa machine uniquement. Cela signifie que les seules données qui devront être envoyées au client seront le contenu pur. Si nous reprenons l exemple de Gmail, une fois la page chargée, les seules informations renvoyées à l utilisateur lorsqu il cliquera sur un de ses s seront les contenus de ces messages. Même s il faut noter que la différence entre renvoyer une page «complète» avec HTML, CSS, JavaScript et simplement les informations brutes est minime (de l ordre du kilo-octet), lorsque le site en question est visité plusieurs millions de fois par jour, la différence en terme de volume de données est multipliée d autant, et que l intérêt d avoir moins de volume transmis devient substantiel. 3. Déplacement d une partie du traitement métier sur le client Un autre des avantages des SPA vient du fait que l on peut utiliser la machine du client pour réaliser une partie (voire la totalité dans certains cas) des processus métier de l application. Un exemple concret pourrait être la réalisation de graphiques : dans le cas de pages web classiques, les différentes informations seraient récupérées depuis une base de données, puis le serveur construirait la représentation graphique de celles-ci avant de transmettre le tout au client. Avec les SPA, nous pouvons utiliser le JavaScript du côté client pour réaliser puis afficher ces graphiques, ce qui évite de demander au serveur de fournir un travail supplémentaire. Un autre exemple extrêmement intéressant se situe au niveau de la gestion des dates et de l heure. En effet, le JavaScript est capable de gérer les conversions entre le la date et l heure locale et le temps universel coordonné (UTC), ce qui facilite énormément la gestion de ces paramètres qui devaient préalablement être déterminés via une localisation de l IP, souvent approximative et «falsifiable» de l utilisateur pour pouvoir lui appliquer son fuseau horaire correctement. 4) Les inconvénients des SPA Bien que l utilisation de SPA puisse être avantageuse grâce aux points évoqués précédemment, il faut aussi noter que l on y retrouve plusieurs inconvénients. 1. La nécessité de JavaScript Le premier inconvénient vient de la nécessité d avoir JavaScript activé sur le navigateur du client : si l utilisateur a volontairement désactivé le JavaScript sur son navigateur, le site ne pourra pas fonctionner correctement. Bien que ce cas soit extrêmement rare, c est une possibilité à envisager avant d opter pour cette technologie. 2. Search Engine Optimization Un autre inconvénient important lors de l utilisation d une SPA réside dans l optimisation du site pour le référencement («Search Engine Optimization», plus communément appelé «SEO»). En effet, au niveau du référencement naturel : les robots parcourant les sites afin de les indexer fonctionnent toujours sur le modèle du «Web 1.0», et le JavaScript est purement et simplement ignoré. Cela signifie que les seules informations qui seront relevées par le robot seront celles présentes dans la page lors du chargement initial de celle-ci. 3. Analyse Utiliser une SPA implique que le site ne va avoir qu une seule page (ce qui veut dire qu il n y aura qu une seule URL), ce qui va forcément imiter l étude du comportement des visiteurs sur le site, et renvoyer de nombreuses informations «erronées» aux outils d analyse de trafic, comme Google Analytics ou Piwik. 53

55 4. Publicités Enfin, bon nombre de services dépendants des chargements de pages comme par exemple Google AdSense pour la publicité seront rendus inefficaces, car la page n est techniquement chargée qu une seule fois. 5. Solutions possibles Cependant, il faut savoir qu il existe des solutions pour contourner ces différents problèmes. Elles peuvent être plus ou moins faciles à mettre en place, comme simplement ajouter un tag <meta> particulier dans l en-tête du site pour signaler au robot parcourant le site qu il est principalement basé sur AJAX et qu il doit procéder autrement pour récupérer les informations contenues sur le site, ou légèrement modifier le script de récupération de données pour l analyse des visites du site, et bien que la mise en place de ces solutions alternatives demandent du temps, la perte est minime comparée aux avantages de la technologie SPA. 5) Développement et mise en place 1. Le concept d état et les modèles MV* Avant d aller plus loin, il me semble nécessaire de préciser un détail de nommage concernant les Single Page Applications. Le nom qui a été donné à cette technologie est relativement trompeur, car effectivement, car ce n est pas parce que nous réalisons une SPA qu il est impossible pour notre site d avoir une plusieurs pages différentes (par exemple un accueil, un panier et un catalogue pour un site d e-commerce). Un acronyme plus juste pourrait être Single Pull Application, ou encore Rich Web Applications. L idée principale réside, comme je l ai indiqué plus haut, dans le fait qu une seule page «entière» est demandée au serveur, puis que cette page sera modifiée par l utilisateur par le biais de JavaScript et de données envoyées par le serveur. Les pages au sens IHM (Interface Homme-Machine) du terme sont appelées «vues», ou encore «états». D un point de vue architectural, ces vues sont indépendantes. Elles ne sont là que pour donner une allure à ce que l utilisateur voit. En revanche, le contenu affiché par la vue est géré par une autre entité : le modèle. Le rôle du modèle est de capter et de comprendre le comportement de l application. C est cette entité qui va directement gérer les données et la logique métier de l application. Les architectures logicielles qui gravitent autour des éléments de modèle et de vue sont généralement accompagnées par un troisième élément qui vient compléter le motif. Dans le cas des SPA, il en existe trois principales : (a) Architecture MVC : Model View Controller Ici, le troisième élément, le contrôleur, va être le «point d entrée» de l application. C est cet élément qui va recevoir les inputs de l utilisateur et qui va demander la mise à jour des éléments de la page (action sur la vue) ou la mise à jour des données (action sur le modèle). 54

56 Schéma de l architecture MVC Historiquement, ce type d architecture était déployé sur le serveur, et tout y étais traité avant que la vue ne soit renvoyée au client sous la forme d une page HTML générée. De nos jours, avec la modernisation des navigateurs et les possibilités qu offre JavaScript, l architecture MVC a pu être déplacée directement sur le client. (b) Architecture MVVM : Model View View Model Comme l architecture MVC, MVVM cherche à séparer la vue de la logique métier et de l accès aux données mais cette fois-ci en s appuyant sur la notion de data-binding. Les parties View et Model sont similaires à MVC entre lesquelles on trouve le ViewModel, qui est une abstraction de la vue classique qui va également servir de médiateur entre la vue et le modèle (qui est la cible des data-bindings). On pourrait voir cet élément comme une spécialisation du contrôleur du modèle MVC qui servirait de convertisseur qui pourrait changer les informations issues du modèle en informations de vue, et qui fait passer les requêtes de l utilisateur effectuées sur la vue depuis celle-ci jusqu au modèle. Schéma de l architecture MVVM 55

57 (c) Architecture MVP : Model View Presenter MVP est un pattern architectural créé pour à la fois faciliter les processus de tests unitaires automatisés et pour améliorer le principe de «séparation des préoccupations» (Separation of concerns, SoC) au sein de la logique de présentation. Encore une fois, les éléments de Model et de View sont similaires à ceux présentés pour le MVC. Ici, le troisième élément (le Presenter) est une sorte d interface entre les deux premiers éléments qui va agir à la fois sur le modèle et la vue. Il récupère les données depuis une source (le modèle) et le formate pour l afficher dans la vue. De plus, contrairement au MVC, la vue n est ici pas directement liée au modèle. Schéma de l architecture MVP (d) Quelle architecture choisir? Aucune des trois architectures présentées ici n est forcément adaptée lorsque l on cherche à créer une SPA. En effet, les trois façons de concevoir peuvent s appliquer, et le choix d une architecture sur les autres va se faire par le choix de l outil (du framework) utilisé, ou par préférence du (des) développeur(s) si aucun framework n est utilisé. Il n y a pas de «mauvais choix» en soi, seulement des choix plus ou moins adaptés à un problème donné. 6) La communication avec le serveur 1. L utilisation de REST (a) Qu est-ce que REST? REST, acronyme de REpresentational State Transfer, est une architecture, ou norme, qui concerne les systèmes distribués, au même titre que SOAP ou WSDL. Son inventeur, Roy Fielding, la décrit REST comme suit : Une architecture logicielle est définie par une configuration d'éléments architecturaux composantes, connecteurs et données contraints dans leurs relations afin d'obtenir un ensemble désiré de propriétés architecturales. Cette norme regroupe des lignes de conduites concernant la création de web services qui permettent la communication entre deux entités connectées (ordinateurs, smartphones, objets connectés, ) à un réseau à travers le protocole de communication HTTP. 56

58 (b) Le choix de REST Lors de la phase d analyse du projet, lorsque l équipe réfléchissait à comment les communications entre le client et le serveur seraient gérées, il est apparu qu utiliser une norme déjà existante était la meilleure chose à faire. En effet, l avantage d utiliser une norme telle que REST assurait une compréhension à priori universelle du code (REST étant mondialement utilisé), ce qui signifie une facilité à intégrer d autres développeurs sur le projet si celui-ci venait à se développer ainsi qu une maintenabilité facilitée. (c) Le fonctionnement de REST REST repose principalement sur l utilisation des verbes HTTP utilisés par les navigateurs web : GET, POST, PUT et DELETE, qui sont comparables avec les méthodes élémentaires que l on peut trouver dans le monde des bases de données (CRUD, acronyme de Create Retrieve Update Delete). Méthode HTTP Action CRUD Description POST CREATE Création d une nouvelle ressource GET RETRIEVE Obtention d une ressource PUT UPDATE Mise à jour une ressource DELETE DELETE Suppression d une ressource Ces verbes vont être utilisés au sein de requêtes AJAX afin de préciser quel sera le type d instruction à transmettre au serveur 2. AJAX & JSON Le terme AJAX (Asynchronous JavaScript And XML) désigne un ensemble de technologies et techniques de développement web qui sont utilisées pour créer des applications web asynchrones. L utilisation d AJAX est particulièrement indiquée lorsque l on cherche à créer des SPA puisqu elle permet de communiquer avec le serveur sans impacter l expérience de l utilisateur : l asynchronisme des échange de gèle pas l interface utilisateur, et le retour d information peut être utilisé pour modifier la vue. (a) Requête AJAX Un appel AJAX typique se présente de la façon suivante : Exemple d appel AJAX avec jquery 57

59 Les principaux paramètres d un appel AJAX sont donc : L URL : C est l indication de l endroit du serveur où sera traitée la requête. Le type : Un des quatre verbes HTML expliqués précédemment, pour déterminer quelle sera l action de la requête selon les normes REST. Les données : Bien que les données ne soient pas obligatoires dans certains cas (récupération de la totalité des enregistrements d une table particulière par exemple), elles doivent être transmises sous la forme d objet JavaScript. La procédure de succès : Si l appel s est déroulé correctement, on attend généralement un retour du serveur qui contiendra les informations demandées (dans le cas d un GET), ou une confirmation de bonne exécution (dans le cas d un PUT par exemple). La procédure d échec : Bien qu optionnelle, cette procédure s exécute si un problème est survenu lors de l appel AJAX. Les paramètres passés dans cette fonction sont généralement utiles à des fins de débogage. Il existe bien évidemment beaucoup d autres paramètres possibles pour customiser les appels AJAX, mais ils sont beaucoup plus spécifiques et rarement utilisés. (b) Retour JSON JSON (JavaScript Object Notation) est un format standardisé qui permet le transfert d objets via paires attributs valeur. Après un appel AJAX, lorsque des données sont retournées de la part du serveur, deux principaux types de format peuvent aujourd hui être utilisés. Historiquement, le XML était l unique format, mais il est plus courant aujourd hui d utiliser le standard JSON. L avantage du standard JSON est qu il est possible de transformer facilement un objet JSON en objet JavaScript afin de l utiliser dans la vue. (c) Exemple de scénario : connexion à un site Si nous prenons un cas concret de connexion à un site, les échanges entre le navigateur web du client et le serveur se dérouleraient de la façon suivante : l utilisateur entre ses identifiants dans le formulaire et clique sur le bouton de connexion. Au niveau du code, les informations fournies par l utilisateur sont récupérées et envoyées à une fonction JavaScript qui va se charger de faire l appel AJAX. 58

60 Capture d écran de la fonction contenant l appel AJAX Une fois envoyées ces informations envoyées au serveur et le traitement demandé effectué (ici, les vérifications d authentification), une réponse est retournée au client. Ces informations, transmises par chaîne JSON seront transformées en objet JavaScript utilisable par le navigateur du client (ici en exemple, les informations relatives à l utilisateur courant) : Informations de l utilisateur retournées après connexion 59

61 7) Outils : les différents frameworks Avant tout, je voudrais signaler que je vais seulement ici m intéresser aux outils principaux relatifs à la création de SPA. Il existe beaucoup d autres alternatives à ceux que je vais développer ici, mais il est plus pertinent de s attarder sur les technologies principales. 1. Framework ou librairie? Avant de comparer précisément les différentes solutions, il faut s entendre sur les termes utilisés. «Framework» sera utilisé la plupart du temps comme généralisation, mais il existe en fait deux technologies différentes : les frameworks et les librairies. - Ember - AngularJS - Batman - Meteor - Polymer - Principaux frameworks - Backbone - Knockout - Spine - CaneJS - React - Principales librairies La différence entre les deux technologies se fait sur le fait qu une librairie se «greffe» sur une architecture déjà existante alors qu un framework fournit une architecture complète capable de gérer tous les besoins si elle est respectée. 2. Les solutions principales Sorti en juin 2010, Backbone est aujourd hui l outil pour la création de SPA. Le principal avantage de Backbone sur ses «concurrents» vient de sa légèreté (6.4 Ko) et du fait qu il ne dépend que d une seule librairie JavaScript (Underscore.js). Le principal problème de cet outil vient du fait qu il ne propose pas de solutions à des problèmes poussés. En effet, il fait une «base» excellente pour créer des applications web suivant les normes REST et est particulièrement indiqué pour les SPA, mais du développement supplémentaire est nécessaire pour spécifier l outil au besoin. Basé sur jquery, AngularJS est relativement lourd (36Ko) mais très puissant. Il est «MVC-ready», il facilite énormément les tests unitaires, et propose un nombre de fonctionnalités très importantes. De plus, le fait que ce framework soit développé par Google, cela «assure» que l outil sera maintenu. 60

62 Cependant, le principal point noir d AngularJS est qu il est difficilement adaptable à du code existant. De plus, AngularJS est très particulier, ce qui implique une phase d apprentissage plus longue que pour les autres frameworks, et qu une fois habitué, si un changement d outil est nécessaire, il faudra «désapprendre». À l inverse de Backbone, Meteor est le framework le plus lourd, tant en terme de poids qu en terme de fonctionnalités. Un des outils les plus récents, il se veut de «nouvelle génération» et proposant un changement de paradigme sur la manière de considérer les architectures client serveur : développer avec le même langage (JavaScript, ou autre langage se compilant comme tel) sur le client et le serveur. Il va également inclure à ce titre un système de gestion de base de données côté client, ce qui rend possible l exécution de requêtes sans être connecté au serveur. 3. La construction from scratch Certains développeurs préfèrent ne pas utiliser de framework particulier et tout développer euxmêmes. C est le choix qui a été fait pour ce projet, pour des raisons pédagogiques afin de comprendre et manipuler les technologies. Cependant, même un développeur qui cherche à tout bâtir va forcément se créer son propre framework. L avantage principal est que l application ne contiendra que ce qui est nécessaire au développement et sera extrêmement flexible, mais le développeur va être amené à réinventer des fonctionnalités existantes dans d autres outils, et il devra rédiger en plus de son code une documentation complète s il veut que son travail ne soit pas «figé» lorsqu il quittera le projet. ~~~ Fin du document ~~~ 61