1.Choix technologiques

Transcription

1 Table des matières Introduction Choix technologiques... 4 Le choix des EJB Cahier des charges Portail LMD Les acteurs Les objets métiers Cas d'usage Diagramme simplifié Développement Application répartie : les EJB Vue générale Relations entre les objets Persistance La génération des identificateurs La génération des mots clés La communication entre les objets Le lien avec l'interface client Façade Struts Rémanence XML XSLT JSP Site internet Tests Comment L'intéret des tests Retrospective Gestion du travail de groupe Division du travail Communication Synthèse de travaux Problèmes rencontrés Problèmes liés au code Problèmes du côté EJB Problèmes du côté Façade Problèmes liés aux technologies de sécurité Problèmes liés à la communication Divergences dans les noms et types d'attributs Divergences dans la structure du projet Problèmes liés au diagramme UML Problèmes liés au temps Conclusion Annexe - L'eXtreme programming Annexe - Création d'un EJB CMP...30 Annexe - Façade Annexe - Schéma UML Annexe - Authentification et Sécurité

2 Introduction Dans le cadre de la première année de Master informatique, les étudiants sont amenés à réaliser un projet en groupe de treize à dix-huit personnes. Ainsi, ils apprennent à travailler en équipe, à partager et gérer leurs ressources, à assumer les responsabilités liées à un tel projet et à faire preuve d indépendance décisionnelle. Tout ceci leurs permet de se rendre compte de l ampleur d un tel projet et de la nécessité d une bonne organisation. Le sujet du projet J2EE-LMD est la création d'un portail web permettant de consulter toutes sortes d'informations relatives à l'ensemble des formations proposées dans les universités françaises au niveau du LMD. Mais le but du projet est avant tout de développer une application répartie beaucoup plus complète que l'habituel site internet en HTML. Entre autre, notre application est très évolutive, c'est à dire que l'on peut aisément y ajouter des composantes. De plus le site est géré dynamiquement et donc mis à jour instantanément à chaque modification. Il permet également une montée en charge très conséquente, c'est à dire qu'il peut supporter un nombre d'utilisateurs simultanés très important. Enfin, il permet la gestion de différents types d'utilisateurs et de droits d'accès. C'est pourquoi nous utilisons pour ce projet la technologie J2EE. En effet, celle-ci apporte la possibilité de travailler en groupe selon un schéma horizontal : le développement des différentes actions possibles se fait en couches (ex : gestion de personnes, de contacts...) développées en parallèle, ce qui permet à une couche terminée d'être testée seule avant d'être ajoutée à l'ensemble des couches déjà testées. J2EE offre également l'avantage de faire évoluer le portail plus facilement sans pour autant devoir modifier l'existant. Ceci grâce au fait qu'elle permet la programmation du portail sous forme de modules indépendants. Pour mener à bien un tel projet, une bonne organisation est nécessaire. Ainsi le premier semestre a été entièrement consacré à la partie analyse du projet et le deuxième semestre réservé au développement. Bien que ce rapport ne concerne que la partie développement, il est nécessaire d'évoquer brièvement le travail déjà effectué pendant la phase d'analyse du premier semestre. L'analyse du projet nous a tout d'abord permis de définir les outils à utiliser. Outre l'utilisation de J2EE imposée par l'intitulé du sujet, ces outils ont été retenus pour leur adéquation aux objectifs du projet : entre autre, nous les avons retenus pour leur portabilité, leur facilité d'utilisation ainsi que leur gratuité. L'analyse nous a ensuite amenés à définir l'architecture de notre application : à partir des différents modules identifiés, nous avons organisé la répartition des membres du projet en sous-groupes pour la partie développement. L'objectif de la phase de développement est de mettre en oeuvre les spécifications fonctionnelles bâties lors de la phase d'analyse. Nous verrons dans un premier temps les choix technologiques imposés par le sujet, dans un deuxième temps le cahier des charges établi pour notre application. Ensuite nous verrons la partie développement et les tests effectués. Enfin, nous finirons par une retrospective de notre travail de groupe, et des problèmes rencontrés. 2

