Projet MiniCyberCoach

Transcription

1 ADVANCED SOFTWARE ENGINEERING Cours de Master en Informatique Prof. Jacques Pasquier-Rocha Projet MiniCyberCoach Catherine Pugin Florian Evéquoz Pierre-Olivier Volet Université de Fribourg, le 28 janvier 2004

2 Contenu CONTENU 2 INTRODUCTION 3 TÂCHES RÉALISÉES 4 1. IMPLÉMENTATION DES ENTITY BEANS (GÉNÉRATION DE LA BD INCLUSE) ECRITURE DES CLASSES DES COMPOSANTS INSERTION DES BALISES XDOCLET DANS LES CLASSES DES COMPOSANTS IMPLÉMENTATION D'UNE SERVLET TEST DES ENTITY BEANS CONFIGURATION DE L'EMPAQUETAGE POUR LE DÉPLOIEMENT DÉPLOIEMENT DE L'APPLICATION, TESTS ET DÉBOGUAGE RELATIONS DE DÉPENDANCE CONCLUSION 5 2. IMPLÉMENTATION DES SESSION BEANS INSERTPERSONBEAN INSERTATHLETEBEAN SEARCHACTIVITIESFORPERSONFROMTO TENTATIVE D'IMPLÉMENTATION D'UN DELETEPERSONBEAN 8 ARCHITECTURE 9 DIAGRAMME DE CLASSE 1 (ENTITY BEANS) 9 9 CONCLUSION 10 RÉFÉRENCES 10 2

3 Introduction Dans le cadre du cours Advanced Software Engineering, le projet MiniCyberCoach permet de se familiariser avec la technologie J2EE et les Entreprise Java Beans. Le but poursuivi fut l'implémentation de trois use cases du projet MiniCyberCoach. Il a fallu, pour ce faire, installer un environnement de développement J2EE complet (Jboss, MySQL, Eclipse y compris Ant et XDoclet et PhpMyAdmin). La deuxième étape fut naturellement la création d'un projet Eclipse et la configuration (Ant, XDoclet) de ce dernier. Après quoi, l'écriture des beans à proprement parler a pu commencer. Nous avons tout d'abord implémenté les cinq entity beans figurant dans le modèle objet du projet. Nous avons procédé en écrivant uniquement la classe du bean et en insérant dans les commentaires JavaDoc les balises XDoclet nécessaires à la génération des quatre interfaces du bean et du descripteur de déploiement. L'insertion des bonnes informations dans ledit descripteur a permis la création automatique des tables correspondantes dans la base de données (BD) du serveur d'application. Ensuite, nous avons procédé à l'implémentation des use cases suivants : InsertPerson, InsertAthlete, SearchActivitiesforPersonFromTo. Là, à nouveau, nous avons fait usage des balises XDoclet non seulement pour la génération du descripteur de déploiement et des interfaces mais également pour l'écriture de méthodes de recherche personnalisées (du type : findby ou ejbselect ). Finalement, nous avons implémenté une servlet test pour chaque use case développé afin de contrôler le bon fonctionnement de l'ensemble du projet. Cette dernière étape de déboguage fut la plus coûteuse en temps, mais quand même plus importante que les phases d'apprentissage des outils de développement. En effet, si nous restons persuadés d'avoir un bon investissement, la maîtrise de Eclipse et XDoclet notamment a exigé de nous d'importants efforts. 3

