Logiciel de gestion d emploi du temps

Conception d Application Informatique Logiciel de gestion d emploi du temps Céline HENRY COMBES et Pierre LUCE sous la direction de Julien IGUCHI-CARTIGNY Université de Limoges - 2011 1

Introduction Le programme du Semestre 6 de la Licence Informatique de l Université de Limoges prévoit la réalisation d un travail de conception d application informatique. Cette Unité d Etude doit mettre les étudiants dans une situation de développement ou de recherche, et les amener à concevoir une solution logicielle. Plusieurs sujets sont proposés, initiés et suivis par un enseignant. Après avoir demandé des conseils, nous avons opté pour le développement d une application de gestion d emploi du temps dans un environnement Java/Spring, sur proposition de M. Julien Iguchi-Cartigny, Professeur à l Université de Limoges. Ce logiciel a comme finalité de remplacer la gestion manuelle des plannings au sein du Département Informatique. Ce rapport vous présente le travail que nous avons effectué ce semestre. Il en suit le déroulement: nous vous présentons d abord les spécifications du projet, puis expliquons le développement des différentes parties du logiciel, et nous vous parlons enfin de nos impressions et des leçons que nous tirons de cette expérience. Pierre LUCE & Céline HENRY COMBES 2

Partie Première : la spécification du projet L effervescence des dernières années autour des méthodes dites «agiles», en lieu et place des processus «monolithiques» régnant habituellement sur les développements informatiques ne doit pas faire oublier la nécessité, identique quel que soit le mode de travail adopté, d une solide phase de préparation du projet. Nous verrons dans cette première partie l ensemble des étapes préalable à l implémentation d une application : le recueil des besoins, la spécification fonctionnelle, l état de l art, l estimation des coûts. Nous expliquerons aussi les différents choix technologiques effectués durant cette phase. 1. Recueil des besoins et spécifications fonctionnelles Il s agit d interroger les futurs utilisateurs sur ce qu ils attendent de leur produit. Les concepteurs et développeurs doivent nécessairement comprendre le travail de leur client (et les processus liés, «workflow» en anglais) et ainsi s approprier le contexte d utilisation du logiciel et l utilité des fonctions demandées. C est lors de ces discussions, de ces échanges, qu est mis au point un premier modèle métier, avec un formalisme compréhensible par les utilisateurs finaux, qui doivent ainsi pouvoir le valider. Dans le cas présent, nous avons la charge de développer pour le Département Informatique de la Faculté de Sciences et Techniques de l Université de Limoges une application web de gestion des emplois du temps. Les responsables de formation aimeraient pouvoir composer et diffuser aisément les emplois du temps des différentes promotions. Actuellement, leur conception «manuelle» est rendu complexe par le fait que les enseignements se font parfois en groupes, avec des matières optionnelles et des contraintes diverses et variées. La plus grosse partie de l analyse n a pas été de notre ressort mais a été réalisée par M. Cartigny. Nous nous sommes basés sur son travail pour définir les spécifications fonctionnelles de l application. Voici les 5 principales fonctions retenues : a. Editer l emploi du temps de l utilisateur Il s agit de la fonctionnalité principale du logiciel. L utilisateur obtiendra une grille horaire des évènements le concernant ayant lieu dans une période donnée, soit un jour ou une semaine. b. Organiser les domaines Un utilisateur responsable d un domaine peut y ajouter des sous-domaines, pour former une organisation hiérarchique, un domaine étant une abstraction pouvant correspondre à un cours, une formation, un département c. Gérer les utilisateurs d un domaine Le responsable d un domaine peut y ajouter des utilisateurs avec un rôle particuliers. Il peut aussi le faire avec ses sous domaines. d. Répartir les utilisateurs dans des groupes Le responsable d un domaine peut créer des groupes d utilisateurs liés à son domaine (ou à un de ses sous-domaines). e. Ajouter un évènement 3