3 1.Choix technologiques La conception d'un système d'informations est une problématique très complexe. Il faut traiter à la fois l'accès, le traitement et la présentation des données à l'utilisateur final, ainsi que beaucoup d'autres détails tels que la gestion des transactions et la sécurité de l'application. Afin de maîtriser sa conception, et plus tard son évolutivité, nous avons tout intérêt à concevoir un système d'informations sous forme de couches, où chaque couche a une responsabilité précise. Ces couches sont logicielles. L'architecture classique est une architecture à trois couches : la couche présentation contient des composants qui réalisent l'interface graphique de l'application et gèrent les interactions avec l'utilisateur. la couche métier, coeur de l'application, contient des composants qui collaborent entre eux. la couche données est utilisée par la couche métier pour enregistrer les différentes données. Exemple d'application : requête Couche présentation Navigateur Couche métier Couche données réponse client La technologie J2EE (Java 2 Enterprise Edition) permet ce découpage en couches logiques. Celui-ci ne préjuge en aucune manière de la localisation physique des composants constituants chacune de ces couches. En particulier, ces composants peuvent être répartis sur plusieurs serveurs d'application, les serveurs ainsi impliqués pouvant eux-mêmes être regroupés ou distribués sur une ou plusieurs machines constituant l'ensemble de la plateforme d'exécution. Les composants JSP sont un des composants majeurs de la couche présentation. Les EJB sont des composants dédiés à la couche métier et attachés à la couche données lorsqu'ils sont persistants. 3

4 Le choix des EJB Même s'il est possible de se passer des EJB, ceux-ci représentent des avantages certains. Le premier d'entre eux est la possibilité de mettre en oeuvre des architectures complexes où la partie présentation et la partie métier sont physiquement séparées. Le serveur d'applications rend alors de nombreux services en prenant à sa charge les communications réseaux, les transactions distribuées, la sécurité, la répartition de charge et les optimisations possible en mutualisant les ressources (gestion de pool). Le deuxième avantage réside dans la normalisation du modèle de composants EJB. Ainsi, les EJB peuvent être déployés sur tout serveur J2EE. 2. Cahier des charges Il s'agit de connaître quelles orientations donner au projet d'un point de vue développement. C'est pourquoi l'établissement d'un cahier des charges complet a été important. 2.1.Portail LMD Le projet J2EE-LMD consiste en la création d'un portail d'accès à l'offre de formation d'un ensemble d'universités. En effet, dans le cadre de la réforme LMD, les universités ont besoin d'une centralisation de leurs données pour une représentation plus claire de leurs formations afin de bien s'adapter au nouveau système imposé. Ainsi, il est par exemple possible, à l'aide de l'application finale, de créer des formations constituées de «ressources», c'est à dire de matières (exemple : cours de compilation). Les divers parcours des universités sont alors consultables. Pour pouvoir réaliser ce genre d'actions avec l'application finale, nous avions besoin de définir un certain nombre d'objets-métiers principaux qui nous servent à représenter nos grandes entités Les acteurs Il convient aussi de définir différents types d'utilisateurs ayant accès à cette application. Ainsi nous avons : les visiteurs, ils ne font que des recherches et des consultations les enseignants, ils ont les mêmes droits que les visiteurs plus la possibilité de créer et modifier des ressources les administrateurs, ils ont tous les droits, c'est à dire qu'ils peuvent créer, modifier mais aussi supprimer des ressources. 4

5 2.1.2.Les objets métiers Pour présenter aux lecteurs les informations sur la réforme LMD, il est nécessaire d'avoir des objets-métiers correspondant aux universités, aux UFRs qu'elles regroupent, à leurs adresses et villes associées. Tout ce groupement d'objets nous a permis de traduire l'aspect «universités» de notre application. En particulier, nous avons choisi d'avoir : des personnes symbolisant les différents utilisateurs de notre application des matières correspondant aux matières enseignées des universités regroupant des matières (et ressources associées) au sein de formations ainsi que toutes les informations associées des sections/niveaux hiérarchisant l'offre de formation de l'université concernée et enfin des questions/faq qui sont le résultat du classement de nos données afin de pouvoir y faire des recherches. De manière plus détaillée, les objets-métiers matières, sections et niveaux associés constituent les disciplines présentes par formations, niveaux ou sections. Les matières et niveaux sont reliés au sein des unités d'enseignements. Pour chaque matière, il y a aussi un certain nombre de ressources pédagogiques associées. Enfin, en ce qui concerne les UFRs et disciplines enseignées en leur sein, des mots-clés sont associés à ces derniers objets-métiers, sauf pour les sections. Ces mots-clés ne sont ni obligatoires ni limités en nombre mais fort utiles pour les recherches «en interne de l'application». Les questions et FAQ qu'elles constituent servent à aider le visiteur perdu ou demandeur d'une quelconque assistance au sein de notre portail web. Enfin, avec les différents types d'utilisateurs qui peuvent consulter notre portail web, il est important de savoir si la personne est un simple visiteur ou un utilisateur avec des droits. Il convient donc de les représenter par des entités personnes parmi lesquelles nous avons des administrateurs et des professeurs dotés de plus de pouvoir. Ce sont nos derniers objets-métiers mais pas les moindres car ils permettent de gérer les droits des utilisateurs en fonction de leur identification Cas d'usage Le client définit tout au long du développement différents scénarios qui représentent ce qu'il attend concrètement de l'application. Nous allons détailler quelques cas d'usages qui représentent des actions générales réalisables sur l'application finale. Ainsi il est possible de faire: Consultation : Cette opération est permise à tous. La consultation consiste à choisir une catégorie d'objets et à demander l'affichage partiel ou total de son contenu au niveau de la base de données sur laquelle repose notre application. 5

