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

21 Semaine Dates Ensemble des activités menées Semaine 16 du 18/04 au 24/04 Vacances de Printemps Semaine 17 du 25/04 au 01/05 Examens du deuxième semestre Semaine 18 du 02/05 au 08/05 Rapport final à rendre avant le vendredi 6 mai à 18h. Semaine 19 du 09/05 au 15/05 Présentation orale le mercredi 11 mai de 13h45 à 15h45, suivi des démonstrations de 16h à 18h dans l'amphi P. Tout ce travail a pris du temps, un volume d'heures considérable, mais non uniformément réparties car tout n'a pas nécessité le même investissement. Il était donc intéressant de schématiser la quantité de travail fourni. Répartition du temps de travail fourni Action des JSP Sécurité UML XSLT Sérialiser Site Test EJB Communication La communication au sein du groupe s'est globalement bien passée, même si cela n'a pas toujours été très évident, car, pour beaucoup d'entre nous, cette expérience de travail de groupe était nouvelle. Globalement, le travail de chaque binôme a été régulièrement efficace mais la prise de décisions au sein du groupe a été plus difficile. En effet, lors de certaines prises de décisions délicates, les discussions ont été plutôt insulaires et peu partagées avec l'ensemble du groupe. Il s'agit là du pire exemple de situation peu productive que nous ayons rencontré. Mais nous avons toujours insisté sur l'importance de la communication. Le rôle des deux chefs de projet a été très important pour organiser et monopoliser l'attention de tous. Ainsi, ils ont pu centraliser les informations et fixer des objectifs hebdomadaires pour que 21

22 le travail évolue, ne perdant pas de vue l'échéance du projet. La communication des résultats de chaque équipe a été très importante, elle a permis de partager le travail effectué. Chaque membre du groupe avait une vision globale de l'avancement du projet. Le concept de «travailler ensemble» a donc été l'apprentissage le moins évident, mais cela a été très enrichissant pour tous. Nous avons eu l'intelligence de bien nous entendre et de favoriser la discussion, tout ceci a bénéficié au projet, qui, dès lors qu'il a été «entamé», n'a cessé de grandir Synthèse de travaux La division du travail en début de semestre nous a permis d'évoluer en parallèle. Les bilans chaque semaine sur l'avancement de chacun permettaient de faire de nouvelles répartitions si nécessaire. Après que le premier EJB ainsi que son lien avec une page JSP aient été faits, nous avons commencé le début de la synthèse de l'ensemble des travaux que chaque binôme allait faire. La synthèse de toutes les parties élaborées par les différents groupes s'est faite progressivement tout au long du projet. La structure horizontale de notre application a permis de construire petit à petit des traversées complètes de notre portail, c'est à dire d'une action sur le site par un usager jusqu'à l'accès à la base de données si nécessaire. Cette évolution progressive nous a permis d'avoir assez vite un rendu qui a été une motivation supplémentaire pour chacun. La gestion du travail de groupe est un paramètre essentiel pour la bonne évolution d'un tel projet. Cela aura été un excellent apprentissage pour chacun d'entre nous, même si nous ne pouvons pas affirmer que nous avons toujours fait les bons choix, mais c'est en nous remettant en question que nous avons essayé d'évoluer «intelligemment». 5.2.Problèmes rencontrés Lors de l'accomplissement de notre projet, les problèmes ont été de plusieurs types : ceux liés au développement du code, ceux touchant à l'organisation du groupe et, ceux liés aux erreurs faites lors de la phase d'analyse, et du temps restreint pour finir ce projet Problèmes liés au code Problèmes du côté EJB Le premier EJB créé était de type EJB BMP, c'est à dire que la rémanence des informations était gérée par l'ejb lui même (i.e. les requêtes sont codées par le programmeur). Or nous voulions, pour que nos EJBs soient utilisables sur un maximum de bases, que la rémanence soit gérée directement par le container, c'est à dire des EJB de type CMP. Des recherches ont donc été faites à ce sujet, mais peu d'informations ont pu être trouvées, c'est pourquoi cette transformation a été difficile à opérer. 22