Le responsable d un domaine ajoute un évènement le concernant en précisant une date, une heure de début, une durée, et les utilisateurs concernés (en utilisant potentiellement un groupe d utilisateurs). L évènement dispose en plus d une description optionnelle. 2. Etat de l art Nous avons tout d abord cherché ce qu il existait déjà en terme de gestionnaire d emplois du temps sur le marché. Il existe deux principales catégories de ce type de logiciel : La création annuelle d emplois du temps de collège ou lycée. Ces logiciels sont très complets et performant. Ils prennent en comptes les cours des étudiants, les disponibilités des professeurs, la cohérence de la succession des cours. Néanmoins ces logiciels sont utilisés une fois par an afin d avoir un emploi du temps unique valable pour toute l année scolaire. Ce type de logiciel ne conviendrait donc pas au besoin de l université dont l emploi du temps est généralement modifié chaque semaine. De plus l utilisation de ce logiciel chaque semaine serait fastidieux en effet ces logiciels sont «lourd» c est-à-dire qu il demande beaucoup de capacité et de temps d exécution. Le gestionnaire d emplois du temps destinés aux particuliers. Pour exemple nous pensons à l emploi du temps de Google, ces logiciels permettent de créer des plages de réunion, de rendez-vous très facilement. Ces plages horaires peuvent tout à fait être des plages horaires de cours. Néanmoins ces plages horaires sont trop flexibles pour être adapté à des cours qui ont généralement des durées fixes. De plus ces emplois du temps n ont pas la notion de «journée» qui débute à 8h et se termine au plus tard à 18h30. Nous avons donc décidé de nous baser sur un type de gestionnaire d emplois du temps destiné au particulier en prenant comme base de départ le calendrier de Google. 3. Estimation des coûts Réalisé d après les spécifications, cette estimation permet d obtenir un coût de développement prévisionnel. Grâce à la méthode des points de fonction, nous estimons le nombre de lignes de codes entre 5000 et 6000. Cela correspond (méthode COCOMO) à un effort de 22 mois-homme. 4. Technologies mises en œuvre Le projet concerne la réalisation d une application web, c est-à-dire un logiciel utilisable via un navigateur internet standard. Ce type d application repose principalement sur une architecture client-serveur : le client est le navigateur internet, le serveur est un programme fonctionnant sur un ordinateur distant. a. Technologie côté «serveur» Elles sont multiples, et se distinguent principalement par le langage de programmation utilisé. On trouve sur le marché deux grandes catégories de technologie «serveur» : les «professionnelles» d un côté, éprouvées depuis des années, avec principalement Java Enterprise Edition (Oracle) et DotNET (Microsoft), et de l autre côté des langages parfois relativement ancien mais dont l utilisation sur des applications professionnelles croît de plus en plus : PHP en est le fer de lance, avec plusieurs millions de sites «amateurs» l utilisant, et de plus en plus de frameworks efficaces et solides sur lesquels s appuient de nombreuses entreprises. Le choix est fait pour notre projet d utiliser le langage Java, pour plusieurs raisons : 4

le système d information de l Université utilise déjà cette technologie, ce qui facilitera l intégration de notre logiciel en s appuyant sur le framework Spring, il est possible de développer rapidement une application solide et facilement extensible c est une technologie avec une licence libre, contrairement à DotNET Les nombreuses bibliothèques et les frameworks éprouvés existant sous Java vont faciliter le développement. Parmi ceux utilisés, notons : Spring Framework : qualifié de «container léger», il propose entre autre un système d injection de dépendance, de gestion de la sécurité, une architecture MVC Java Persistence API : officiellement spécifiée par le Java Community Process, cette API décrit un ORM (Object-Relational Mapping) à base de classes entités annotés, permettant de se passer de requêtes SQL répétitives, et de faire abstraction du SGBD utilisé. b. Technologie côté «client» Le rendu d une interface graphique dans un navigateur laisse plus de choix qu on ne pourrait le penser en premier lieu. La première possibilité venant à l esprit est l utilisation du langage de description HTML, assisté des feuilles de style CSS et du langage dynamique Javascript. Mais il est aussi possible d utiliser d autres formes de rendu, comme par exemple Flash, notamment avec la technologie Adobe Flex, voire même la réalisation d applet Java pour faire une interface. Néanmoins, et bien que Flex présente beaucoup d avantages, il a été retenu d utiliser quelque chose de «classique» : HTML, CSS, modernisé par l utilisation d un framework Javascript. Après avoir choisi dans un premier temps JQuery, nous avons finalement opté pour le framework ExtJs qui propose d excellents widgets graphiques et tout le nécessaire pour réaliser une application web dynamique et moderne, utilisant entre autre AJAX pour des communications client-serveur asynchrone. 5