4 Tâches réalisées 1. Implémentation des entity beans (génération de la BD incluse) Catherine Pugin Pierre-Olivier Volet L'implémentation des entity beans, y compris génération automatique de la base de données du projet, a permis de soulever un certain nombre de questions et de les résoudre définitivement. Parmi ces questions, la plus importante fut celle des commentaires XDoclet nécessaires à insérer dans les classes des composants, afin d'obtenir les descripteurs de déploiement souhaités (ce notamment en vue de la génération de la base de données). Cinq entity beans sont implémentés dans ce projet : - PersonEntityBean, - AthleteEntityBean, - LoginIDEntityBean, - ActivityEntityBean, - DisciplineEntityBean. Chacun sera lié à une table propre dans la BD. Lors du déploiement, cinq tables seront insérées : - Person, - Athlete, - LoginID, - Activity, - Discipline. 1.1 Ecriture des classes des composants La première étape de l'implémentation des entity beans fut l'écriture des classes des composants. En effet, nous avons choisi de générer les interfaces automatiquement, à l'instar des descripteurs de déploiement, en utilisant XDoclet. C'est la raison pour laquelle la première étape de l'implémentation des entity beans ne fut pas l'écriture des interfaces distantes. Chaque composant, outre les méthodes imposées par les spécifications J2EE, contient deux méthodes pour chaque champ spécifié dans la BD du projet, l'un de type setfield et l'autre de type getfield. L'outil Eclipse générant automatiquement les lignes de code imposées pour la création d'un composant métier, l'écriture des cinq entity beans du projet s'est donc résumée aux méthodes susmentionnées. 1.2 Insertion des balises XDoclet dans les classes des composants La deuxième étape de l'implémentation des entity beans fut l'insertion dans les classes des composants des balises XDoclet nécessaires à la génération des interfaces, d'une part, et des descripteurs de déploiement, d'autre part. Ces balises sont à introduire dans les espaces JavaDoc du code. Ce fut la plus grosse partie du travail d'implémentation des entity beans et la plus délicate. Il était en effet impératif qu'il ne subsiste aucune erreur, puisque ces balises allaient non seulement générer les interfaces et les descripteurs de déploiements, mais également, indirectement et grâce aux descripteurs de déploiements complets et corrects, la BD (ou plutôt les tables correspondantes dans la BD). Si nous avons passé beaucoup de temps à entrer dans la syntaxe et la sémantique de XDoclet, il ne nous semble pas en avoir gaspillé. Car il est peu probable, premièrement, que l'écriture a mano de la classe du composant, des quatre interfaces et des descripteurs de déploiement complets et corrects nous eût coûté moins de temps. Deuxièmement, il ne faut pas sous-estimer le pouvoir de XDoclet. Cet outil permet à celui qui le connaît bien d'implémenter en vingt minutes un composant y compris ses interfaces, ses descripteurs de déploiement et, si besoin est, d'automatiser la génération de la table correspondante dans la BD. 1.3 Implémentation d'une Servlet test des entity beans La troisième étape de l'implémentation des entity beans fut l'implémentation d'une servlet destinée à tester le comportement correct des entity beans sur le serveur. Le comportement de cette servlet se borne à insérer une nouvelle personne dans la BD puis à en afficher les caractéristiques depuis la BD. 4