23 Pour ne pas avoir fixé suffisamment tôt de conventions tout à fait claires dans notre programmation, un certain désordre a régné dans les noms de nos packages, des attributs,... Nous avons donc perdu du temps à définir de nouvelles/meilleures règles communes et à mettre en conformité le travail que nous avions déjà effectué. Lors du regroupement des différents composants métiers, nous avons été confrontés au choix de tout regrouper dans un seul et même projet ou de les laisser séparés. Nous avons également dû déterminer si nous regroupions tous les sessions beans dans un même fichier ou si nous en gardions un par EJB. C'est ce dernier choix qui a été retenu par soucis de légèreté et de lisibilité Problèmes du côté Façade Après avoir réussi à faire fonctionner les différents tutoriels qui nous ont été proposés par Mr Bekkers concernant Struts, nous nous sommes confrontés au problème de l'adaptation de ces tutoriels à notre façade du projet. Ensuite, nous avons rencontré un problème important pour la création des fichiers PDF et HTML, car nos fichiers XML générés par Castor n'étaient pas conformes à la norme utilisée pour les traitements XSLT. Il nous a donc fallu étudier la norme de présentation des fichiers en DOM4J, puis créer nos fichiers XML sans l'aide d'un générateur automatique. La mise en place de l'interface faisant la liaison entre la façade et l'application fut elle aussi assez délicate.en effet, le groupe chargé de réaliser la façade Web a dû faire un effort de compréhension du code réalisé par le groupe développant les EJB afin d'utiliser les méthodes adéquates pour chaque action proposée à l'utilisateur du portail. Nous avons eu beaucoup de problèmes, et passé énormément de temps sur la création des pages JSP finales, et surtout sur le code javascript qui s'y exécute, car nous n'avions pas préparé suffisamment cette étape lors du premier semestre. Il nous a été très difficile de gérer les listes dynamiques, ainsi que tous les boutons de soumission du formulaire Problèmes liés aux technologies de sécurité Durant la phase de test et développement plusieurs éléments sont venus freiner le travail. En effet, à la forte demande de temps que suppose la mise en place du SSO-CAS (mécanisme d'authentification des utilisateurs) cette option a été écartée même si elle est tout à fait intégrable dans notre projet. Ensuite, l'annuaire LDAP de l'université s'est avéré ne pas être hiérarchisé selon des droits ou des rôles, donc inutilisable en l'état,ne contenant pas suffisamment de données exploitables pour le serveur Web. Cela sous-entend que Tomcat ne pouvait pas gérer les droits des utilisateurs dans ces conditions. Le problème le plus ennuyeux était certainement l'impossibilité de se rabattre sur la base JDBC qu'utilisent nos EJB. En effet, comme expliqué ci-dessus, nous aurions pu configurer Tomcat pour qu'il aille interroger cette base pour identifier les personnes, leurs mots de passe et leurs rôles qui auraient été préalablement sauvés par nos EJB durant le remplissage des formulaires pour les premières connexions. 23

24 Le dernier problème, qui est sans doute mineur, est le fait que le Tomcat soit «enveloppé» avec JBOSS et qu'il est d'utilisation très opaque. Nous n'avons pas pu accéder à l'administration Tool comme nous le faisions très aisément avec le Tomcat extérieur que nous utilisions seul. Cela voudrait dire que nous «débrancherions» le Tomcat de JBOSS pour utiliser un Tomcat extérieur plus configurable et plus transparent en utilisation Problèmes liés à la communication Divergences dans les noms et types d'attributs Lorsqu'il a été question de faire le lien entre les EJB et la façade, nous nous sommes rendu compte que les noms des attributs n'étaient pas tous identiques des deux côtés. Cela ne rendait pas la liaison impossible, mais le code interface qui liait la façade à l'application devenait très difficile à comprendre car on se perdait facilement parmi les noms d'attributs. Il a donc fallu choisir l'un des deux côtés comme base à suivre pour nommer tous les attributs. C'est le côté application qui a été judicieusement choisi, pour la simple et bonne raison que la modification d'un attribut d'ejb entraîne de plus longues et plus complexes modifications sur le code de l'application. Un nouveau diagramme UML a ensuite été réalisé et distribué à tous pour que de tels problèmes n'arrivent plus. Le même problème a été rencontré au niveau des types des attributs. En effet, du côté façade, il est plus aisé de ne manipuler que des chaînes de caractères. Cela ne semble forcément pas logique lorsqu'on parle d'un âge ou d'un numéro de rue, pourtant nous avons maintenu cette version de la façade qui ne contenait que des chaînes de caractères car elle était déjà fonctionnelle. C'est pourquoi, il a été nécessaire d'adapter l'application afin qu'elle gère systématiquement des chaînes de caractères en entrée qu'elle peut ensuite convertir lors du stockage dans sa base de données Divergences dans la structure du projet Afin d'avoir une version finale claire et ordonnée de notre projet, il a fallu que l'ensemble des développeurs se mettent d'accord sur la structure du projet au niveau de l'organisation de ses répertoires et de ses fichiers. Au début du développement, aucune organisation des fichiers n'avait été prévue. Ceci était dû au fait que chaque binôme développait des parties indépendantes. Du coup, chaque binôme organisait son sous-projet à sa manière. Pourtant, afin de réunir tous les EJB et la façade, il a fallu faire des choix d'organisation. C'est pourquoi nous avons mis en place une structure type du côté façade, et une autre du côté application. Cette division en deux projets aux structures distinctes nous a permis de simuler en plus le côté application répartie de notre projet. 24