Partie Seconde : le développement du projet Une fois le recueil des besoins effectués, la faisabilité étudiée et les technologies choisies, il est temps de commencer le développement du projet. Celui-ci se découpera en plusieurs parties, pouvant se dérouler parfois en parallèle : la formation sur les technologies utilisées, le maquettage des interfaces graphiques, le développement coté serveur et l intégration des interfaces graphiques avec le développement côté client. 1. Se former Les premières semaines de travail ont été consacrées à l apprentissage des technologies utilisées. Nous nous sommes initialement réparti le travail, Céline s occupant de la partie «Client», Pierre de la partie «Serveur». Nous avions donc chacun différentes choses à apprendre, mais les méthodes étaient les mêmes : lecture d ouvrages spécialisés et suivi de didacticiels trouvés sur Internet. Spring et JQuery proposent une documentation exhaustive qui facilite grandement leur prise en main. La large communauté d utilisateurs met à notre disposition beaucoup de ressources. 2. Concevoir les maquettes Notre travail comporte une part essentiel d interface graphique. En effet, l application doit principalement être pratique à utiliser, sans quoi elle sera délaissée. Beaucoup de logiciels «utiles» n ont pas connu de succès à cause d un aspect austère et d une interface trop peu ergonomique. C est pourquoi nous avons passé du temps à concevoir les maquettes de notre application. Ce travail nous a permis de préciser les spécifications, et plus particulièrement de trier ce qui devait être fait en priorité et ce qui pouvait venir plus tard. Au-delà de l aspect esthétique, nous cherchions surtout la meilleure organisation des différents écrans. Figure 1.Exemple de maquette sur papier 6

Ainsi, malgré le changement de framework Javascript après coup, le travail effectué au préalable ne l a pas été en vain. Car si l apparence diffère quelque peu, la structure globale reste inchangée quelle que soit la technologie utilisée. Comme souvent, un premier jet a été fait sur papier, puis en HTML. C est au final le widget Ext.Calendar fait par Ext.Ensible qui sera retenu comme base de travail pour la présentation des emplois du temps. Cette extension à ExtJs propose des fonctionnalités de présentation similaires à celle de Google Agenda. 3. Environnement de développement Afin de se familiarisé avec des techniques professionnelles de développement, il a été décidé de mettre en place une «forge logicielle». Ce concept comprend principalement l utilisation d un serveur d intégration continue et d un système de gestion des sources. a. Source Code Management (Gestion du code source) Un logiciel de SCM sert à maintenir l ensemble des différentes versions d un code source, en traçant la moindre modification, ce qui permet à tout moment de revenir à une version précédente, ou de séparer un projet en plusieurs variantes. Son utilisation est indispensable dans un environnement ou plusieurs développeurs peuvent travailler sur les mêmes fichiers : le système de gestion des conflits intégrés à ces logiciels permettent de ne pas perdre d information en cas de modifications simultanées d un fichier par deux personnes. Pour ce projet, c est le logiciel Mercurial qui a été utilisé. b. Intégration continue Rendu populaire par l Extreme Programming, l intégration continue est une technique de génie logiciel visant à vérifier à chaque changement du code source qu aucune régression n est introduite dans un programme fonctionnel. Ainsi, un ensemble de tests (et d autres tâches) est automatiquement mené à chaque ajout de modification sur le serveur de gestion du code source. Pour mener à bien ce travail, nous avons installé un serveur d intégration continue appelé Hudson, qui permet cette automatisation de la construction d un projet. Assisté de Apache Maven, gérant les dépendances, le serveur va régulièrement scanner le dépôt de code source et si il y détecte une mise à jour, va lancer automatiquement une série de tâche : Récupération de la dernière version des sources Compilation Tests Analyse qualité du code via Sonar En cas d échec, une alerte est envoyée, entre autres au développeur ayant effectué la mise à jour des sources causant l échec. 7