6 Ajout : Cette opération n'est permise qu'à un administrateur, seul habilité à faire ce genre de tâches (excepté l'ajout de ressources pédagogique qui est également faisable par un professeur). Plus particulièrement, nous créons une personne «lambda» et analysons le résultat obtenu pour voir si cela correspond bien à ce que nous voulons. Une ou plusieurs consultations sont également intégrées à ce cas d'usage pour visualiser le contenu modifié afin de vérifier que tout fonctionne bien. 6

7 Modification : Là aussi, seuls les administrateurs, ou éventuellement les enseignants, peuvent le faire. En particulier, nous reprenons une personne déjà existante afin de lui apporter des modifications. Ensuite nous contrôlons que tout fonctionne bien par le biais d'une consultation. Recherche : Notre dernier cas d'usage concerne des recherches diverses au sein des ressources ou formations présentées par notre application. Nous pouvons ainsi vérifier que toutes les parties de notre application sont bien articulées et «communiquent» bien entre elles afin de modéliser le fonctionnement global de cette dernière. En effet, une recherche nécessite que toutes les informations soient bien enregistrées par notre application et soient exploitables. 7

8 2.2.Diagramme simplifié Après notre analyse, nous avons déterminé que le principe général de notre application peut, d'une manière un peu simplifiée, se résumer par le schéma suivant : 8

9 Ces groupes d'objets sont les principaux. Ce sont les grands objets-métiers que nous avons retenus. Nous avons tenté de les implémenter par des EJB. Ces composants offrent tous les avantages au niveau persistance, sécurité d'accès aux données... tout en ne présentant que très peu de code effectif. C'est tout l'intérêt du J2EE avec ses EJB si utiles et pourtant si obscurs dans un premier temps. Mais cela sera approfondi dans la partie suivante. 3. Développement Lors du développement de notre application, deux axes importants de développement ont été soulevés : celui concernant le serveur d'application, et celui concernant la façade, c'est à dire l'interface client. 3.1.Application répartie : les EJB La partie EJB (Entreprise Java Bean) concerne la partie logique métiers de notre portail web. On précise que ce portail fonctionne sur un serveur JBoss selon les spécifications J2EE (Java 2 Enterprise Edition) de SUN. J2EE est une plate-forme de développement qui nous permet de développer notre application web composée de servlets, JSP et composants métiers à base d'ejb. C'est également une spécification destinée aux éditeurs de logiciels qui désirent créer des serveurs d'applications compatibles J2EE. Un serveur d'application contient un conteneur Web pour l'exécution des applications Web et un conteneur d'ejb pour l'exécution des composants métiers (services détaillés en annexe du dossier de spécifications). Seul le conteneur d'ejb nous intéresse dans cette partie, c'est lui qui nous fournit l'environnement d'exécution des EJB, en leur fournissant des services tels que les transactions ou la persistance. L'un des intérêts principaux de J2EE est la gestion des différents services par le conteneur : le développeur ne s'occupe plus de la gestion des services tels que la persistance (dans une base de données par exemple), la sécurité ou encore les transactions Vue générale Chaque entité du schéma UML1 est représentée par un EJB de type CMP (Contenair Managed Persistance), c'est à dire des objets aux données persistantes sur le serveur et dont la persistance elle-même est gérée par le conteneur. Nous appelons ceux-ci des EJB entity ou encore entity bean. Nous pourrions par exemple les utiliser pour représenter un compte bancaire : celui-ci garde en mémoire le solde, les historiques et les autres services éventuels (points, adresses, numéro de comptes...). 1 Voir Annexe 9

10 L'ensemble de ces entity beans est manipulé par un ou plusieurs EJB que nous appelons EJB session. Comme son nom l'indique, celui-ci n'est pas persistant et possède un durée de vie égale à celle d'une session. Par exemple, nous pourrions représenter un bean session par une action sur le compte bancaire (retrait d'argent, suppression d'un compte..). Compte banquaire Dépot d'argent Client Entity Retrait d'argent Session Entity Session Entity B D Client Client Demande d'achat Panier Enfin, le client (côté façade du portail) manipule les fonctions du session bean, ce dernier jouant le rôle de façade vers les entity beans Relations entre les objets Les relations entre les entités (voir schéma UML) sont gérées de deux manières : Premièrement, un identificateur unique (clé primaire) est utilisé pour lier deux objets. Par exemple, la relation (1-1..*) entre une ville et une adresse est réalisée à l'aide du code insee. Ainsi, chaque ville a un code insee unique et chaque adresse possède un code insee correspondant à la ville. Un objet intermédiaire est utilisé pour lier deux objets. Par exemple, dans une foire aux questions (FAQ) chaque question fait partie d'un thème. L'objet QuestionsDeTheme permet de relier les objets Question et Thème à l'aide des références aux identificateurs questionid et themeid. Deuxièmement, des scripts SQL avec des contraintes d'intégrités entre les différents paramètres ont été créés pour ajouter des contraintes entre les objets (commande CONSTRAINT en SQL). Par exemple, dans le cas d'une FAQ (Foire Aux Questions), on précise une contrainte d'intégrité dans ThemeDeFAQ sur themeid pour la relation avec Theme, et sur faqid pour la relation avec FAQ. L'objet ThemeDeFAQ peut donc être créé seulement si les objets Theme et FAQ correspondants existent. CREATE TABLE FAQ( FAQID VARCHAR(255) NOT NULL PRIMARY KEY, NOMFAQ VARCHAR(250), CONSTRAINT CONST_FAQ_UNU UNIQUE(FAQID)) 10

11 CREATE TABLE THEME( THEMEID VARCHAR(255) NOT NULL PRIMARY KEY, NOMTHEME VARCHAR(250), CONSTRAINT CONST_THEME_UNU UNIQUE(THEMEID)) CREATE TABLE THEMEDEFAQ( THEMEDEFAQID VARCHAR(255) NOT NULL PRIMARY KEY,THEMEID VARCHAR(255), FAQID VARCHAR(255), CONSTRAINT CONST_THEMEDEFAQ1 FOREIGN KEY(THEMEID) REFERENCES THEME(THEMEID) ON DELETE CASCADE, CONSTRAINT CONST_THEMEDEFAQ2 FOREIGN KEY(FAQID) REFERENCES FAQ(FAQID) ON DELETE CASCADE ) Ces contraintes permettent aussi la suppression implicite des relations : par exemple, lorsque la FAQ est supprimée les éléments ayant une contrainte d'intégrité sur celle-ci sont également supprimés Persistance Comme nous l'avons dit plus haut, la persistance est gérée par le conteneur (environnement d'exécution des EJB). Cette abstraction supplémentaire nous permet de manipuler des objets persistants sans pour autant nous soucier de la mise en oeuvre. Le conteneur associe chaque entity bean avec une table dans la base de données. A chaque paramètre d'un objet est associé un champ dans la table. Par exemple, l'objet FAQ (avec les paramètres faqid et nomfaq) est représenté dans la base de données par une table "FAQ" avec deux champs : faqid et nomfaq. La manipulation des entity beans est donc implicitement celle des tables dans la base de données associées à ces objets. mybean.remove();//suppression de l'objet mais aussi, implicitement, de la ligne correspondante dans la table mybean.create();//création de l'objet ainsi que de la ligne associée dans la table de la base de données Les recherches d'objets sont réalisées de la même façon : le conteneur gère les requête SQL indiquées dans l'entity bean et rend les objets associés La génération des identificateurs La persistance, à l'aide d'une base de données, suppose une clé primaire dans chaque table. Dans certains cas, la clé primaire est contenue dans les données (champ insee de Ville : le code insee est unique pour chaque ville) mais dans d'autre cas, nous nous retrouvons avec des doublons si nous n'ajoutons pas une colonne supplémentaire faisant office de clé primaire. Ainsi, nous avons introduit une table d'identificateurs qui contient toutes les clés primaires artificielles et qui fait 11

12 office de compteur : lors d'un ajout d'une clé primaire, nous cherchons dans le champ le compteur de clé primaire associé à l'ejb, nous l'extrayons et l'incrémentons. L'entier extrait est préfixé par le sigle de l'ejb (par convention) et est utilisé comme clé primaire. Par exemple, pour ajouter une FAQ, nous allons chercher l'entier dans le champs FAQ de la table Identificateur, nous l'incrémentons puis l'utilisons comme clé primaire de la FAQ ainsi créée dans la table FAQ (La clé sera du type FAQ4587 si l'entier extrait est 4586) La génération des mots clés Si nous supposons que nous avons un portail de dimension honnête, il faut que nous puissions retrouver facilement des informations sur tel thème, ou telle personne. Nous avons introduit pour cela la notion de mots clés : lors de la création d'une question ou d'un thème dans la FAQ, d'une UE, d'une matière.., nous mémorisons les informations importantes sous forme de chaîne de caractères à l'aide d'un entity bean MotsCle. Les recherches sur le portail sont donc majoritairement des recherches sur le champ nom de la table MotCle. Nous retrouvons le contexte du mot clé à l'aide de l'identificateur motcleid dans les diverses tables intermédiaires telles que MotsClesDeQuestion, MotsCleDeNiveau, MotsCleDeUE... L'avantage de cette forme est sa facilité d'ajout de mots clés de nouvelles catégories. Nous pouvons ainsi aisément rajouter d'autres critères de recherches sans pour autant toucher à la structure existante La communication entre les objets Au sein du serveur, les EJB ne sont pas disponibles de la même façon : soit l'objet est local au conteneur, c'est à dire que seuls les autres objets du conteneur y ont accès. soit l'objet est disponible sur tout le serveur et le client, via des méthodes distantes (attribut remote). Chaque objet possède une ou deux interfaces permettant un accès local (et distant). Elles contiennent les méthodes de création, destruction et recherche. Ces interfaces sont donc sollicitées à chaque communication avec d'autres objets. Un client aura donc accès seulement aux méthodes des objets déclarés comme distants Le lien avec l'interface client Ce portail est construit selon l'architecture 3-tiers. Cela suggère sa division en plusieurs parties pour permettre un niveau d'abstraction plus élevé. Trois parties se distinguent : - La façade qui constitue l'interface Web permettant aux clients d'interagir avec le côté applicatif - La partie métier, composé du serveur d'ejb (partie applicative du projet) - La base de données qui correspond à la persistance des données. 12

13 Comme nous l'avons dit précédemment, la façade a accès aux méthodes métiers (méthodes des EJB) à l'aide d'interfaces distantes. Ces méthodes permettent d'échanger des informations, la plupart du temps de type chaîne de caractères. Mais, étant donné que chaque méthode peut rendre des informations multiples (ex: nom, prénom, adresse.. pour la méthode chercher personne), chaque entity bean possède une classe supplémentaire permettant d'encapsuler un ensemble d'informations. Ces classes sont suffixées par Data (ex: personnedata). Par exemple, l'échange d'adresses se fait à l'aide de la classe adressedata qui encapsule les données adresseid, rue, numéro, codeinsee. 3.2.Façade Notre projet étant un portail d'informations, il était nécessaire de développer des formulaires de saisie, ainsi qu'une interface WEB permettant aux clients d'interagir avec notre serveur d'application Struts Concernant les formulaires de saisie, notre choix initial était les formulaires JSP Struts et il a été retenu. Struts est un environnement de base (on parle aussi de squelette) qui induit un modèle de programmation robuste et qui offre une architecture et des outils pour le développement rapide de sites Web professionnels. L'étape suivante consistait à faire la liaison entre ces formulaires et le parseur XML, c'est à dire sauvegarder les informations rentrées via le formulaire dans des fichiers XML Rémanence XML L'un des premiers buts de notre projet est d'utiliser une rémanence2 en XML. Nous avons donc appris à utiliser les «parsers» ou «serialiseurs» XML qui permettent de récupérer des informations dans un Bean et de les sauvegarder dans un fichier XML. Notre choix s'est porté sur DOM4j. Celui-ci représente l'information sous forme d'arbre de type «dom4j.document». Nous créons un nœud «père» correspondant à l'identifiant de l'objet métier dont les «fils» correspondent aux attributs de cet objet. Ainsi en ajoutant ce nœud dans l'arbre obtenu par relecture du fichier XML précédemment créé, nous obtenons l'arbre complet représentant toutes les informations saisies jusqu'à présent. Ensuite nous créons sur le disque dur un fichier XML correspondant au modèle de document de DOM4j dans lequel nous écrivons notre arbre. 2 La rémanence est le temps que reste une donnée en mémoire après utilisation 13

14 UE3 SGM UE1 MFGL 40 UE2 35 REPR UE3 40 SGM 40 Cette rémanence nous a servi à «simuler» notre base de données lorsque nous développions la façade alors que les EJB étaient en cours de développement. Ainsi, le développement de la façade et des EJB étaient complètement indépendants, la façade travaillant sur des fichiers XML, et les EJB sur la vraie base de données. Biensûr, lorsque la liaison entre la façade et les EJB a été réalisée, notre rémanence XML a été remplacée par l'utilisation des fonctions de gestion de la base via les EJB (cela n'était de toute façon pas réaliste d'uiliser des fichiers XML car nous ne pouvions les protéger des problèmes d'accès concurrents entre utilisateurs différents). Néanmoins, nous avons conservé l'utilisation des fichiers XML pour les formulaires de recherche afin que l'ensemble des réponses trouvées dans la base de données soient centralisées dans un seul fichier permettant l'affichage des réponses par traitement XSLT XSLT Nous avons décidé d'utiliser un rendu HTML et PDF pour nos documents destinés aux visiteurs du portail. Nous avons donc utilisé les feuilles de style XSLT qui permettent d'obtenir ces rendus. Ces feuilles parcourent les fichiers XML générés au préalable à l'aide de DOM4j et récupèrent toutes les données afin de les représenter dans un tableau. Ainsi on peut afficher par exemple une personne recherchée mais aussi toutes les personnes présentes dans la formation. Ces feuilles de style sont propres à chaque objet car elles créent un tableau dont les colonnes sont les valeurs des attributs de chaque objet. 14

15 3.2.4.JSP Une page JSP est un texte mélangeant du HTML et du code JAVA, qui va être interprété par le navigateur Web du client comme une page HTML classique. Une page JSP est accompagnée sur le serveur Web d'une Servlet, qui est l'objet résultant de la compilation du code JAVA de la JSP. L'utilisation de pages JSP permet de créer des pages HTML dynamiques qui ont la possibilité de faire des appels aux EJB et d'afficher les champs et les données différemment en fonction de leurs réponses. Notre portail propose plusieurs possibilités à l'administrateur du site. Celui-ci peut rentrer des informations concernant les formations, les modifier ou bien les supprimer. De plus, les visiteurs ont la possibilité de consulter toutes ces informations et d'effectuer des recherches sur le portail. Nous avons donc dû modifier notre formulaire Struts afin qu'il permette de réaliser plusieurs actions par Bean (par exemple : Ajout/Modification/Supression). De même nous avons modifié nos formulaires JSP basiques de Struts afin de permettre ces actions aux utilisateurs, c'est à dire ajouté tous les boutons correspondants et toutes les actions appelées par ceux-ci dans nos classes Site internet Le site internet est la partie visible de l'application. Il permet aux visiteurs de s'informer sur les formations dispensées à l'université de Rennes1 (pour notre démonstration) et aux enseignants de renseigner leurs formations. Pour cela, le site se doit d'être clair, grâce à une esthétique simple, mais suffisamment plaisante pour ne pas rebuter lors de son utilisation. Pour construire le design de base, nous avons utilisé Dreamweaver, pour lequel quelques licences sont disponibles à l'ifsic. C'est un puissant outil d'édition de pages web. La technologie CSS (Cascading Style Sheets : feuilles de style en cascade) a été massivement employée. CSS est principalement utilisée pour définir les couleurs, les polices, le rendu, et d'autres caractéristiques d'un document, et a été créée pour effectuer la séparation entre la structure éditée en HTML, et la présentation (en CSS). Cette séparation fournit un certain nombre de bénéfices, permettant d'améliorer l'accessibilité, de changer plus facilement de structure et de présentation, et de réduire la complexité de l'architecture d'un site web. 15

16 Ainsi, les avantages des feuilles de style sont multiples : - La structure des pages et la présentation sont gérées dans des fichiers séparés. - La conception des pages se fait dans un premier temps sans se soucier de la présentation, ce qui permet d'être plus efficace. - La présentation est uniformisée : les pages HTML font référence à la même feuille de style. Cette caractéristique permet de plus une refonte plus rapide du design. De ce fait, le code HTML est considérablement réduit en taille et en complexité, puisqu'il ne contient plus de balise de présentation. Les CSS nous permettent donc d'obtenir un site plus homogène où toutes les informations de mise en page sont centralisées. Mais il a fallu pousser encore plus loin la dissociation de l'aspect graphique et du contenu. Il serait inutile de retrouver sur toutes les pages le code des différents menus, des images 'logo' etc d'autant plus qu'une modification obligerait à retoucher toutes ces pages. Il a donc été mis en place un système permettant l' inclusion de pages, grâce à la technologie JSP. C'est à dire qu'il n'existe qu'une seule page comportant l'aspect visuel du site (facilité de mise à jour) et dans laquelle se trouve une référence à une autre page (passée en paramètre) qui viendra s'inclure à l'intérieur de celle-ci, ces pages insérées étant principalement des formulaires ou des résultats de requêtes. 16

17 Formulaire Struts ou page de résultat, inséré dans la façade. La feulle de style est héritée. Fichier unique et commun à toutes les pages, comportant entre autre des balises <div> dans lesquels est inséré du code HTML, ainsi que des insertions en jsp d'informations relatives au formulaire à afficher. Formulaire.jsp Facade.jsp J2EE.css Fichier de rassemblement spécifique à chaque formulaire. Paramètres Feuille de style unique et commune à toutes les pages. Déclaration de mise en forme des balises <div> (emplacement, police, taille, couleur...) i_formulaire.jsp Liens.. Déroulement d'un appel à une page. 4. Tests Le test est une étape importante du développement d'un projet. Nous inspirant de la méthode extreme programming, nous avons, pour chaque scénario planifié, écrit un ensemble de tests de recette. Ces tests ont pour but de vérifier de manière automatique chacune des fonctionnalités demandée par le client. L'architecture de notre application nous apporte la possibilité de travailler en binômes selon un schéma horizontal : le développement des actions possibles se fait en couches. Les différents modules ont donc été développés en parallèle par les binômes et subissaient des tests unitaires élaborés avant le développement du nouveau «composant». L'intégration des différents modules a été progressive, nous avons pu avoir assez rapidement un rendu fonctionnel. En effet, dès lors qu'un EJB était fini et que son lien avec la façade était terminé, nous avions une «traversée», c'est à dire une de nos couches horizontales qui composent notre application. Mais l'intégration des modules nécessite de nouveaux tests que l'on appelle des tests de non régression c'est à dire la vérification que l'ajout du nouveau module ne diminue en rien le degré de qualité de l'application déjà existante. 17

18 4.1 Comment La pratique systématique des tests nous a permis de corriger nos erreurs de conception, de savoir si notre codage était correct et si nous obtenions bien ce que nous escomptions. Les tests se sont déroulés de la manière suivante : Déploiement de l application : Avant de pouvoir effectuer un test il fallait au préalable déployer notre application sur le serveur, ce déploiement générant lui-même parfois des erreurs. En cela nous pouvons considérer le déploiement comme un test à part entière. Le test : Une fois l'application déployée, il était possible de tester les méthodes, les classes, les EJBs, les pages JSP, les actions qu'elles appellent, bref ce que nous souhaitions tester. L'automatisation de la création de certains fichiers, comme par exemple dans le cas des EJB, permet d'accélérer les tests avec l'avancement du projet. En effet, certaines méthodes se retrouvent à l'identique dans différents modules. Une fois le modèle de base développé et sérieusement testé, nous avons gagné du temps dans le développement et le test des méthodes similaires. Nous avons donc appliqué le principe de base qu'on ne teste que ce qui peut casser. 4.2 L'intéret des tests Il est certain que l'architecture J2EE s'adapte très bien à la méthode de développement extreme Programming. Cela nous a offert l'avantage de faire évoluer le portail plus facilement sans pour autant devoir modifier l'existant. L'intégration continue des modules du projet ainsi que le rendu au reste de l'équipe permet, en plus d'une motivation certaine, de définir au plus proche et au plus urgent les besoins et les exigences finales de notre application. De plus les besoins définis régulièrement par le client permettent ainsi d'éviter une perte de temps en développant des modules qui s'égarent des souhaits émis par le client. Nous avons donc eu de nombreux avantages à automatiser les tests : Rapidité de détection et de correction des erreurs. Vision précise de ce qu'il y a à faire et qui permet d'aller droit au but. Fonctionnement globale du système très rapide. Ce que nous pouvons conclure sur l'évolution du projet c'est que progressivement le temps consacré au test a été réduit, ainsi nous avons passé plus de temps à développer plutôt qu'à chercher des «bugs». L'évolution du taux de réussite aux tests nous a permis de plus de constater l'évolution de la qualité de notre application. 18

19 5. Retrospective Ce projet est une expérience de travail de groupe. Il est donc intéressant de revenir sur notre organisation, et les difficultés qui ont été perçues. 5.1.Gestion du travail de groupe Un travail conséquent a été fourni pour atteindre l'objectif final, chacun étant des plus motivés. Pendant la phase de développement nous n'étions plus que treize, ce projet a donc été un important investissement personnel de la part de chacun. Une bonne communication au sein du groupe et une réelle motivation ont contribué à ce que l'ambiance de travail soit agréable. Ainsi chaque personne a permis l'avancement du projet, qui, pour nous, aura été une expérience très enrichissante Division du travail La division du travail n'a pas été faite dès les premières semaines du semestre, car au début il s'agissait de se lancer, de trouver l'accroche : «créer un EJB». Tout le monde s'y est mis, chacun de son côté ou par binômes. Notre encadrant constatant que nous avions des difficultés à nous lancer, nous a conseillé de scinder le groupe en deux : un groupe dit façade (partie serveur web et site internet) et un groupe dit EJB (partie serveur d'application et base de données). C'est à ce moment là que la machine s'est lancée. Dans chaque sous-groupe, des objectifs ont été fixés par binômes. Ainsi pendant plusieurs semaines chaque binôme a travaillé en autonomie et a fait avancer sa partie. Le rôle du mercredi après-midi a été d'effectuer ensemble les choix sur les futures orientations de notre travail, mais également de vérifier l'état d'avancement de chacun et de fixer de nouveaux objectifs. Chaque semaine, l'avancement du travail ainsi que les objectifs à atteindre pour la semaine suivante sont notés dans un cahier. Le planning qui suit synthétise donc l'ensemble des activités les plus signifiantes menées durant la phase de développement : Semaine Dates Ensemble des activités menées Semaine 02 du 10/01 au 16/01 Rôles définis : équipe CVS, équipe CMS, responsable documentation. Organisation en binômes. Notions introduites: Portlet et Portal (doc). Objectif : premier EJB Personne. Semaine 03 du 17/01 au 23/01 Itération de l'objectif de l'ejb Personne (tentative avec Jonas). Semaine 04 du 24/01 au 30/01 Toujours pas de modèle d'ejb. Division du groupe en deux sous-groupes : EJB et Façade. 19

20 Semaine Dates Ensemble des activités menées Semaine 05 du 31/01 au 06/02 Premier EJB qui marche (Personne). Création de formulaires de saisie. Création des feuilles de style (XSLT pour visualisation HTML et visualisation PDF). Objectifs: chapitre 8 du TUSC (lien entre Façade et EJB). Semaine 06 du 07/02 au 13/02 Présentation et tutoriel de l'ejb personne. Chapitre 8 fait. Développement intensif de tout cela. Semaine 07 du 14/02 au 20/02 Répartition de certains du groupe façade dans le groupe EJB. Idée : faire un EJB compteur pour la gestion des id. Le développement continu, le test aussi. Semaine 08 du 21/02 au 27/02 Vacances de Février Semaine 09 du 28/02 au 06/03 Modification du schéma UML. Confirmation de l'utilisation d'un EJB qui détermine l'id(choix du nom). Et on développe toujours... Semaine 10 du 07/03 au 13/03 Premier plan du rapport. Nouvelle modification du schéma UML. Objectifs : - Finir les EJB, pour avoir une base stable pour avancer du côté façade. - Élaboration d'une traversée complète sur Personne avec un formulaire de saisie «embelli» et une première idée de mise en forme. Semaine 11 du 14/03 au 20/03 Confirmation du plan établi, répartition des différentes parties du rapport dans tout le groupe. Définition de l aspect visuel du site et de la forme. Semaine 12 du 21/03 au 27/03 Présentation du travail pour la gestion des personnes qui ont différents droits d'accès sur le site. Modification du schéma UML. Le développement ne cesse d'évoluer (le test aussi). Semaine 13 du 28/03 au 03/04 Choix de ceux qui feront la présentation orale. Tests de tous les formulaires de saisie. Évolution du rapport, avec nouvelle répartition du travail pour celui-ci. Finalisation des EJB et tests intensifs de ceux terminés. Évolution du travail du groupe façade. Semaine 14 du 04/04 au 10/04 Présentation du travail du groupe façade (tutoriel). Présentation des pages créées du site. Semaine 15 du 11/04 au 17/04 Première version du rapport. Répartition pour la présentation orale. Définition de ce qui reste à faire, et nouvelle répartition des groupes. 20