25 5.2.3.Problèmes liés au diagramme UML Lors de la programmation des différents objets métiers, nous nous sommes rendus compte que la vision que nous en avions au premier semestre était trop vague et entraînait trop de contraintes. C'est pourquoi nous avons repris le schéma UML du premier semestre de façon à ce que les différentes composantes ainsi que leurs liens soient bien identifiés et éclaircis au besoin. Du fait de la structure même des EJB le schéma UML a du être une fois de plus remanié pour supprimer les compositions et agrégations, ce qui a entraîné la création de nouveaux objets métiers intermédiaires Problèmes liés au temps Apprentissage des technologies long et fastidieux L apprentissage des différentes technologies nous a demandé un investissement en temps que nous avions, pour la plupart, sous-estimé. Les recherches sur Internet et dans les différents livres que nous avons trouvés se sont succédées pendant plusieurs semaines, là où nous pensions en passer une seule. Une discussion entre nous, ainsi qu avec Mr Bekkers, au sujet de ce qui avait été compris, s'est avérée nécessaire pour être sûrs de ne pas faire fausse route. Planning trop optimiste et difficile à respecter A la fin du premier semestre, nous avions tenté d ériger un premier planning pour le deuxième semestre. Assez rapidement, il s est avéré que ce planning serait impossible à respecter, en grande partie parce que nous n avions pas prévu que l apprentissage des EJB serait aussi long. Effectivement, le planning prévoyait l intégration des EJB pour la fin du mois de janvier, or le premier EJB a été finalisé seulement fin février. 25

26 Conclusion Notre application n'est pas parfaite et peut donc être améliorée sur différents points. Tout d'abord, il existe quelques points faibles en particulier au niveau de la partie métier (EJB). D'un coté le nombre de fonctions offertes nous permet une grande évolutivité, mais d'un autre coté les objets en mémoire sont plus conséquents. C'est pour cette raison que chaque entité doit être la plus petite possible. Mais l'évolutivité de la partie de la façade est limitée aux fonctions de la partie métier, c'est à dire que des fonctions supplémentaires doivent être rajoutées pour offrir de nouveaux services. En définitive, ce projet a été l'occasion pour nous de nous confronter à de nouvelles technologies, et à l'obligation de se former continuellement pour pouvoir avancer. Ceci nous a également permis d'apprendre à travailler en groupe et de conduire un projet de son élaboration jusqu'à son développement. Les véritables difficultés de travailler en équipe ont été soulevées, et ont su globalement être réglées. Au plan du travail de groupe, les erreurs sont dues en partie au manque d'expérience, et ce projet était donc nécessaire pour bien cibler ces difficultés. 26

27 Annexe - L'eXtreme programming L Extreme Programming (XP) est une méthode de développement légère conçue pour de petites équipes confrontées à des environnements mal connus ou fortement changeants. Cette méthode mise au point sur le terrain propose un processus focalisé sur les objectifs élémentaires du développement : o Développer vite. o Développer juste. 1. XP en bref XP définit une discipline de développement qui permet de diminuer le coût du changement dans le logiciel, à tel point qu'il devient plus avantageux de prendre les décisions le plus tard possible, en attendant les résultats concrets issus du développement lui-même. Les spécifications peuvent alors être élaborées progressivement tout au long du développement en enchaînant des itérations rapides de spécification / développement / livraison. Le client peut ainsi guider le développement tout au long du projet. 2. Les pratiques XP XP définit la manière dont l'équipe intéragit avec le client pour "développer juste" : o Livraisons fréquentes : l équipe vise la mise en production rapide d'une version minimale du logiciel, puis elle fournit ensuite régulièrement de nouvelles livraisons en tenant compte des retours du client. o Planification itérative : un plan de développement est préparé au début du projet, puis il est revu et remanié tout au long du développement pour tenir compte de l expérience acquise par le client et l équipe de développement. o Client sur site : le client est intégré à l'équipe de développement pour répondre aux questions des développeurs et définir les tests fonctionnels. o Rythme durable : l équipe adopte un rythme de travail qui lui permet de fournir un travail de qualité tout au long du projet. XP définit des pratiques permettant de développer vite tout en acceptant le changement tout au long du projet : o Conception simple : on ne développe rien qui ne soit utile tout de suite. o Remaniement : le code est en permanence réorganisé pour rester aussi clair et simple que possible. o Tests unitaires : les développeurs mettent en place une batterie de tests de nonrégression qui leur permettent de faire des modifications sans crainte. o Tests de recette : les testeurs mettent en place des tests automatiques qui vérifient que le logiciel répond aux exigences du client. Ces tests permettent des recettes automatiques du logiciel. 27