Le logiciel Sonar fournit un ensemble de métriques pour évaluer la qualité du code : complexité, respect des bonnes pratiques, taux de couverture du code par les tests 4. Développer côté serveur Afin de faciliter le développement côté serveur, ce dernier se fera principalement en testant «en local» sur l ordinateur du développeur, et en fin de journée un «commit» sur le dépôt de code source est effectuer. Cela permet d économiser le temps de déploiement sur un serveur de développement distant. a. Test-Driven Development Après avoir commencé en développant de façon «standard», nous avons rapidement voulu essayer un nouveau mode de travail : le développement piloté par les tests. Aussi appelé «Test First», cela consiste en l écriture préalable à tout code «fonctionnel», des tests qui assureront du bon fonctionnement de notre code. Kent Beck, inventeur du TDD, le résume en disant qu aucune ligne de code fonctionnel ne doit être écrite si elle n est pas déjà testée. Voici la chronologie d un développement «test-driven» : Ecriture d un test où la future classe/fonctionnalité est utilisée avec l interface désirée, et vérifiant son fonctionnement. 1) Exécution du test : il y a beaucoup de chance que ça ne compile même pas, au mieux, le test échouera => «Red» 2) Ecriture d un minimum de code pour que le test fonctionne. Cette étape doit durer le moins de temps possible, et, si nécessaire, le code écrit peut utiliser des constantes ahurissantes, pourvue que le test passe => «Green» 3) Refactoring du code, afin de le rendre réellement fonctionnel, en procédant par étapes, vérifiées à chaque fois par une validation des tests => «Refactor» «Red» «Green» «Refactor», tel est le credo du Test-Driven Development. Ce mode de travail, très troublant dans un premier temps, prouve son efficacité par la grande confiance que l on place en son code, sans pour autant avoir à rédiger des dizaines de tests couvrant tous les cas les plus extrêmes. b. Le framework Spring La programmation d un logiciel est essentiellement constituée de travaux répétitifs, communs à tous les programmes du même genre : accès à une base de données, gestion d un cache, traitement d un formulaire, etc. Une application web sous Java doit en outre se plié à la lourdeur de certaines technologies JEE (anciens EJB 2, servlets ). Pour pallier à ces problèmes, il existe pour de nombreux langages des frameworks, assemblage de briques logiciels préfabriquées et réutilisables. Un framework peut être vu comme un ensemble de librairies rassemblées et organisées autour d une architecture, souvent imposée (au moins en partie) au logiciel final. Dans la sphère Java, le framework le plus connu et le plus utilisé est probablement Spring. Il couvre la plupart des aspects du développement d une application, et même d un ensemble applicatifs : tiers web, web services, clients lourds, applications distribuées. Divisé en modules, gérant chacun un ensemble cohérent de fonctionnalités, Spring repose sur le concept de l Inversion de Contrôle (IoC) et de l Injection de Dépendance (DI). Ces motifs de conception proposent globalement de découpler les éléments du programme en supprimant les instanciations directes d un objet, au profit d autres méthodes d instanciations, via l injection depuis un conteneur, ou grâce au design pattern Factory. Ainsi, le type d un objet instancié peut être modifié à travers tout 8

le programme en modifiant un fichier de configuration ou une annotation, et puisqu il est utilisé à travers des interfaces, il n y a pas à modifier le code. Spring Framework is a Java platform that provides comprehensive infrastructure support for developing Java applications. Spring handles the infrastructure so you can focus on your application. Spring enables you to build applications from plain old Java objects (POJOs) and to apply enterprise services non-invasively to POJOs. This capability applies to the Java SE programming model and to full and partial Java EE. INTRODUCTION TO SPRING FRAMEWORK, DOCUMENTATION OFFICIELLE Associé au framework Hibernate/JPA pour la gestion de l accès aux données, il offre la possibilité de développer des applications sûres et flexibles, et ce de façon rapide, tout en assurant une maintenance et une évolutivité simplifiées. c. L architecture MVC et Spring MVC Les applications web modernes fonctionnent pour la plupart selon le modèle dit «Modèle, Vue, Contrôleur» (MVC), proposant la séparation en trois couches principales des éléments du programme : Un Modèle représentant le métier de l utilisateur via des objets métiers. On y inclut aussi souvent l accès aux données. Une Vue servant de représentation du modèle et d interface d interaction avec l utilisateur. Un Contrôleur qui se charge de lier la Vue et le Modèle afin de les découpler et de fournir à la vue une interface nécessaire et suffisante à ses besoins. Figure 2. L architecture MVC 2 de Spring MVC (image tirée de la documentation officielle) 9

