Conception d’Application Informatique
Logiciel de gestion d’emploi du temps
Céline HENRY COMBES et Pierre LUCE
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, Profes- seur à 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
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 appli- cation : le recueil des besoins, la spécification fonctionnelle, l’état de l’art, l’estimation des coûts. Nous expliquer- ons 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ével- oppeurs 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 com- pré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 enseigne- ments 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ène- ments 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 organisa- tion 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 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 perfor- mant. Ils prennent en comptes les cours des étudiants, les disponibilités des professeurs, la cohérence de la suc- cession 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érale- ment 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 particu- lier 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évision- nel. 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 :
» 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éveloppe- ment. 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.
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 par- fois en parallèle : la formation sur les technologies utilisées, le maquettage des interfaces graphiques, le dével- oppement 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 principale- ment ê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
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 automa- tiquement 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.
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 rassem- blé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 supprim- ant 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
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.
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, Con- trô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.
“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 applica- tion.
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
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 annota- tions Java plutôt que sur des fichiers XML. Le Listing 1 donne un exemple de 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 applica- tion 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).
@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
Figure 3. L’architecture de l’application
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é sup- plé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.
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 re- tourné 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
Figure 4. Fonctionnement schématique d’une méthode de contrôleur
» AccueilController : page d’accueil, point d’entrée de l’application
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.
@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());
}
// Retour de l’objet réponse return hm;
} /**/
}
Listing 2. Exemple de méthode d’un contrôleur
Deux technologies JavaScript se sont succédé. Le début du travail a été fait autour de JQuery, qui fut en- suite 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, er- gonomiques et professionnelles dans un navigateur web : formulaires, grilles de données, fenêtres… La dern- iè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 don- nées sur un serveur, ou envoyer les requêtes pour les modifier.
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, Figure 5. Fonctionnement des widgets ExtJS
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.
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 6. Calendrier basique, avec les options par défaut et un jeu d’essai
Figure 7. Aperçu de notre interface
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).
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 fal- lu 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.
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.
Figure 8. Fenêtre d’ajout d’évènement
Figure 9. Menu contextuel
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: prob- lè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 com- munication 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 possi- bles, 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 frame- work Spring et ses capacités. Pensant d’abord pouvoir travailler sans difficulté grâce à cela, il se rendit rapide- ment 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.
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 universi- taire.
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 ac- compagnement 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ével- oppement de ce programme.
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
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
Bibliographie
Documentations officielles
» 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/