28 XP repose également sur une grande cohésion de l'équipe : o Responsabilité collective du code : chaque développeur est susceptible de travailler sur n'importe quelle partie de l'application. o Programmation en binômes : les développeurs travaillent toujours en binômes, ces binômes étant renouvelés fréquemment. o Règles de codage : les développeurs se plient à des règles de codage strictes définies par l'équipe elle-même. o Métaphore : les développeurs s'appuient sur une description commune du design. o Intégration continue : l'intégration des nouveaux développements est faite chaque jour. 3. Le cycle standard XP 1. Le client écrit ses besoins sous forme de scénarios. 2. Les développeurs évaluent le coût de chaque scénario. 3. Le client choisit les scénarios à intégrer à la prochaine livraison. 4. Chaque développeur prend la responsabilité d'une tâche. 5. Le développeur choisit un partenaire. 6. Le binôme écrit les tests unitaires correspondant au scénario à implémenter. 7. Le binôme prépare l'implémentation en réorganisant le code existant, puis il procède à l'implémentation proprement dite. 8. Le binôme intègre ses développements à la version d'intégration, en s'assurant que tous les tests de non-régression passent. 4. Limites de XP XP n est pas une méthode «presse-bouton». Sa mise en œuvre demande des efforts, et le contexte doit être suffisamment favorable : o Les développeurs doivent avoir une compétence suffisante pour construire des applications réellement évolutives. o L'entente entre les membres de l'équipe doit permettre une réelle communication et une collaboration efficace. XP introduit un changement fondamental dans l'approche du développement : la culture de l'entreprise doit permettre ce changement, et chacun doit se former à ces pratiques. Conclusion : XP crée une véritable dynamique d'équipe qui séduit à la fois le client et les développeurs : le client retrouve un rôle central dans le développement, et les développeurs participent à tous les aspects du développement et travaillent véritablement en équipe. XP ne s'applique cependant pas à tous les contextes : c'est à chaque projet de déterminer si XP lui convient, et dans l'affirmative l'adoption de la méthode doit se faire de manière progressive pour laisser le temps à chaque intervenant de se former à ces pratiques. Reférence : 28