Spring MVC est le module du framework Spring permettant la création d une application web J2EE sans avoir à programmer de Servlet, et qui utilise l architecture MVC 2. Cette évolution du MVC utilise un contrôleur «frontal» qui va réceptionner toutes les requêtes et les distribuer ensuite à des contrôleurs plus spécialisés. Ces derniers vont effectuer le travail «fonctionnel» puis créer un objet de modèle qui sera transmis à la vue pour affichage. Spring MVC propose depuis sa version 3 une configuration presque intégralement basée sur des annotations Java plutôt que sur des fichiers XML. Le Listing 1 donne un exemple de contrôleur. @Controller @RequestMapping(value= /account ) public class AccountController { } @Ressource private AccountService accountservice; public void setaccountservice(accountservice accountservice){ /**/ } @RequestMapping(value= /list ) public String getaccountlist(model model) { /**/ } @RequestMapping(value= /creer,method=requestmethod.post) public String create(@valid Account account,bindingresult result) { /**/ } @RequestMapping(value= /creer, method=requestmethod.get) public String getcreateform(model model) { /**/ } Listing 1. Exemple de méthode d un contrôleur Nous y voyons que les url des requêtes sont mappées vers des méthodes particulières des contrôleurs. Les options sont nombreuses et permettent de rediriger précisément les demandes vers les réponses correctes. Néanmoins, si cette méthode de configuration est bien moins lourde qu un fichier XML dès que notre application prend de l ampleur, elle est aussi plus intrusive. d. Architecture de l application Maintenant que nous avons présenté le modèle MVC, utilisé pour la couche Web de notre application, nous allons vous présenter son architecture (voir Figure 3). Figure 3. L architecture de l application 10

Il y a donc 4 couches principales : Couche «domaine» : ensemble des objets métiers, ce sont des POJOs (JavaBeans classiques) annotés pour des besoins de persistance de donnée Couche «DAO» : gère la persistance et l accès aux données, via la Java Persistence API, abstraction représentant une connexion à une base de donnée et la gestion des entités selon des concepts objets et non pas relationnels. Couche «services» : c est elle qui va exécuter les fonctionnalités de l applications, en interagissant avec les DAO. Couche «présentation» : on y trouve deux façons d accéder aux fonctionnalités : via une interface web (Spring MVC) ou via des Web Services (gérés aussi par Spring) Parallèlement à ses couches, le conteneur léger Spring gère tout ce qui est instanciation et injection des dépendances. Le plus gros du travail sur les couches Services, DAO et Domaine a été fait par M. Cartigny, nous nous sommes contenté d y apporter ponctuellement une modification, une correction, ou une fonctionnalité supplémentaire. e. Travail effectué Notre principal travail a donc été de programmer les contrôleurs de l application web. Il a donc fallu dans un premier temps se mettre d accord sur une interface, un protocole d échange avec la partie «client», c est-àdire mettre au point le format des données échangées avec l application JavaScript présente sur la page Web. Une fois cette tâche effectuée pour chacune des fonctionnalités attendues, nous avions donc toutes les signatures des méthodes de nos contrôleurs. Après avoir rédigé les tests adéquats, nous avons implémentés le code fonctionnel. La plupart du temps, le code d une méthode suit le schéma présenté par la Figure 4. Figure 4. Fonctionnement schématique d une méthode de contrôleur Un exemple de traitement est visible dans le Listing 2 : on y trouve une méthode permettant l ajout d un nouvel objet Domain en base de données. Les 3 étapes présentées dans la figure 3 sont présentes. L objet retourné au final est une Map, correspondant à l objet JSON attendu par l application ExtJS côté client. On peut y voir toutes les annotations permettant la configuration et l injection des dépendances. Trois contrôleurs ont étés réalisés : EventController : gestion des évènements DomainController : gestion des domaines 11