5 Ici encore, si l'on peut croire à une perte de temps, s'en fut en réalité un gain. Premièrement, il vaut toujours mieux tester les éléments indépendamment, de façon à cerner au plus vite les erreurs. Deuxièmement, le squelette de la servlet a pu être réutilisé pour tous les tests que nous avons effectué sur l'application Mini CyberCoach par la suite. 1.4 Configuration de l'empaquetage pour le déploiement La quatrième étape de l'implémentation des entity beans fut la définition, par l'intermédiaire des facilités fournies pour Eclipse, des options d'empaquetage Ant. A cette étape également, beaucoup de temps utilisé à entrer dans la sémantique Ant, mais pas perdu. En effet, le gain de temps fut considérable par la suite, car une fois les options Ant spécifiées, il est possible d'empaqueter le projet à chaque nouveau changement en quelques secondes. Nous avons spécifié la génération de quatre packages différents. Premièrement un package MiniCyberCoachEJB.jar, contenant les composants compilés, deuxièmement un package MiniCyberCoachEJB-client, contenant les interfaces, troisièmement un package MiniCyberCoachWeb.war, contenant la servlet. Nous avons finalement regroupé ces packages en une application J2EE individuelle empaquetée dans MiniCyberCoachApp.ear. Il a en outre fallu écrire le descripteur d'application application.xml. 1.5 Déploiement de l'application, tests et déboguage La cinquième étape de l'implémentation des entity beans fut finalement le déploiement de l'application sur le serveur, la réalisation des tests usuels (à l'aide de la servlet test) et le déboguage de l'application, ce qui englobe aussi bien des erreurs dans le code Java que dans les balises XDoclet. Cette étape fut longue et pénible et, cette fois, nous avons bel et bien perdu du temps. Il a en effet fallu plusieurs heures à la correction d'erreurs simples en raison du comportement parfois curieux d'eclipse. Nous illustrons notre propos par un exemple. JBoss nous a signalé en premier lieu une erreur dans la servlet test à la localisation du composant PersonEntity. Erreur il y avait bien, mais qui fut promptement corrigée. S'en suivit le rituel d'empaquetage et de déploiement et, au second test, surprise : l'erreur n'avait pas disparu. Plusieurs heures de recherche, correction, empaquetage, déploiement suivirent cet incident. Jusqu'au moment où M. Evéquoz suggère d'effacer entièrement la ligne problématique. À l'appel de la Servlet, effarement : l'erreur n'avait toujours pas disparu. C'est donc à cet instant que nous avons envisagé la possibilité d'une faiblesse de notre outil développement. Nous avons eu raison. Le problème semble s'être résolu de lui-même le lendemain (sans doute grâce au redémarrage de la machine). Cette anecdote veut signifier la difficulté rencontrée parfois à travailler avec cet environnement de développement. Elle veut aussi donner un élément de justification du prix d'outils de développement professionnels tels que Websphere d'ibm. Ces outils coûtent cher parce qu'ils sont complexes et délicats, et que la garantie de leur bon fonctionnement est onéreuse. 1.6 Relations de dépendance Les relations de dépendance entre les tables sont spécifiées dans le descripteur de déploiement à l'aide de balises XDoclet. Elles permettent, lors du déploiement des tables dans la BD, de générer les clés étrangères nécessaires. 1.7 Conclusion À la fin de cette phase de développement, les entity beans PersonEntity, LoginEntity, AthleteEntity, ActivityEntity et DisciplineEntity sont fonctionnels. Grâce aux spécifications XDoclet, les classes correspondantes sont générées, c'est-à-dire pour chaque entity bean, les interfaces home, remote, local et localhome. De plus, le descripteur de déploiement contient toutes les informations nécessaires à leur fonctionnement correct, dont notamment : - références JNDI des interfaces associées, - persistance (Container managed persistence - CMP), - lien avec la base de données (utilisés aussi pour la génération de ladite BD), - relations de dépendance entre entity beans (cf. diagramme de classes). 2. Implémentation des session beans Nous avons adopté grosso modo la même méthode de travail que pour les entity beans. Nous avons donc commencé par l'écriture des classes des beans, puis nous avons inséré dans les espaces JavaDoc les balises XDoclet requises pour la génération des interfaces, du descripteur de déploiement. 5

6 Les mêmes remarques faites à ce sujet dans les lignes consacrées aux entity beans sont valables pour les session beans. Entrer dans la syntaxe et la sémantique XDoclet est un exercice ardu mais au rendement élevé. 2.1 InsertPersonBean Pierre-Olivier Volet Florian Evéquoz Catherine Pugin Les spécifications du bean sont les suivantes : étant donné toutes les informations relatives à une personne, dont son username et son password, insérer les relations correspondantes dans les tables Person et LoginID de la BD. Il s'agit donc d'une transaction puisqu'il faut éviter absolument que, par exemple, la relation correspondante soit insérée dans la table Person sans que la relation correspondant ne soit insérée dans la table LoginID. Nous avons choisi de régler ce problème en spécifiant les informations relatives à cette transaction dans le descripteur de déploiement. Le modèle de transaction requis est de type required. Le bean offre la méthode suivante : public void InsertNewPerson( String FirstName, String LastName, char Gender, String Address, String TelephoneNumber, String Address, int DayOfBirth, int MonthOfBirth, int YearOfBirth, String Username, String Password) throws EJBException Cette méthode se comporte de la manière suivante : 1. Localisation des entity beans concernés, PersonEntity et LoginIDEntity 2. Détermination de la clé primaire de la relation à insérer dans Person et de la clé primaire de la relation à insérer dans LoginID. Dans ce dessein, la méthode utilise la méthode findbyprimarykey fournit par défaut par les entity beans. Elle s'en sert pour parcourir les relations enregistrées dans les tables afin de déterminer quelle est le nombre de la clé primaire de la relation insérée en dernier. Une fois ce chiffre connu, il suffit de lui additionner 1 pour obtenir la clé primaire de la prochaine relation à insérer. 3. Insertion des informations dans la BD à l'aide des méthodes de type setfield des entity beans. La méthode une lance une exception de type EJBException en cas de problème, notamment si les informations n'ont pas pu être insérées correctement. 2.2 InsertAthleteBean Pierre-Olivier Volet Florian Evéquoz Catherine Pugin Les spécifications du bean sont les suivantes : étant donné toutes les informations relatives à un athlète, insérer la relation correspondante dans la table Athlete. Puis, mettre à jour l'athlète actuel de la personne correspondante en remplaçant la clé étrangère CurrentAthlete de la personne par l'identificateur de ce nouvel athlète. Par la même occasion, il faut mettre à jour le champ ValidTo de l'ancien athlète en lui donnant la valeur du ValidFrom du nouvel athlète qu'on insère. Nous avons choisi de régler ce problème en spécifiant les informations relatives à cette transaction dans le descripteur de déploiement. Le modèle de transaction requis est de type required. Le bean offre la méthode suivante : 6

7 public void InsertNewAthlete( int ValidFrom, int Weight, int Height, int OwnZoneMin, int OwnZoneMax, Boolean Injury, int PersonId) throws EJBException Déroulement de la méthode : 1. Localisation des entity beans concernés, PersonEntity et AthleteEntity. 2. Détermination de l'athlète courant en regardant le champ CurrentAthlete de la personne concernée. 3. Grâce à cette clé, on localise l'athlète courant et on insère la valeur ValidFrom dans le champ ValidTo. 4. Ensuite on crée un nouvel athlète entity bean et on insère les valeurs requises dans la BD grâce aux setfields. Comme précédemment la méthode lance une exception du type EJBException si une erreur s'est produite durant son exécution. 2.3 SearchActivitiesForPersonFromTo Florian Evéquoz Pierre-Olivier Volet Les spécifications du bean sont les suivantes : étant donnés l'identificateur d'une personne et deux dates limites cohérentes la première date est inférieure à la seconde retourner toutes les activités des athlètes correspondants à la personne durant la période donnée. Pour ce faire, nous récupérons la date courante de la machine dans un objet Calendar pour vérifier la cohérence des dates entrées. Le bean ne traitera ainsi pas des dates qui sont "à venir". Le résultat est retourné dans un vecteur où seront listées toutes les activités. De plus, pour ce bean, nous avons dû définir deux nouvelles méthodes de recherche EJB-QL : - findathletesbypersonid(personid), - findactivitiesbyathleteid(athleteid). Ces deux méthodes permettent de simplifier les recherches dans la BD en évitant de devoir traiter chaque recherche avec les méthodes uniques, propres à chaque entity bean findbyprimarykey(pk). Celles-là sont définies dans le descripteur de déploiement par une requête SQL de type SELECT OBJECT(o) FROM table AS 0 WHERE a.fieldid =?1. Le bean offre la méthode suivante : public Vector dosearchactivitiesforpersonfromto( int PersonID, int From, int To) throws EJBException Déroulement de la méthode : 1. Localisation des entity beans concernés, ActivityEntity et AthleteEntity. 2. Parcours de la liste des athlètes et insertion dans un vecteur des athlètes correspondants à la personne en question. 3. Pour chaque athlète, on parcourt la liste des activités et on place dans un nouveau vecteur celles le concernant. On obtient ainsi deux vecteurs, l'un dans l'autre, structure que l'on retourne en réponse. Ici aussi, la méthode renvoie une exception de type EJBException en cas de problème lors de l'exécution, par exemple s'il n'y a aucune activité associée aux athlètes de la personne. 7

8 2.4 Tentative d'implémentation d'un DeletePersonBean Catherine Pugin Nous avons commencé l'écriture d'un session bean DeletePersonBean. Cette tentative avorta cependant, car la tâche se révéla, compte tenu de la forme générale du projet, bien plus importante que planifiée. L'idée de départ était d'utiliser les définitions de relations entre les entity beans (plus précisément la balise <cascade-delete />). Ceci permet de signifier au serveur d'application, lorsqu'une relation est supprimée, quelles sont les relations qui lui sont associées et qu'il faut également supprimer. De cette manière, un seul appel de la méthode remove() sur le bean à supprimer suffit à supprimer non seulement le bean en question mais aussi, par effet de cascade, tous les beans associés. Cela ne fonctionne évidemment qu'à condition que les relations soient correctement spécifiées d'une part, et que le modèle objet spécifie des relations bidirectionnelles entre tous les beans à prendre en compte dans l'effet de cascade, d'autre part. Or, si l'on observe les schémas des tables proposé dans la donnée du projet, ceci n'est pas le cas pour la relation entre les beans AthleteEntityBean et ActivityEntityBean. Implémenter un tel session bean exigerait donc plusieurs modifications dans les entity beans concernés afin que la relation entre eux devienne bidirectionnelle. Faute de temps, nous n'avons pas pu entreprendre ce travail. Ainsi, notre DeletePersonBean n'efface que les beans PersonEntity et LoginIDEntity concernés (reliés entre eux par une relation bidirectionnelle) mais pas les beans AthleteEntity et ActivityEntity. 8

9 Architecture Diagramme de classe 1 (entity beans) Fig. 1. Diagramme de classe. 9

10 Conclusion Au terme de ce travail, nous pouvons dégager plusieurs réflexions. Premièrement, une remarque quant au temps consacré à la réalisation du projet. Il nous a fallu, en effet beaucoup plus de temps que prévu pour réaliser ce projet. Ce dépassement vient, entre autres, de la complexité des outils de développement utilisés ainsi que de leur relative instabilité. Il convient à ce sujet de souligner notamment la forte propension au crash dont Eclipse a fait preuve durant le développement du projet. Une autre raison à cette multiplication du temps de travail est la complexité de l'écriture (y compris l'insertion des balises XDoclet correctes) ainsi que du déboguage d'un bean. Ce sont des entités extrêmement complexes dont le bon fonctionnement dépend d'un très grand nombre de paramètres. L'aisance dans la programmation des EJB relève de l'acquisition d'une somme importante de connaissances. Nous considérons comme un symptôme révélateur de la complexité de la tâche le fait que, bien qu'ayant travaillé à trois sur un petit projet, nous n'avons pu éviter la spécialisation de chacun. Il est en effet très vite apparu que le moyen le plus efficace de progresser dans notre travail était de répartir les diverses étapes de la création d'un EJB entre nous trois, selon nos connaissances et notre (mince) expérience dans le domaine. Cela étant, il convient de souligner que nous avons toujours travaillé en groupe, mais que le leader de l'opération changeait en fonction du type de cette opération. Ainsi, la personne qui a le mieux compris la structure des entity beans a "dirigé" l'écriture de ceux-ci, tandis que celle qui avait le mieux saisi les difficultés de la syntaxe XDoclet a supervisé l'insertion de celle-ci, etc. Malgré ces quelques ombres, il faut souligner que ce projet constitue un excellent, voire indispensable, complément au cours. Il permet, en effet, de saisir par l'exemple la nature des questions abordée d'un point de vue théorique, et ce faisant, de parvenir à une compréhension globale satisfaisante du sujet. Le projet MiniCyberCoach nous a également permis de saisir toute la puissance technique et le potentiel commercial de la spécification J2EE et des EJB. Il nous a également permis de comprendre que ces technologies sont développées en vue d'applications extrêmement complexes et que ce n'est que dans cette perspective qu'elles constituent une solution rentable et d'un type actuellement irremplaçable. Références Livres [1] R. Monson-Haefel, Enterprise Java Beans, 3rd Edition, O'Reilly, sept Sites Internet [2] bon tutorial sur les EJB avec XDoclet. [3] xdoclet.sourceforge.net site officiel de XDoclet. 10