29 Annexe - Création d'un EJB CMP Avant de commencer il vous faut installer : 1. J2SDK (que vous trouverez à l'adresse suivante ajoutez la variable d'environnement: Nom de la variable : JAVA_HOME Valeur de la variable : path d'installation de votre J2SDK 2. JBOSS (serveur d'applications J2EE gratuit et contient 'TOMCAT' comme serveur web) la version la plus récente est conseillée, copiez le répertoire jboss-x.x.x sous C: ajoutez la variable d'environnement : Nom de la variable : JBOSS_HOME Valeur de la variable : C:\jboss-x.x.x 3. Lomboz (plugin eclipse pour le développement en J2EE) Help>Software Updates>Add an extension location : et vous précisez le chemin du répertoire où se trouve le plugin, ce répertoire doit toujours être contenu dans un répertoire de nom 'eclipse' qui contient un fichier ECLIPSEEXTENSION Maintenant que Lomboz est installé, il reste à le configurer : Windows>Preference>Lomboz : indiquez le path du Tools.jar Windows>Preference>Lomboz>Server Definitions : indiquez le ou les serveur(s ) que vous souhaitez utiliser et indiquez son path 29

30 indiquez les différentes bibliothèques et assurez-vous qu'elles sont bien ajoutées : Réalisation d'un projet J2EE Tout d'abord il faut créer un projet J2EE : Dans file>new>lomboz J2EE Project : Renseignez le nom du projet, puis cliquez deux fois sur suivant. ajoutez un module web et un module ejb : Et adjoignez-lui un (des) serveur(s) cible(s), installé(s) plus haut : 30

31 Une fois le projet créé, il faut créer un nouvel ejb : 3 ETAPES : 1. Développement d'un entité Bean CMP: avant de faire cela il faut savoir que la classe qui définit un entity bean : Doit implémenter l interface EntityBean (fait par lomboz). Doit être publique (fait par lomboz). Doit implémente des méthodes ejbcreate(), ejbpostcreate(), ejbremove() N'a pas de constructeur (fait par lomboz mais pas toujours, une faiblesse) File>New>Lomboz EJB Creation Wizard Remplissez les champs Nom et Package puis choisissez Container Managed Entity EJB comme type(entité CMP) : Next>remplissez les informations concernant les données/attributs de notre EJB: ces attributs représentent les champs de la table dans la base de données. 31

32 N.B: N'oubliez pas de préciser la clé primaire de la table. Après avoir ajouté tous les champs celui ci créera un fichier nommé ufrdeunivbean.java sous le package portail.lmd.entity sous le répertoire src. Ajoutez l'entity au module EJB(que l'on a créé au début) : Placez-vous sur le bean créé,c'est à dire sur le fichier ufrdeunivbean.java sous le package portail.lmd.entity sous le répertoire src, clic droit>lomboz J2EE>Add EJB to module. Ce qui, dans la vue lomboz, ajoute l'entity comme appartenant au module : Complétez la méthode ejbcreate de votre entity, il faut ajouter les attributs en paramétres et, dans le corps de la méthode, les setter : Ajoutez les tags pour les méthodes finders qui sont l'équivalent des requêtes SQL, ils seront ajoutés aprés le tag suivant qui a déjà été généré par Lomboz (on pourrait les mettre 32

33 ailleurs c'est à dire directement dans nos méthodes mais cela annulerait l'avantage des CMP, contrairement aux BMP pour lesquels on est obligé d'utiliser les requêtes directement dans nos méthodes): Ce qui nous donne (ici on rajoute une méthode de recherche par Id d'ufr), biensûr on peut en ajouter d'autres finders: Générez vos classes ejb grâce aux tags ajoutés plus haut: Patientez le temps que cela se fasse... Lorsque cela sera fini, vous aurez dans la console le message suivant : BUILD SUCCESSFUL Total time: 1 minute 29 seconds) Créez une business Method get...data : Clic droit sur la classe se trouvant dans le Bean>New>Lomboz EJB Method Wizard. Entrez l'entête de la méthode (éventuellement avec des paramètres) dans le champs Method Signature Method Type : choisissez Business Method Interface Type : choisissez Local Interface (les méthodes des bean ne doivent pas être distantes) Complétez le corps de la méthode : Astuce : au lieu de créer la méthode par le menu on peut la créer directement dans le code source (par un copier coller par exemple). Ajoutez les méthodes callbacks, en ajoutant un champ où sera stocké le contexte et deux méthodes pour l'assigner et pour le désassigner : 33

34 Regénerez les classes EJB, et vous en aurez fini avec l'entity. 2. Développement d'un session Bean: File>New>Lomboz EJB Creation Wizard remplissez les différents champs et choisissez Stateless Session EJB comme type d'ejb Ajoutez le session au module EJB. Ajoutez les tags suivants au début du session c'est à dire au début de ufrdeunivaccess: Ajoutez un champ...localhome pour sauvegarder les références : Ajoutez la méthode ejbcreate : 34

35 Ajoutez les méthodes remote (distantes) pour accéder a votre Bean : Tout d'abord les getters ou méthodes de recherche, biensûr il peut y en avoir plusieurs Puis les adders ou méthodes d'ajout : Puis les méthodes de modification : Et enfin les méthodes de suppression : 35

36 Et voilà vous avez fini EJB, il ne reste qu'à générer Création un client de test : File>New>Lomboz EJB Test Client Wizard : Complétez la méthode testbean selon les tests que vous désirez faire, par exemple : Modifiez le Jboss.xml : Lomboz ne compléte pas correctement le jboss.xml. Il faut transformer tout les ejb-ref par des ejb-local-ref (cette modification est à faire à chaque regénération des classes EJB). Modifiez le xdoclet.xml : il faut lui indiquer le type de base de données utilisé, le nom du serveur etc... pour cela recherchez dans le fichier le champs correspondant à jboss et rentrez les informations suivantes : Donnez le path des plugins : en raison d'une petite imperfection d'eclipse, les plugins ne sont pas recopiés dans le répertoire plugins d'eclipse, alors 2 solutions : 36

37 1. Recopiez manuellement les plugins dans le répertoire plugins d'eclipse 2. Modifiez le Path dans le xdoclet.xml : recherchez le champ «fileset» et dans dir donnez le path pour les plugins. Lancez le serveur : Lomboz J2EE View > Modules > UfrDeUniv > ejb_ufrdeuniv > jboss325 > clic droit > Run Server Déployez votre EJB (vous pouvez le faire avant ou après le lancement du serveur car Tomcat analyse continuellement si de nouveaux EJB ont été déployés): Lomboz J2EE View > Modules > UfrDeUniv > ejb_ufrdeuniv > clic droit > Deploy. Lancez le client de test: placez-vous sur votre client>clic droit>run>java application et si tout se passe bien vous aurez le résultat dans la fenêtre console. 37

38 Annexe - Façade 1.Structure du projet constituant la façade Afin de rendre claire et simple l'arborescence des fichiers de la partie façade, nous avons décidé de bien séparer les fichiers selon leurs types et fonctions. De plus, le fait de réunir tous les fichiers utiles à la façade dans un même projet permet de n'avoir que des librairies internes au projet, donc de ne gérer que des chemins relatifs à la racine du projet. Voici comment se présente l'arborescence de la façade : Racine de la façade Répertoire des feuilles de style Répertoires des fichiers générés par la façade Répertoires spécifiques de Struts : «merge» contient tous les fichiers XML de configuration de Struts qui formeront le fichier «web.xml» une fois concaténés. «META-INF» contient le fichier qui va indiquer le package contenant le projet à déployer sur le serveur web et sa racine. «pages» contient toutes les pages JSP de notre façade «WEB-INF» contient tous les fichiers sources (les classes compilées et les fichiers JAVA) de nos beans 38

39 Le répertoire contenant toutes les sources Java est divisé en trois parties : «outils» contient les fichiers Java rassemblant toutes les méthodes de création et de traitement des fichiers XML, PDF et HTML. «resources» contient le fichier «ApplicationRessources.properties» qui sert de source pour tous les messages d'erreur ainsi que pour tous les textes des boutons. «struts» contient tous les fichiers permettant la gestion de chaque type de formulaire (il est divisé en sous répertoires : un pour chaque type) 2.Explication rapide du code source 2.1.Package «outils» «XMLObjectException.java» Il s'agit simplement de la classe de gestion des exceptions, qui au final ne fait que propager les exceptions interceptées à sa classe mère «XMLObject.java» Il contient trois types de méthodes : les méthodes qui, à partir des valeurs des champs du formulaire qui lui sont passés en paramètres, créent ou bien complètent le fichier XML correspondant qui contient toutes les valeurs saisies dans la base jusqu'à présent. C'est-à-dire, par exemple, vous voulez pour le formulaire de saisie d'une personne, que le fichier XML contienne toutes les personnes qui ont été saisies auparavant. une méthode qui, à partir d'un fichier XML génère le fichier PDF correspondant. une méthode qui, à partir d'un fichier XML génère le fichier HTML correspondant. Attardons-nous tout particulièrement sur la génération des fichiers XML. Il s'agit de créer un objet de type «dom4j.document» à partir, à la fois du fichier XML correspondant, s'il existe, puis d'y ajouter le noeud créé à partir des paramètres, ou bien s'il n'existe pas, de créer le fichier XML uniquement avec le noeud créé. NB : grâce à l'utilisation de XPATH, nous évitons l'enregistrement d'un doublon dans le fichier XML. Le code étant assez simple, nous vous invitons à le lire pour une meilleure compréhension. 2.2.Package «resources» Le fichier «ApplicationRessources.properties» sert, en quelque sorte, de base de valeurs de libellés à Struts car c'est dans ce fichier qu'il va chercher les messages qu'il a besoin d'afficher. Cela permet de gérer ces messages sans savoir où ils sont utilisés et de les factoriser (par exemple : le texte qui s'affiche sur le bouton annulation doit être le même pour toutes les pages JSP de la façade pour être cohérent, donc ces boutons font tous référence à la même entrée «button.annulation = Annuler»). 39

40 2.3.Package «struts» Ce package contient les fichiers Java qui constituent le «bean» auquel fait appel la page JSP qui lui correspond. Il est divisé en autant de sous-packages qu'il existe de type d'entités dans notre diagramme UML. Chacun de ces sous-packages contient deux fichiers : le premier, qui porte le nom de l'entité, correspond au «bean» qui constitue la servlet servant à l'exécution de la page JSP chez le client. Il contient tous les attributs correspondants aux champs de saisie de la JSP (avec les accesseurs d'attributs associés), ainsi qu'une fonction de validation appelée lors de la soumission du formulaire qui vérifie les informations saisies. le second, «submitaction.java», est le fichier le plus important ici, car c'est lui qui s'occupe de tous les traitements effectués en fonction du bouton de la JSP qui est déclenché. En effet, à chaque bouton correspond une méthode qui porte le nom que l'on a attribué grâce à la méthode getkeymethodmap qui associe la déclaration du bouton dans la JSP à la méthode dans la classe «submitaction.java». Ces méthodes peuvent être celles utilisées par l'administrateur pour la saisie (ajout, suppression, modification et affichage) ou bien celles utilisées par un visiteur qui souhaite effectuer une recherche ou une consultation. Le principe de ces méthodes est toujours le même : on crée un EJB session correspondant à l'objet métier que l'on souhaite manipuler, puis on l'utilise pour accéder aux méthodes de traitement des EJB. Suivant les données récupérées par le formulaire, ces méthodes modifient la base de données ou bien y récupèrent des informations. Après un traitement adéquat elles rendent ces informations à l'utilisateur sous forme HTML ou PDF. 2.4.Struts-config.xml Ce fichier est le fichier de configuration de tous les formulaires de notre façade. Il est constitué de deux parties distinctes : Une partie «Form Bean Definitions» qui regroupe les définitions de tous les beans, c'est à dire l'association du nom du Bean à sa classe. Une partie «Action Mapping Definitions» qui regroupe les définitions des différentes actions. C'est dans cette partie que l'on définit par exemple quelle page JSP afficher suivant le résultat de la méthode définie dans la classe «SubmitAction.java». 40

41 Annexe - Schéma UML 41

42 Annexe - Authentification et Sécurité Le chapitre sécurité du projet LMD-J2EE a une place très importante, en effet, comme toute application web gérant des ressources et des accès privilégiés, ce portail web se voit obligé d'avoir un système de sécurité et d'authentification. 1. Sécurité : La sécurité de modèle web-tiers utilisée dans la Java Web Service Developer Pack est basée sur la spécification de Java Servlet Spécification qui améliore la portabilité des applications leurs permettant d'être déployées dans divers environnements de sécurité. La spécification JWSDP définit une sorte de contrat entre les développeurs d'applications web et ceux qui configurent ces dernières dans leurs milieux opérationnels. Les mécanismes de sécurité mis en place par les développeurs web sont exprimés dans un descripteur de déploiement (fichier xml) ayant pour but d'être intégré dans le fichier Web.xml de l'application. Le principe de gestion des accès et des droits repose sur le découpage en Utilisateurs, Groupes et Rôles. Rôle - c'est ce qui permet à un utilisateur d'avoir accès ou pas à un ensemble particulier de ressources. Un rôle peut être comparé à une clé qui ouvrirait certaines serrures et pas d'autres. Dans le cadre du projet J2EE-LMD on aura trois types de rôles Administrateur, Enseignant ou Visiteur. Utilisateurs - c'est un individu, client identifié de l'application Web. Groupes - c'est un ensemble d'utilisateurs identifiés et classés selon des caractéristiques communes, pour ce projet, ils seront associés selon les trois rôles existants. A côté de ce découpage la notion de REALM est très importante puisque c'est ce qui constitue la base de données complète des rôles, utilisateurs et groupes qui identifie un utilisateur valide dans une application Web (ou un ensemble d'applications Web). Dans ce projet les utilisateurs seraient stockés dans un annuaire LDAP avec leur(s) rôle(s) associé(s) ou à défaut dans une base de données SGBDR gérée par les EJB. 2. Technologies : Les technologies utilisées dans cette partie du projet sont donc : LDAP Serveur web TOMCAT 5 XML Pages JSP et Servlets 42

43 3. Architecture : L'environnement de programmation pour le portail côté serveur web se fait selon le modèle STRUTS s'appuyant sur le serveur TOMCAT 5. Sur la figure ci-dessous, nous voyons le processus qui s'enclenche quand une personne essaie d'accéder à des parties du site à accès sélectif. Figure 1 Le processus d'authentification se déroule en général ainsi: demande d'accès à une ressource ou à une page protégée le serveur web qui gère la protection enverra l'utilisateur vers une page de login l'utilisateur s'identifie lancement d'une recherche de cet utilisateur sur l'annuaire LDAP s'il existe, ouverture d'une session par Tomcat pour cet utilisateur sinon envoi vers une page d'erreur accès à la ressource Durant l'authentification serveur TOMCAT récupère l'identité de l'utilisateur et de son rôle. Si l'authentification par LDAP est validée alors le serveur ouvre une session avec l'identifiant du client ainsi reconnu. Grâce au contenu du fichier web.xml de l'application Web, TOMCAT peut à ce moment là, connaissant le rôle du client, lui donner accès ou non à certaines pages ou ressources. 43

44 4. Développement et test : La phase de développement pour toute la partie sécurité et gestion des droits a été précédée par une phase de recherche afin d'identifier les possibilités des technologies dont nous disposons et ce que nous pouvons trouver pour compléter ou remplacer par des moyens plus récents et plus faciles à mettre en œuvre. 4.1 Recherche : La phase de recherche n'a pas été très longue, elle nous a servi à mieux appréhender de nouvelles technologies telles que SSO-CAS et LDAP. SSO-CAS (Single Sign-On - Central Authentification service) est totalement OpenSource à base de JAVA et sert comme son nom l'indique à ne s'identifier qu'une unique fois pour plusieurs applications Web. Cela est idéal dans le cadre de notre projet puisqu'un portail a pour but à long terme de regrouper plusieurs applications sécurisées telles qu'un emploi du temps, un calendrier d'examens, une boite ... En ce qui concerne LDAP, notre but est de nous servir de l'annuaire déjà existant de l'université et ainsi l'utiliser dans un premier temps pour les authentifications en ligne avant de pouvoir, si nous le souhaitons, l'étendre à celui de plusieurs universités. 4.2Développement : Dans Tomcat, grâce aux Realms, il est possible de protéger l'accès aux ressources du serveur, en demandant aux utilisateurs de s'authentifier. Le principe est simple (tout le monde l'a déjà rencontré sur un site) : lorsque l'utilisateur tente d'accéder à l'url d'une ressource protégée, il est envoyé vers une page de login : nom d'utilisateur et son mot de passe. Pour cela, il faut configurer un REALM pour notre application sur TOMCAT et en parallèle enrichir le fichier web.xml de notre application. Nous créons alors un nouveau fichier xml que nous passerons au Xdoclet qui lui même générera le fichier web.xml final de l'application. Le fichier xml comporte plusieurs balises relatives aux contraintes et sécurité. Dans l'exemple suivant nous voyons comment déclarer des contraintes sur des ressources web et les définitions des rôles impliqués : <web-app>... <security-constraint> <display-name>sécurité sous Tomcat</display-name> <web-resource-collection> <web-resource-name>ressource protégée</web-resource-name> <url-pattern>/appli/*</url-pattern> <http-method>get</http-method> <http-method>post</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> <role-name>user</role-name> </auth-constraint> </security-constraint> <security-role> <role-name>admin</role-name> </security-role>... </web-app> 44

45 Ci-dessous nous voyons la correlation avec ce qui a été déclaré ci-dessus dans le fichier web.xml et ce que TOMCAT doit avoir comme référence pour respecter les contraintes établies dans son fichier tomcat-users.xml : <?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="tomcat"/> <role rolename="role1"/> <role rolename="manager"/> <role rolename="admin"/> <user username="tomcat" password="tomcat" roles="tomcat"/> <user username="role1" password="tomcat" roles="role1"/> <user username="both" password="tomcat" roles="tomcat,role1"/> <user username="admin" password="" roles="admin,manager"/> </tomcat-users> Nous remarquons qu'il est nécessaire qu'il y ait correspondance entre les security roles que TOMCAT connaît (dans son REALM) et ceux qui sont déclarés dans le web.xml. 4.3Tests : Pour les tests, nous avons procédé en trois phases: tests d'utilisation d'une authentification LDAP tests de fonctionnement de Tomcat avec un site exemple tests de gestion des droits avec Tomcat à partir d'une base de données Première phase, nous avons créé une page de garde web d'un site internet et avons mis en place un lien d'authentification qui nous redirige vers l'annuaire LDAP de l'université après authentification avec la base de données de l'université on reçoit un ticket qui nous sert d'identifiant pour la session durant laquelle on est connecté. La deuxième phase quant à elle, consiste à intégrer un site web composé de quelques pages ainsi que de son web.xml au fichier Webapps de Tomcat. Nous avons étudié ainsi les différentes méthodes dont nous disposons pour gérer notre site web avec les différentes bases de données utilisateurs possibles. Le serveur web accepte jusqu'à 4 types de bases différentes : JDBCRealm connectant Tomcat à une base relationnelle JNDIRealm connectant Tomcat à un annuaire LDAP MemoryRealm qui lit des fichiers xml contenant les utilisateurs valides, leur mot de passe et rôles UserDataBaseRealm connectant Tomcat à des ressources JNDI configurées pour ce serveur. Durant cette phase nous avons remarqué que nous pouvions utiliser conjointement la base JDBC des EJB. Le serveur Web serait alors en lecture quant aux EJB ils seraient en lecture/écriture. La configuration pour l'utilisation d'une telle base se fait dans l'administration Tool de Tomcat. Il suffit de remplir le formulaire ci-dessous avec les informations adéquates. 45

46 Figure 2 Malheureusement, nous n'avons pas pu tester cette configuration. Le développement des EJB se faisant sur une «mini» base de données existante dans Jboss, nous n'avons pas pu récupérer toutes les informations qui caractérisent cette base pour les passer dans le formulaire de la figure 2. Ce point est expliqué plus en détail dans le chapitre des problèmes rencontrés. La troisième phase nous a permis de voir comment se concrétisait la gestion des rôles par Tomcat. Nous avons opté dans le cadre du test pour une MemoryRealm. C'est à dire un fichier xml contenant une liste d'utilisateurs valides avec leurs rôles et leur mot de passe. Le fichier étant comme suit : <?xml version='1.0' encoding='utf-8'?> <data-users> <role rolename="tomcat" description="role indéfini"/> <role rolename="role1" description="consultation"/> <role rolename="manager" description="consultation publication"/> <role rolename="admin" description="ayant droit"/> <group groupname="enseignant" description="groupe de publication" roles="manager"/> <group groupname="admin" description="l'administrateur" roles="admin,manager"/> <user username="mehdi" password="mehdi" fullname="mehdi" groups="admin" roles="admin,manager,role1,tomcat"/> <user username="steeve" password="steeve" fullname="steeve" groups="enseignant" roles="admin,manager,role1,tomcat"/> <user username="nolwenn" password="nolwenn" fullname="nolwenn" groups="enseignant" roles="manager,role1,tomcat"/> <user username="patrick" password="patrick" fullname="patrick" groups="enseignant" roles="manager,role1,tomcat"/> <user username="nizar" password="nizar" fullname="nizar" groups="enseignant" roles="manager,role1,tomcat"/> <user username="amine" password="amine" fullname="amine" groups="enseignant" roles="manager,role1,tomcat"/> <user username="yann" password="yann" fullname="yann" groups="enseignant" roles="manager,role1,tomcat"/> <user username="aubin" password="aubin" fullname="aubin" groups="enseignant" roles="manager,role1,tomcat"/> <user username="fiona" password="fiona" fullname="fiona" groups="enseignant" roles="manager,role1,tomcat"/> 46

47 <user username="damien" password="damien" fullname="damien" groups="enseignant" roles="manager,role1,tomcat"/> </data-users> Nous voyons que les rôles sont préalablement définis ainsi que les groupes existant avant l'énumération des utilisateurs. Ensuite, comme expliqué plus tôt, le fichier web.xml de l'application, ici de notre site test, est enrichi avec ces quelques lignes qui précisent les pages protégées de celles qui ne le sont pas comme suit : <web-app>... <welcome-file-list> <welcome-file>lien.htm</welcome-file> </welcome-file-list> <security-constraint> <display-name>pages a acces selectif</display-name> <web-resource-collection> <web-resource-name>ressource protégée</web-resource-name> <url-pattern>/page1.htm</url-pattern> <http-method>get</http-method> <http-method>post</http-method> </web-resource-collection>... <auth-constraint> <role-name>admin</role-name> </auth-constraint> </security-constraint>... <login-config> <auth-method>form</auth-method> <form-login-config> <form-login-page>/login.htm</form-login-page> <form-error-page>/error.htm</form-error-page> </form-login-config> </login-config>... <security-role> <description>the prof role</description> <role-name>admin</role-name> </security-role>... </web-app> Grâce à ce dispositif nous avons pu voir comment le serveur gérait automatiquement les accès aux pages après s'être identifié. En effet, si nous ne disposons pas des droits nécessaires pour accéder à une page et que nous ne sommes pas identifié, Tomcat nous redirige automatiquement vers une page de login sinon vers une page d'erreur explicitant la restriction. 47