AccueilController : page d accueil, point d entrée de l application @Controller @RequestMapping(value= /domaine ) public class DomainController { @Resource private DomainService domainservice; /**/ // Cette méthode prendra en charge une requête POST d url./domaine/ajouter @RequestMapping(value= /ajouter, method=requestmethod.post) public @ResponseBody Map<String,Object> adddomaine( @RequestParam( parent ) String parenteid, @RequestParam( title ) String title, @RequestParam( description ) String description){ // On créé un objet de réponse HashMap<String, Object> hm = new HashMap<String,Object>(); try { // Vérification des paramètres if(title!= null && title.length() == 0) throw new IllegalArgumentException( Domain title is empty ); // Accès au Service if(parenteid.equals( 0 )){ domainservice.createrootdomain(title, description); } else { domainservice.createdomainindomain(title, description, parenteid); } // Préparation de la réponse hm.put( success, true); } catch (Exception e){ hm.put( success, false); hm.put( error, e.getmessage()); } return hm; } // Retour de l objet réponse /**/ } Listing 2. Exemple de méthode d un contrôleur 5. Développer côté client La façon de travailler sur le code côté client a été légèrement différente. Le développeur concerné étant seul à travailler dessus, et son intégration avec l application final étant tardive, peu de commit ont été réalisés sur le gestionnaire de sources. Une grosse partie du travail ayant d ailleurs été fait sur papier, il y eut dans un premier temps relativement peu de code. 12

Deux technologies JavaScript se sont succédé. Le début du travail a été fait autour de JQuery, qui fut ensuite abandonné au profit d ExtJs. Nous vous présenterons donc ce framework, les extensions utilisées et enfin le travail final réalisé. a. ExtJs (Sencha) Né comme une extension de la librairie Yahoo User Interface, ce framework a très rapidement pris son indépendance. Il propose de nombreux widgets graphiques permettant la création d interfaces complètes, ergonomiques et professionnelles dans un navigateur web : formulaires, grilles de données, fenêtres La dernière version (ExtJs 4) est sortie au mois d avril, mais n étant pas compatible à 100% avec le travail effectué, nous avons poursuivi le travail sous la version 3.3.1 sortie en novembre. Le framework organise ses widgets selon un modèle découplant l objet d affichage (la grille par exemple) de l objet permettant de manipuler les données (appelé un Store), qui lui va par exemple aller chercher les données sur un serveur, ou envoyer les requêtes pour les modifier. Figure 5. Fonctionnement des widgets ExtJS La figure 5 schématise ce fonctionnement. Le widget est la partie graphique, le formulaire ou la grille par exemple. Le store est un objet avec lequel le widget va intéragir, il va contenir les données traitées par le widget. C est en quelque sorte une base de donnée locale à la page. Le Proxy va représenter une source de données. Le plus utilisé sera le HttpProxy, qui permet de récupérer et de modifier les données via des requêtes AJAX. Entre le Store et le Proxy, les communications sont difficiles car le Store ne manipule que des objets, alors que le proxy peut récupérer des chaines sous divers format (JSON, XML ). Pour les aider, on utilise des Readers et des Writers, qui vont convertir dans un sens et dans l autre les données brutes en objets. b. Le widget Calendar de Ext.ensible Au cours de nos recherches, nous avons trouvé une création qui nous poussa à adopter ExtJs comme technologie client. Il s agit du widget «Calendar» fait par la société Ext.ensible et distribué gratuitement pour une utilisation non commerciale. Il s agit d un calendrier présenté à la façon de Google Agenda, avec des vues paramétrables (jour, semaine, mois), les interfaces d ajouts / modifications d évènements, gestion de plusieurs calendriers, internationalisé, bref, qui correspondait tout à fait à nos besoins, à quelques personnalisation près. Un Calendrier Ext.ensible suit le même fonctionnement que celui décrit dans le paragraphe précédent. L interface graphique repose sur deux Stores: un EventStore qui stocke les évènements affichés sur le calendrier, et un CalendarStore, qui stocke un ensemble d agendas, pouvant être affichés ou masqués sur l interface. Un évènement possède donc des dates/heures de début et de fin, un titre et une description. On peut lui associer certaines propriétés: appartenance à un agenda en particulier, durée sur toute une journée (ou plus- 13

ieurs jours), récurrence selon un schéma précis, rappel... Ces champs sont personnalisables: on peut en ajouter, ou modifier les noms de ceux existants. Figure 6. Calendrier basique, avec les options par défaut et un jeu d essai Les données peuvent aussi bien être récupérées sur un serveur distant (via requête AJAX et architecture REST) qu instanciées directement dans le script. C est bien sûr cette première façon de faire qui sera utilisée dans notre cas. Le drag n drop est utilisable pour ajouter des évènements: on clique à l heure de début et on fait glisser jusqu à l heure de fin. D une façon générale, l interface et l ergonomie rappellent beaucoup Google Agenda, la référence en matière de calendriers en ligne. Figure 7. Aperçu de notre interface 14

c. Travail réalisé L interface actuelle repose sur un Ext.Viewport. Il s agit d une fenêtre prenant tout l espace disponible, et permettant donc d organiser le navigateur comme un vrai programme de bureau (voir figure 7). Figure 8. Fenêtre d ajout d évènement A gauche, une liste des domaines existant s affiche sous forme d arbre. Un clic droit dessus entraine l affichage d un menu contextuel permettant l ajout, la modification, et la suppression de domaines. Il a fallu distinguer l ajout d un sous-domaine de l ajout d un nouveau domaine racine: cette distinction se fait sur l emplacement du clic-droit. Le formulaire d ajout/modification qui s ouvre alors est une fenêtre modale (Ext. Windows) contenant un simple formulaire ExtJS (Ext.form.FormPanel). Au centre et à droite de l écran se trouve le calendrier, outil principal du logiciel, dont on a déjà parlé précédemment. Les caractéristiques des différentes vues ont été modifiées pour être plus appropriées à l utilisation de notre application. Ainsi, les journées vont de 8h00 à 19h30, et plus de 00h00 à 23h59, avec une unité de temps de 15 minutes et non plus de 30 minutes. De même, seuls apparaissent les jours travaillés. Figure 9. Menu contextuel Le concept original d agendas a été repris, et au lieu d associer un agenda à un évènement, on va lui associer un domaine. Seul le nom change, et la façon de les associer, mais la structure reste inchangée. La sémantique est modifiée, mais l implémentation reste quasiment la même. On peut ainsi faire apparaitre sur le calendrier les évènements d une même matière avec une couleur particulière, n afficher que ceux là, ou encore les exclure. D autres modifications légères ont été faites pour adapter les entrées / sorties à nos formats de données. Les échanges se font via des chaînes JSON (format de sérialisation JavaScript) et il a parfois été nécessaire de changer le nom de certains attributs. Cette partie du travail a été facilitée par les options de mapping offertes par ExtJs et par l extension utilisée. 15

Partie Dernière : Apprentissages, leçons tirées, expériences acquises Au début de ce projet, nous avions des envies et des attentes. Certaines ont été satisfaites, d autre ont changées, mais nous avons dans tout les cas appris des choses et tiré des leçons de cette expérience. Nous allons vous expliquer ce que nous retenons, d abord d une façon générale, puis de façon particulière pour chacun de nous. 1. L ennemi n 1: le temps Un projet informatique, et d autant plus un projet universitaire, souffre toujours des mêmes maux: problèmes de temps, de concentration, de compétences. Si pour ces derniers nous avons matières à apprendre (et c était d ailleurs le but), les autres projets scolaires et professionnels nous ont empêcher de consacrer autant de temps que nous aurions voulu à ce travail. Nous avons la chance de souvent travailler ensemble, ce qui a facilité notre coordination, notre communication et donc la gestion des avancées de chacun. Néanmoins, la planification est toujours un exercice difficile, surtout quant on ne peux pas savoir à l avance combien de temps par jour ou par semaine on pourra consacrer au projet. C est pourquoi la répartition des tâches n a peut être pas été adroite. Nous avions découper le projet en deux parties puisque nous étions deux développeurs. L un devait s occuper de la partie client, l autre de la partie serveur. Au début, les maquettes avançèrent beaucoup plus vite que le code serveur, mais au final, c est du côté client que la charge du travail fut la plus importante, entre autre à cause du changement de dernière minute de framework JavaScript. La communication est donc essentielle, aussi bien quand on avance que quand on est en difficulte. La précision est impérative lorsque son définit les interfaces à utilisé: par exemple, ExtJS attend en entrée des dates dans un certain format, qui n est pas celui par défaut sérialisé par Java. Il faut donc préciser le moindre détail. L expérience joue un rôle déterminant dans ce travail. 2. Apprentissages techniques et difficultés particulières Pour Céline, ce projet fut l occasion d acquérir des compétences dans les technologies de présentation du Web: CSS, JavaScript, et d apprendre l utilisation de deux framework: ExtJs et jquery. Ses principales difficultés furent de se concentrer sur l objectif principal (minimum fonctionnel) et pas sur toute les améliorations possibles, ainsi que de s adapter au changement de framework. La prépondérance de l anglais dans la documentation n a pas facilité ses recherche. Pierre put quant à lui renforcer ses notions de programmation Java, et notamment découvrir le framework Spring et ses capacités. Pensant d abord pouvoir travailler sans difficulté grâce à cela, il se rendit rapidement compte qu il fallait encore faire attention à énormément de choses, souvent des détails, et que les causes d erreurs possibles sont très nombreuses quelque soit la technologie utilisée. Ce fut aussi l occasion d installer et d utiliser une forge logicielle pour la première fois: un outil très pratique, mais délicat à configurer et à mettre en route. 16

Conclusion Ce projet majeur dans notre année universitaire nous a permis de découvrir de nouvelles technologies et de nouvelles pratiques en matière de programmation Web, notre domaine d études privilégié. Il nous a permis de confirmer notre intérêt pour ce secteur et nous a conforté dans nos choix de poursuite de cursus universitaire. Travailler avec un de nos enseignant nous a donné un aperçu de méthodes de travail différentes de celles que nous avions déjà expérimenté, et a amélioré notre connaissance des techniques de développement. Son accompagnement dans la découverte de Spring, entre autre, a été une aide précieuse. Pour finir, nous aurions aimé que les autres projets universitaires nous laisse plus de temps pour apporter un maximum de fonctionnalités à cette application qui nous parait utile et nécessaire. Nous espérons que des équipes des prochaines années pourront reprendre le travail là où nous l avons laissé et mener à terme le développement de ce programme. 17

Table des matières Introduction 2 Partie Première : la spécification du projet 3 1. Recueil des besoins et spécifications fonctionnelles 3 2. Etat de l art 4 3. Estimation des coûts 4 4. Technologies mises en œuvre 4 Partie Seconde : le développement du projet 6 1. Se former 6 2. Concevoir les maquettes 6 3. Environnement de développement 7 4. Développer côté serveur 8 5. Développer côté client 12 Partie Dernière : Apprentissages, leçons tirées, expériences acquises 16 1. L ennemi n 1: le temps 16 2. Apprentissages techniques et difficultés particulières 16 Conclusion 17 18

Table des figures Figure 1.Exemple de maquette sur papier 6 Figure 2. L architecture MVC 2 de Spring MVC (image tirée de la documentation officielle) 9 Figure 3. L architecture de l application 10 Listing 1. Exemple de méthode d un contrôleur 10 Figure 4. Fonctionnement schématique d une méthode de contrôleur 11 Listing 2. Exemple de méthode d un contrôleur 12 Figure 5. Fonctionnement des widgets ExtJS 13 Figure 6. Calendrier basique, avec les options par défaut et un jeu d essai 14 Figure 7. Aperçu de notre interface 14 Figure 8. Fenêtre d ajout d évènement 15 Figure 9. Menu contextuel 15 19

Documentations officielles Bibliographie Spring Framework 3.0 Documentation Reference http://static.springsource.org/spring/docs/3.1.0.m1/spring-framework-reference/html/ JQuery API Reference http://docs.jquery.com/main_page ExtJS API Documentation http://dev.sencha.com/deploy/ext-3.3.1/docs/ Ext.ensible Calendar API Docs & Samples http://ext.ensible.com/products/calendar/ Ouvrages divers Spring in Action, Craig Walls, éditions Mannings Test Driven Development: By Example de Kent Beck, éditions Pearson Eduction Java Persistence and Hibernate de Anthony Patricio, éditions Eyrolles CSS - Le guide complet, de Fabien Basmaison et Antoine Cailliau, éditions Micro Application. jquery de Jonathan Chaffer et Karl Swedberg, éditions Pearson Eduction Tutoriaux, aide, Foires Aux Questions Ajax Simplifications in Spring 3.0 http://blog.springsource.com/2010/01/25/ajax-simplifications-in-spring-3-0/ MVC Simplifications in Spring 3.0 http://blog.springsource.com/2009/12/21/mvc-simplifications-in-spring-3-0/ FAQ Spring - Developpez.com http://spring.developpez.com/faq/ Tutoriel CSS sur HTML.net http://fr.html.net/tutorials/css/ Tutoriel jquery sur BabylonDesign http://babylon-design.com/apprendre-et-comprendre-jquery-1-3/ 20