Cahier des charges technique

Transcription

1 Filière Informatique et Réseaux - 3ème année Projet O.P.S. Gang of five

2 ETAT DU DOCUMENT Auteur du document Nom(s) et titre(s) Signature(s) Date Equipe GoF 01/11/2007 Vérification du document Nom(s) et titre(s) Signature(s) Date KARKAB Yazid Y. Karkab 11/11/2007 SARVARIE Maxime M. Sarvarie 11/11/2007 Approbation du Document Nom(s) et titre(s) Signature(s) Date MORELLE Alexis A. Morelle 11/11/2007 DOCUMENTS DE REFERENCE Référence Version Date version Description documents CDC_ /11/2007 Cahier des charges CDCG_ /10/2007 Cahier des charges graphique DDODT_ /10/2007 Définition des outils de travail CDCF_ /11/2007 Cahier des charges fonctionnel 11/11/07 Version / 77

3 EVOLUTION DU DOCUMENT Version Date Auteur Motif(s) de l évolution /11/2007 Yazid Karkab Plan du document /11/2007 Yazid Karkab Intégration de l'étude technique faites dans le DODT. Modification de cette dernière pour l'adapter au CDCT /11/2007 Yazid Karkab Intégration des premiers diagrammes de paquetage et quelques diagrammes de classes. Aucun commentaire de ces schémas pour le moment /11/2007 Yazid Karkab Ajout de la partie «conception du logiciel» Modification de l'architecture logicielle dans l'étude technique /11/2007 Maxime Sarvarie Objectifs du document, conventions de codage, UC génériques. 11/11/07 Version / 77

4 Table des matières 1 Objectifs du document Etude technique Architecture logicielle Développement des clients Bases de données Librairies Frameworks Conception du logiciel Généralités sur les diagrammes de classes et paquetages Paquetage «ops.server» Paquetage «ops.common» Paquetage «ops.heavyweigth» Evolution de la conception Cas d'utilisation génériques Cas d'utilisation de persistance Conventions de codage Langue Contrôle automatique de la qualité du code Versions Conclusion Glossaire /11/07 Version / 77

5 Index des illustrations Illustration 1: Architecture logicielle OPS...8 Illustration 2: Diagramme de paquetages général...27 Illustration 3: Paquetage "server"...29 Illustration 4: Paquetage "server.session"...30 Illustration 5: Paquetage "server.core.dao"...31 Illustration 6: Paquetage "server.core.processing"...32 Illustration 7: Paquetage "common"...34 Illustration 8: Entité "Attendee"...35 Illustration 9: Entité "OralPresentation"...37 Illustration 10: Entité "Planning"...39 Illustration 11: Entités "TimeRange" et "Company"...41 Illustration 12: Classe "EntityFactory"...42 Illustration 13: Paquetage "common.rules"...43 Illustration 14: Paquetage "common.properties"...45 Illustration 15: Paquetage "heavyweight"...47 Illustration 16: Paquetage "heavyweight.gui.skel"...48 Illustration 17: Paquetage "gui.attendee.view"...49 Illustration 18: Paquetage "gui.attendee.model"...51 Illustration 19: Paquetage "heavyweight.util"...52 Illustration 20: Diagramme de séquence "Créer une entité en base de données"...56 Illustration 21: Lire une entité en base de données...59 Illustration 22: Modifier une entité en base de données...62 Illustration 23: Supprimer une entité en base de données...65 Illustration 24: Structure du dépôt Subversion /11/07 Version / 77

6 1 Objectifs du document Le présent document constitue le cahier des charges technique du projet OPS réalisé par l'équipe Gang of Five. Il définit une réponse au cahier des charges fonctionnel sous forme d'une étude technique définissant les outils qui seront utilisés par l'équipe ainsi qu'une conception détaillée de l'architecture logicielle de la future application. Ce documentt contient également les conventions de codage qui seront appliquées pour obtenir une application facilement maintenable et évolutive. On trouvera également dans ce cahier des charges technique l'ensemble des cas d'utilisation génériques. 11/11/07 Version / 77

7 2 Etude technique Cette etude technique nous permettra de mettre en évidence les différents besoins techniques recensés par l'équipe afin de réaliser le logiciel OPS. Nous allons donc présenter les différents logiciels et bibliothèques que nous allons utiliser pour développer notre solution. 2.1 Architecture logicielle Dans un premier temps, nous allons présenter l'architecture logicielle du logiciel OPS qui s'appuie sur la technologie Java Entreprise Edition 5. Il s'agit d'une technologie 3 tiers comprenant : une couche de présentation, elle intéragit avec l'utilisateur et présente les données en communiquant avec la couche métier une couche de logique métier, elle réalise les traitements métier et c'est la passerelle entre la couche données et la couche présentation. une couche d'accès au données, elle assure l'accès au données en gérant la persistance de ces dernières dans la base de données. Nous présentons ci-dessous un schéma simplifié de l'architecture logicielle. 11/11/07 Version / 77

8 Illustration 1: Architecture logicielle OPS La figure nous permet de distinguer facilement les différentes couches du modèle JEE5. Couche présentation : Le logiciel OPS offre deux interfaces utilisateurs : un client léger et un client lourd. Le client lourd est une application externe développé en Java 1.5. La couche présentation est donc assurée par une interface graphique Java développé en Swing, AWT, ou tout autre API graphique Java. Le client léger accède à l'application grâce à un navigateur Web dans lequel il va visualiser les pages générées par le conteneur Web. Un conteneur web se compose de différements éléments : Servlets, ce sont les classes qui analysent les requêtes HTTP envoyées par le client léger. Ils générent ensuite les réponses qui seront transmises au serveur Web afin d'être envoyées au client. 11/11/07 Version / 77

9 JSP ou Java Server Pages, cette technologie permet de générer dynamiquement des pages Web en y insérant des fragments de code Java. Les possibilités du conteneur Web peuvent être améliorées à l'aide de framework d'applications Web. Ces frameworks fournissent des composants graphiques Web préfabriqués et simples à utiliser. Nous utiliserons un ou plusieurs framework dans le cadre du développement de notre client léger, les frameworks choisis seront décrit plus tard dans ce document. Couche métier : La couche métier est assurée par le conteneur d'ejb. Il contiendra des classes ayant des responsabilités différentes : Les classes offrant les sessions clientes afin que ceux-ci bénéficient de tous les services offerts par les classes présentes dans le conteneur d'ejb. Les EJBs sessions sont donc les points d'entrée client dans le conteneur d'ejb. Les classes permettant la lecture, l'ajout, la modification et la suppression de données métier : les EJBs entity. Des classes seront chargées de la vérification de la cohérence des données durant ces opérations. Les classes assurant les traitements des données métier, comme par exemple la génération d'un planning de soutenance. Les classes assurant la persistance des données entre les objets métier et leur représentation en base de données. Couche de données : La couche de données est représentée par la base de données Choix du serveur d'applications Dans le but de mettre en place notre architecture logicielle, il va tout d'abord falloir choisir quel serveur d'applications nous allons utiliser. En effet, de nombreux serveurs ont été développés, chacun ayant ses particularités. Nous avons donc étudié les différentes 11/11/07 Version / 77

10 solutions pour choisir la plus apte à répondre à nos besoins durant ce projet JBoss Le serveur d'applications JBoss est développé par une division de l'entreprise Red Hat, célèbre pour sa distribution Linux du même nom. JBoss est un logiciel open source sous licence LGPL. De plus, grâce à la licence LGPL, l'utilisation de JBoss dans un projet n'oblige pas l'utilisateur à rendre son code source libre. JBoss 4.2 offre tous les services définis par le Java EE 2 (Servlets, JSP, EJBs, etc) mais il propose également quelques fonctionnalités introduites dans la technologie Java EE 5 (nouveaux JSP et EJBs, etc). Cependant il n'implémente pas entièrement les spécifications Java EE Tomcat Tomcat est une implémentation partielle des spécifications Java EE 5. En effet Tomcat n'intégre qu'un conteneur de Servlet/JSP et un serveur HTTP interne. Ce logiciel open source a été développé par un groupe de travail appartenant au projet Apache, il est placé sous licence LGPL. Tomcat, actuellement en version 6, est donc un serveur d'applications léger qui n'offre que les fonctionnalités Web d'un serveur Java EE Glassfish GlassFish est un logiciel libre réalisé par Sun et une communauté active de développeurs. Il sert de base à un autre serveur d'applications Sun : Sun Java System Application Server Platform Edition 9.0. GlassFish est certifié Java EE 5, il est sous double licence CDDL (licence open source crée par Sun MicroSystems) et GPLv2 (licence dont dérive la LGPL). La version 2 de GlassFish, qui intégre le JEE5 est disponible depuis le 17 septembre Il est l'un des seuls serveurs d'applications qui implémente intégralement les fonctionnalités de la technologie JEE5. Le fait que GlassFish soit développé par les 11/11/07 Version / 77

11 fondateurs de Java (Sun MicroSystems) nous assure que le logiciel sera stable et de qualité malgré sa jeunesse Solution retenue Nous pouvons donc résumé les présentations des serveurs d'applications grâce au tableau comparatif suivant : Critères JBoss Tomcat Glassfish Support Solaris Oui Oui Oui Logiciel Libre Oui Oui Oui Servlets / JSP Oui Oui Oui EJB EJB 3 Pas d'ejb EJB 3 Certification Java EE J2EE 1.4 J2EE 1.4 Java EE 5 Intégration aux IDE Oui Oui Oui Communauté utilisateurs Très Grande Très Grande Très Grande C'est donc le serveur d'applications Glassfish sur lequel nous nous appuierons car il implémente entièrement les spécifications Java EE 5, ce qui lui permet d'être certifié JEE5 par Sun MicroSystems. 2.2 Développement des clients Nous allons maintenant décrire les besoins engendrés par le développement d'un client léger et d'un client lourd, et choisir les solutions y répondant Client lourd La solution logicielle que nous avons proposé au client dans le cahier des charges offre la possibilité d'utiliser un client lourd. Ce dernier va intégrer une interface graphique réalisée en Java à l'utilisateur. Elle lui permettra de naviguer à travers toutes les fonctionnalités offertes par OPS. Nous devons donc choisir la librairie que nous allons utiliser pour réaliser l'interface graphique du client lourd. Pour cela nous allons présenter les deux librairies graphiques certifiées par Sun Microsystems. 11/11/07 Version / 77

12 AWT Il s'agit de la première bibliothèque graphique Java apparue en version 1.0. Elle sert de base à d'autres librairies telle que Swing que nous verrons ensuite. Le principal inconvénient d'awt est qu'elle emploie des composants natifs de la plate-forme, ce qui n'assure pas la portabilité certaine d'une interface graphique réalisée avec AWT. En effet des différences de comportements ou d'affichage peuvent exister entre un même programme s'exécutant sur deux systèmes d'exploitations différents Swing Swing est apparue en version Java 1.2, il se base sur la librairie AWT. La grande innovation qu'apporte cette librairie est la réalisation d'interfaces graphiques identiques indépendamment de la plate-forme de déploiement. C'est la librairie la plus utilisée dans le monde Java, et c'est celle que l'équipe maîtrise le mieux. Nous allons donc nous tourner vers la bibliothèque Swing pour réaliser l'interface graphique du client lourd Client léger Le client léger permet à l'utilisateur d'accéder aux fonctionnalités offertes par le serveur d'applications via un navigateur Web. Le serveur d'applications va donc devoir être capable d'interpréter ou de créer des pages HTML pour dialoguer avec le client léger. Cette fonctionnalité est assurée par des technologies intégrées à la norme Java EE 5 : Les Servlets. Les JSP. Nous avons expliqué le rôle de ces deux technologies dans la partie dédiée à la présentation de l'architecture Java EE 5. En plus de ces deux technologies, nous allons certainement utiliser un framework d'applications web. Un framework est un ensemble d'outils, de librairies et de conventions permettant le développement rapide d'applications (Web dans notre cas) faciles à maintenir. 11/11/07 Version / 77

13 Nous présenterons ultérieurement différents frameworks qui seront susceptibles d'être utilisés. 2.3 Bases de données La solution logicielle que nous avons proposé dans le cahier des charges précise qu'une base de données sera présente dans notre architecture. Une base de données a pour rôle de stocker des informations organisées dans des tables. Ces données peuvent être ensuite récupérées de manière rapide grâce à des requêtes adressées au serveur. Ces requêtes respectent le format définit par la norme SQL99 (Structured Query Language). Dans le cadre de notre projet, la base de données servira à stocker toutes les informations (coordonnées et disponibilités) concernant les participants aux soutenances (apprentis, tuteurs et tous les autres membres du jury), ainsi que les plannings et certains paramètres de notre application. Nous nous sommes penchés sur deux gestionnaires de bases de données MySQL MySQL est un système de gestion de bases de données (SGBD) relationnel. Le terme relationnel signifie que les données sont stockées dans des tables reliées par des relations définies par le créateur des tables. Ces relations permettent la combinaison des données entre plusieurs tables durant une requête. MySQL est un logiciel open source sous licence GPL, il est donc libre de téléchargement et d'utilisation. Il respecte le standard SQL 99, qui est la norme qui nous a été enseignée dans le cadre de nos cours sur les bases de données. Aujourd'hui disponible en version 5, il était surtout apprécié par les développeurs Web pour sa rapidité de traitement des requêtes par rapport à PostgreSQL. Cependant cet avantage tend à s'estomper voire même à disparaître depuis les dernières versions de PostgreSQL qui a énormément progresser en terme de rapidité de traitement des requêtes. 11/11/07 Version / 77

14 2.3.2 PostgreSQL A l'instar de MySQL, PostgreSQL est un SGBD relationnel respectant le standard SQL 99. C'est un logiciel libre sous licence GPL. PostgreSQL est reconnu pour offrir des possibilités qui ne sont pas disponibles avec MySQL, comme les langages procéduriaux ou les «sous sélections» durant les requêtes. Nous ignorons encore si de telles fonctionnalités nous seront utiles de façons certaines dans ce projet. Cependant dans le cas où elle le seraient, cela nous évitera de devoir gérer l'absence de ces fonctionnalités par un bloc logiciel dans notre programme. De plus, depuis la version 7.1, il rivalise avec MySQL en terme de rapidité d'exécution des requêtes. PostgreSQL est actuellement disponible en version 8.2. PostgreSQL, comme MySQL, gère l'aspect transactionnel des opérations sur base de données, ce qui est important pour notre application qui devra s 'assurer de l'atomicité des modifications sur les plannings Solution retenue Le tableau comparatif suivant nous permet de présenter ces deux outils de manière synthétique : Critères PostgreSQL MySQL Support Solaris OUI OUI Taille maximum d'une table 32 To 4Go Support des langages de procédures OUI NON Support des procédures stockées OUI OUI (version 5.0 seulement) Support des sous sélections lors des requêtes OUI NON Drivers JDBC OUI OUI Support des transactions OUI OUI Communauté utilisateurs Très Grande Très Grande 11/11/07 Version / 77

15 Notre choix se porte sur le gestionnaire PostgreSQL pour plusieurs raisons. Tout d'abord il possède plus de fonctionnalités que son homologue MySQL et offre, d'après nos recherches, une robustesse supérieure à celui-ci. Enfin, PostgreSQL est le gestionnaire de bases de données utilisée par le Centre de Ressources Informatique (CRI) de l'université de Marne-la-Vallée, ce qui nous permettra d'utiliser nos bases de données étudiantes lors des tests durant la phase de développement et de faciliter la mise en production de l'application. 2.4 Librairies Pour interagir avec d'autres sytèmes ou applications, notre projet va devoir utiliser différentes librairies ou interfaces de programmation (Application Programming Interface ou API). Nous avons défini celles que nous devrons utiliser pour développer les fonctionnalités que devra offrir notre application Librairie de gestion du format Microsoft Excel L'une des contraintes fonctionnelles dictées par le client est la possibilité de peupler une partie de la base de données à partir d'un listing sous forme de feuilles de calcul Microsoft Excel. Ce listing sera composé des coordonnées des apprentis des différentes filières, mais aussi de celles des tuteurs ingénieurs et enseignants associés à ces apprentis. L'objectif est donc de trouver une librairie Java permettant de manipuler des fichiers Microsoft Excel et deux bibliothèques peuvent potentiellement répondre à ce besoin JExcelAPI Cette bibliothèque permet la lecture et l'écriture de fichiers Microsoft Excel au format 97 à Sachant que le client n'utilise pas la version 2007 du logiciel l'api convient parfaitement à la lecture des fichiers clients qui seront en version 2003 au maximum. Dans le cas ou le client passerait un jour en version supérieur à 2003, il faudra qu'il sauvegarde ces fichiers Excel au format 2003 avant de les fournir à notre application. 11/11/07 Version / 77

16 Elle supporte le format des dates, des polices et des formules de calculs à partir de la versions 97. La librairie n'offre pas la possibilité de créer ou de modifer des macros, cependant elle n'altère pas les macros existantes sur un fichier Apache POI Le projet Apache POI a été réalisé par un sous groupe de travail du projet Apache. Il se compose de plusieurs sous-projets ayant pour but de fournir des librairies Java permettant de lire et d'écrire des fichiers au format Microsoft. Parmi ces différents sous-projets, c'est le projet HSSF qui nous intéresse particulièrement. En effet c'est ce dernier qui a permis la réalisation d'une librairie Java permettant la lecture et l'écriture des fichiers formatés par Microsoft Excel en version supérieure ou égale à Solution retenue Les deux librairies offrent des fonctionnalités similaires, cependant JExcelAPI se révèle être dix fois moins lourde que Apache POI (24Mo contre à peine 2Mo pour JExcelAPI). En effet il ne semble pas possible de télécharger seulement le module HSSF (librairie Microsoft Excel) du projet Apache POI. La qualité des documentations et l'activité des développeurs des librairies étant bonne pour JExcelAPI (dernière mise à jour en aout 2007), nous allons nous tourner vers cette solution simple et légère Librairie d'envoi de mails OPS propose à l'utilisateur d'envoyer les convocations aux soutenances par courriers électroniques. Ces convocations pourront être adressées à tous les participants d'une soutenance : les apprentis et les membres du jury. Cependant le client nous à préciser qu'il ne compte utiliser cette fonctionnalité que pour les tuteurs enseignants. Afin de réaliser cette fonctionnalité, nous allons devoir utiliser une bibliothèque Java permettant d'envoyer des s. 11/11/07 Version / 77

17 Une librairie s'impose pour combler ce besoin. Développée par Sun Microsystems, JavaMail permet de modéliser des courriers électroniques et de les envoyer au format MIME. La norme Multipurpose Internet Mail Extensions (MIME) est un standard internet qui étend le format de données des s pour supporter des contenus multiples : différents codage de caractères, images, vidéos, etc. La possibilité de modéliser à souhait un courriel répond parfaitement au besoin du client qui souhaite contrôler le format des s envoyés. Cette librairie est documentée de façon simple et complète, ce qui facilitera la prise en main par l'équipe de développement. Actuellement JavaMail est disponible en version 1.4 et est compatible avec Java 1.4 ou supérieur. Il est également à noter que cette bibliothèque est incluse dans les serveurs d'applications JEE Librairie d'authentification utilisateurs Le logiciel OPS sera utilisé par des personnes de l'université de Marne La Vallée qui devront s'authentifier pour accèder au logiciel OPS. Elles ont déjà des comptes utilisateur créés sur le système d'information de l'université qui est mis en place par le CRI (Centre des Ressources Informatiques). Nous allons donc devoir nous interfacer avec l'annuaire informatique de l'université qui contient ces comptes utilisateurs. Ceci dans le but d'éviter une redondance des informations. Un annuaire informatique est un système qui stocke des données pérennes, telles que les coordonnées des utilisateurs d'un système d'information. L'université de Marne-la-Vallée utilise un annuaire LDAP (Lightweight Directory Access Protocol). Nous allons donc avoir besoin d'une librairie Java nous permettant d'aller récupérer des informations (nom d'utilisateur et mot de passe) contenues dans l'annuaire LDAP JAAS L'API Java Authentifaction and Authorization Service est fournit avec le kit de 11/11/07 Version / 77

18 développement de Java EE 5. Elle permet, entre autre, à des applications d authentifier des utilisateurs et d appliquer des contrôles d accès suivant plusieurs méchanismes, comme LDAP qui nous intéresse particulièrement. Par exemple, cette bibliothèque offre aussi des fonctionnalités de cryptographie JGuard JGuard est un framework de sécurité basé sur JAAS, il require un environnement Java 1.4. Ce framework est conçu dans le but de gérer l authentification et les droits d'accès à des applications. L'avantage majeur de ce framework est que les informations sur les utilisateurs peuvent être stockées dans des base des données, des annuaires LDAP, des fichiers XML, etc. De plus les utilisateurs peuvent bénéficier des droits associés à divers rôles. Par exemple, dans le cadre du logiciel OPS, il sera facile de définir à le cellule alternance les droits d'administration grâce à JGuard. Enfin les différents droits d'accès des utilisateurs sur une application données peuvent être modifiés constamment grâce à une API fournit par le framework Librairie PDF Le logiciel OPS va proposer de générer les convocations au format PDF afin de les envoyer par ou de les imprimer pour un envoi ultérieur par courrier postal. Les convocations crées s'appuieront sur un modèle fournit par l'utilisateur. Le template servant de base pour générer les convocations sera un fichier OpenOffice (ODT) crée par la cellule alternance. Enfin, il sera aussi possible d'exporter un planning au format PDF afin de pouvoir le diffuser de manière électronique aux personnes n'ayant pas accès à la consultation des plannings via le logiciel OPS. Nous allons nous interesser à diverse librairies Java qui nous permettrons de manipuler des fichiers PDF et ODT JODReports Ce projet était autrefois appellé JOOReports (Java OpenOffice Reports) mais il a été renommé en JODReports afin d'appuyer sur le fait que le format OpenDocument est maintenant un standard. 11/11/07 Version / 77

19 Java OpenDocument Reports est une librairie Java, open source sous licence LGPL, permettant de générer des documents de façon dynamiques en insérant des données dans un template de document pré-défini. Les fonctionnalités principales offertent par cette bibliothèque sont : Les templates peuvent être créer avec un logiciel de traitement texte, l'utilisation de OpenOffice est recommandée. Les données peuvent être importées de nombreuses manières : variables, fichiers XML, objets Java. Les fichiers ODT générés peuvent être converti au format PDF en utilisant la librairie JODConverter JODConverter JODConverter (anciennement JOOConvertor) est une librairie Java open source sous licence LGPL. Elle permet la conversion entre différents formats de documents, tels que : Tous les formats Microsoft vers OpenOffice, et vice versa. Tous les formats Microsoft et OpenOffice vers le format PDF. Tous les formats vers du HTML. C'est un outil puissant qui peut être utilisé conjointement avec JODReports pour répondre à nos besoins gnujpdf La librairie gnupdf est sous licence GPL, elle a été crée dans le but d'être utilisée dans des applications Java EE. En effet, une fonctionnalité qui est souvent requise par ces applications est de pouvoir visualiser ou imprimer des documents générés dynamiquement. Or, de plus en plus d'entreprise utilise le standard PDF. La bibliothèque gnupdf offre la possibilité de créer des fichiers PDF en «dessinant» dans un fichier grâce à des sous classes de java.awt.graphics. Ainsi un document visualisé dans une applet ou une application Swing peut être imprimé puis converti au format PDF. En résumé, à chaque fois que l'utilisateur appelle une methode drawstring() ou drawimage(), au lieu de dessiner sur l'écran, il peut dessiner dans un fichier PDF. 11/11/07 Version / 77

20 itext itext est une librairie sous licence LGPL qui permet de générer des fichiers au format PDF. Elle est parfaite d'utilisation pour les personnes voulant doter leur applications Web d'une capacité à générer et manipuler des fichiers PDF. La bibliothèque permet par exemple de : Générer un fichier PDF à partir de données utilisateurs : documents XML, ou informations stockées dans une base de données. Manipuler des fichiers PDF, concatenation, découpage ou modification du contenu. Remplir automatiquement un formulaire au format PDF. La librairie itext nécessite un environnement Java 1.4 ainsi que d'autre librairies accessibles facilement depuis le site du projet itext Solutions retenues Dans le cadre de la génération des convocations à partir d'un modèle de document OpenOffice, il semble que le couple JODReports et JODConverter corresponde exactement à nos attentes. Enfin, pour l'export des plannings en fichier PDF, nous allons nous tourner vers gnujpdf. En effet, à partir de l'affichage des plannings via l'interface graphique Swing présente sur le client lourd, nous allons pouvoir facilement générer des fichiers PDF Librairie pour la génération du planning Le besoin principal qui justifie la création du logiciel OPS est la possiblité de créer les plannings des soutenances de manière automatique. Cependant, la génération d'un planning doit respecter un grand nombre de contraintes qui nous ont été précisées par le client. La création des plannings résulte donc de la résolution de ces contraintes, ce qui s'avère extrêmement difficile à faire sans utiliser d'outil spécialisé. Ces outils sont appelés des librairies de résolution de contraintes ou Constraint Programming en anglais. Nous allons donc tenter de faire un tour d'horizon des bibliothèques existantes. 11/11/07 Version / 77

21 Principe du Constraint Programming Une contrainte est une relation simple entre plusieurs variables pouvant chacunes prendre des valeurs dans un domaine donné. Le principe de la programmation par contraintes est de résoudre un problème en définissant des contraintes qui doivent être satisfaites par la solution. Pour cela, chaque variable du problème se voit attribué un domaine représentant ses valeurs possibles, puis les contraintes entre les variables sont modélisées. Les problèmes sont souvent solutionnés par le principe du «backtracking» qui consiste à faire des hypothèses jusqu'à ce que la solution en cours d'investigation respecte l'ensemble des contraintes. Le principe revient à explorer toutes les branches d'un arbre jusqu'à trouver celle qui conduit à la solution respectant les contraintes définies Choco Choco est une librairie Java permettant de résoudre des problèmes grâce à la méthode du Constraint Programming. Cette bibliothèque est sous licence LGPL et possède une documentation complète de l'api ainsi que des exemples d'utilisations JaCop Cette librairie écrite en Java 1.5 sous licence GPL permet la résolution de systèmes contraints. Cependant le site officiel est difficilement accessible et il est très pauvre en contenu : documentation et exemples JCream JCream est une bibliothèque Java open source sous licence LGPL permettant d'effectuer de la programmation par contraintes. Elle offre de nombreux algorithmes d'optimisation tels que «Simulated Annealing» ou «Taboo Search». En ce qui concerne sa documentation, elle est correcte mais nettement moins complète que celle de Choco JGap JGap est une librairie sous LGPL offrant une implémentation des algorithmes génétiques qui est une autre méthode algorithmique permettant, entre autre, de résoudre des 11/11/07 Version / 77

22 problèmes comportant des contraintes. La bibliothèque offre une documentation et des tutoriaux complets, cependant il semble que cette librairie remplisse des fonctions bien au dela de nos besoins. Elle comporte un nombre important de paquetages, classes et fonctionnalités. Nous allons donc certainement nous diriger vers une librairie plus simple Bilan Nous ne sommes que très peu familiarisé avec le principe du Constraint Programming, c'est pour cela que nous allons nous tourner vers l'utilisation de Choco qui est de loin le projet le plus documenté et garde une certaine simplicité tout en répondant à nos besoins. Ceci constitue un avantage important pour la prise en main par l'équipe. 2.5 Frameworks Dans cette partie, nous allons présenter les différents frameworks qui pourrait nous être utiles dans le développement de ce projet. Enfin, nous choisirons ceux qui correspondent le plus à nos besoins Frameworks application Web Struts Apache Struts a été créé par Craig McClanahan et est développé par la fondation Apache depuis Struts est un framework offrant un cadre standard pour développer des applications Web JEE5 respectant le modèle MVC (Modèle-Vue-Controleur). Le modèle MVC est une architecture qui sépare les couches, présentations, données et traitements. De cette manière si une couche change, les deux autres ne sont pas, ou peu modifié. Cela offre une maintenance de l'application relativement simplifiée. Cependant Struts montre toute sa puissance dans des applications de grande ou moyenne envergure. Il peut être inadapté dans des projets de petite taille car il est complexe à mettre en oeuvre Java Server Faces A l'instar Struts, JSF à été crée par Craig McClanahan en C'est un framework de 11/11/07 Version / 77

23 développement d'applications Web JEE5 permettant de respecter le modèle MVC. Ce framework offre : un mapping entre les objets et le code HTML correspondant, la possibilité de créer des composants, en plus de la multitude proposée par JSF, le support de différentes technologie d'affichage : HTML, XML, flash, etc, une configuration plus simple que celle de Struts Tapestry Tapestry est un framework open-source, sous licence Apache, qui permet de créer des applications Web utilisant une architecture basé sur des clients légers. Il s'appuie sur n'importe quel conteneur de servlets respectant la norme Java EE. Il peut donc être utilisé avec n'importe quel serveurs d'applications. Tapestry permet d'apporter la notion de développement orienté objets aux applications Web. Il comprend plus de cinquante composants Web graphique pré-définis, mais l'utilisateur peut créer très facilement ses propres composants. Enfin, Tapestry se veut efficace autant pour des applications Web de petites tailles, que pour des projets de grandes envergures Bilan En ce qui concerne les frameworks d'applications Web, nous avons choisi d'utiliser Java Server Faces qui est intégré à la norme JEE5 et sur lequel de nombreux framework viennent s'appuyer Frameworks de persistance des objets Nous allons utiliser la technologie Java Persistance API (JPA) dans notre projet afin de facilement manipulés des objets ayant une representation dans une base de données. Il existe principalement deux implémentations de JPA : Hibernate et TopLink Hibernate Hibernate est un framework open source sous licence GPL gérant la persistance des objets en base de données relationnelle. Il permet le mapping objet/relationnel qui 11/11/07 Version / 77

24 consiste à faire le lien entre la représentation objet des données et sa représentation relationnelle. Cela permet de travailler efficacement avec le contenu d'une base de données relationnelle depuis notre code source Java. Hibernate permet de synchroniser facilement le contenu d'une base de données avec une application Java. Il analyse une base de données existante pour générer les classes Java correspondantes. L'inverse est également possible grâce à la création automatique des requêtes SQL nécessaires pour créer une base de données capable d'accueillir des classes Java Toplink Le framework Oracle Toplink est le plus sérieux concurrent de Hibernate concernant la gestion de la persistance des données. Comme Hibernate, il implémente la norme EJB 3,0 et est donc supporté par la plupart des serrveurs JEE5. Il est à noter que l'implémentation de JPA dans Glassfish est basée sur celle de Toplink Bilan Chaque implémentation offre des services supplémentaires qui ne sont pas définit dans la norme JPA. Cependant, etant donné que nous allons nous contenter d'utiliser les fonctionnalités spécifiés par la norme JPA, le choix de l'implémentation nous importe peu. Nous choisissons donc TopLink car il sert de base à l'implémentation de JPA dans le serveur d'application que nous avons choisi : GlassFish Frameworks AJAX Dans le cadre du développement de la partie client léger du logiciel OPS, nous allons certainement être amené à utiliser la technologie AJAX. L'AJAX permet de mettre à jour une zone ou un objet graphique d'une page, et ceci de manière transparente pour l'utilisateur. Pour ce faire, le browser du client va envoyer une requête particulière au serveur, qui va lui renvoyer les informations nécessaires au rafraichissement de la zone concernée. 11/11/07 Version / 77

25 Nous allons donc étudier quelques frameworks AJAX susceptibles de nous intéresser dans le cas ou nous utilisons cette technologie JBoss RichFaces Le framework RichFaces, libre et open source, permet d'intégrer facilement la technologie AJAX dans un projet de développement d'application. Il est développé par la communauté JBoss. Il offre une riche librairie de composants à utiliser dans le framework JSF, ce qui offre un gain de temps et une facilité de développement aux développeurs. RichFace permet aussi à l'utilisateur de créer ces propres composants, ou de changer l'apparence de ceux existants. Grâce à ce framework, nous allons pouvoir actualiser un composant ou une partie d'une page Web à la suite d'une «requête AJAX», ceci de manière transparente pour le client. Enfin ce framework permet au développeurs d'utiliser la technologie AJAX sans avoir à faire de développements JavaScript ICEfaces ICEfaces est un framework AJAX qui permet aux applications Java EE de créer et de déployer des clients légers offrant une interface graphique riche et complexe. Il se base sur l'environnement d'éxecution offert par les serveurs d'applications Java EE. Les applications réalisées grâce au framework ICEfaces se base sur la technologie JavaServer Faces (JSF). ICEfaces est un framework offrant des fonctionnalités similaires à RichFaces jmaki Le projet JMaki offre la possibilité d'encapsuler des composants JavaScript afin de pouvoir les utiliser dans un framework JSP. Il permet donc d'utiliser des librairies JavaScript, utilisées normalement coté client, dans une application réalisée utilisant JSF. JMaki encapsule de façon native quelques librairies JavaScript très utilisées comme par exemple Dojo. Pour encapsuler un nouveau composant, l'utilisateur doit définir trois fichiers : Un template HTML qui spécifie la mise en page du composant Un fichier CSS qui précise les paramètres de style à appliquer au composant 11/11/07 Version / 77

26 Un fichier JavaScript qui contient le code javascript décrivant les différents états et comportements du composant. La librairie JMaki peut donc nous permettre d'utiliser une multitude de composants définit dans les différentes librairies JavaScript existantes Bilan Nous allons nous tourner vers l'utilisation du framework JMaki qui a l'avantage d'être présent nativement sur la dernière plateforme Netbeans. 11/11/07 Version / 77

27 3 Conception du logiciel Dans cette partie, nous allons présenter le découpage en paquetage de l'application OPS. Pour chaque paquetage nous détaillerons son rôle et les classes qui le composent. Enfin nous décrirons les responsabilités de chaque classe, en précisant les différents designs pattern utilisés. L'application OPS se compose de trois paquetages principaux : «ops.server» contient tous les sous paquetages métier de l'application. «ops.heavyweight» aura pour responsabilité de réaliser la couche présentation offerte par le client lourd. «ops.common» regroupe toutes les classes qui seront utilisées à la fois par le client lourd et le client lourd. Illustration 2: Diagramme de paquetages général 3.1 Généralités sur les diagrammes de classes et paquetages Toutes les classes et leur méthodes qui vont être présentées dans les différents diagrammes sont amenés à être modifiés dans un avenir proche : durant le développement de la V1. En effet, les listes des méthodes de chaque classes ne sont pas exhaustives. Elles sont là pour illustrer de manière générale le rôle que nous avons donné 11/11/07 Version / 77

28 à chaque classe. Ainsi nous serons aménés à ajouter des méthodes à des classes afin de fractionner leurs fonctionnalités, et de ce fait faciliter leur développement. De la même manière, certains paquetages pourront se voir ajouter des sous paquetages. En effet nous n'avons pas une visibilité claire sur toute l'application, notamment sur les paquetages à livrer dans les dernières versions. Même si certains paquetages ne sont pas présents dans le diagramme, nous avons défini plusieurs règles dans la structure de nos paquetages : Tous les paquetages contiendront un sous paquetage «exceptions» qui contiendra les exceptions qu'ils manipulent, Les interfaces seront à la racine des paquetages, et les implémentations se trouveront dans un sous paquetage «impl». Nous allons maintenant détailler chaque paquetages ainsi que les classes qui le composent. 3.2 Paquetage «ops.server» Il contient tous les sous paquetages et classes métier du logiciel OPS, à l'exception des données metier qui sont dans le paquetage «ops.common.entities». «ops.server.session» : contient les EJB sessions qui fournissent aux clients des passerelles vers les différents services offerts par le serveur. «ops.server.core.dao» : services d'accès au données métier (les EJB entity). «ops.server.core.processing» : services de traitement des données. «ops.server.lighweight» : contient les servlets et les JSP qui réalisent la couche présentation du client léger. «ops.server.auth» : assure l'authentification et les gestion des droits des utilisateurs connectés à l'application. 11/11/07 Version / 77

29 Illustration 3: Paquetage "server" Paquetage «server.session» Le paquetage «server.session» utilise le design pattern SessionFacade. En effet, il ne contient que deux EJB Session qui offrent aux clients des interfaces vers tous les services proposés par le serveur. Remote Interface «HeavySessionFacade» : c'est une EJB session stateful accessible seulement par des clients distants (clients lourd dans notre cas). Local Interface «LightSessionFacade» : c'est une EJB session stateless accessible uniquement par des clients locaux : servlets, JSP. 11/11/07 Version / 77

30 Illustration 4: Paquetage "server.session" Les deux SessionFacade déclarent pour le moment les mêmes méthodes car nous n'avons inclus que les CRUD à réaliser en V1 : CRUD des participants et des disponibilités. Ces fonctionnalités étant accessibles depuis les clients lourd et légers, ils sont présents dans les deux interfaces. Ces deux interfaces seront modifiées au fur et à mesure des versions afin d'y ajouter les nouveaux services offerts par chaque version du logiciel OPS. Par exemple nous ajouteront par les suites des méthodes permettant de s'authentifier, ou de générer les plannings, etc. Cependant, comme nous n'avons pas encore entièrement reflechi à l'architecture exacte des paquetages à développer aux versions suivantes, nous n'avons 11/11/07 Version / 77

31 inclus que les méthodes qui seront implémentées à la V Paquetage «server.core.dao» Ce paquetage offre tous les services relatifs aux objets entités : Create, Read, Update, Delete. Il doit aussi garantir que les entités soit bien écrites dans la base de données : le paquetage assure donc la persistance des données. La persistance est assurée via l'objet EntityManager fourni par l'implémentation JPA que nous avons choisis : TopLink. Les opérations CRUD étant génériques à toutes les entités, les deux classes du paquetages possèdent des méthodes generiques. Illustration 5: Paquetage "server.core.dao" Classe EntityService : elle a pour rôle de vérifier la cohérence des objets entités avant de les transmettre à la DAO. De plus c'est elle qui s'assure de la possibilité d'effectuer l'action demandée. Si l'action ne peut pas être réalisée, la méthode lèvera une exception pour prévenir le client du problème. Par exemple, lors de la création d'un participant c'est la classe EntityService qui s'assurera qu'un participant ayant les même informations n'existe pas déjà. Dans ce cas une exception est lancée et une notification est envoyée au client pour savoir si il souhaite créer un doublon. Classe EntityDAO : elle permet, après vérification par la classe EntityService, d'assurer la persistance des entités manipulées dans la base de données. 11/11/07 Version / 77

32 3.2.3 Paquetage «server.core.processing» Ce paquetage contient les services d'accès aux traitements métier comme la génération de planning, de convocations ou l'import des participants à partir d'un fichier Excel. Etant donné que ces paquetages ne seront pas fournis en V1, nous n'allons pas détailler précisement leur contenu. Illustration 6: Paquetage "server.core.processing" Les classes ProcessingService : elles ont pour rôle d'offrir l'accès aux méthodes de traitements métier en cachant l'implémentation de ces dernières. Les classes Processing : elles sont les implémentations des traitements métier. 11/11/07 Version / 77

33 3.2.4 Paquetage «server.lightweight» Ce paquetage contiendra les différents Servlets et pages JSP dédiés à la gestion de la vue et des contrôleurs du client léger. Ce paquetage comprendra au moins un servlet ou une page JSP pour chaque fonctionnalités offertes par le client léger lors de la V1 : Visualisation de la liste des participants Modification d'un apprenti Modification d'un membre du jury L'architecture de ce paquetage n'est pas encore précisement définie, elle sera précisée durant le développement de la V Paquetage «server.auth» Le paquetage «server.auth» est composé par toutes les classes qui permettront d'assurer l'authentification et les gestion des droits des utilisateurs connectés à l'application via un client léger ou un client lourd. 3.3 Paquetage «ops.common» Le paquetage «ops.common» contient tous les paquetages qui sont utilisés par le serveur et le client lourd : «ops.common.entities» : contient tous les objets entités. Coté client, ils sont manipulés en local et envoyés vers le serveur pour être persistés. «ops.common.external» : fournit les services permettant d'utiliser les API externes. «ops.common.properties» : contient les ressources permettant de changer la langue de l'application. «ops.common.rules» : assure la vérification de la cohérence des objets ainsi que des données saisies par l'utilisateur via les interfaces graphiques des clients lourds ou légers. 11/11/07 Version / 77

34 Après cette brève description du paquetage «ops.common», nous allons décrire plus en détail chaque sous paquetage Paquetage «common.entities» Les objets entités étant utilisés par les clients et le serveur, nous avons décidé de placer ce paquetage dans «ops.common». En effet, si nous avions placé les entités dans le paquetage «ops.server.core.entities», nous aurions créé une dépendance entre des paquetage client et un paquetage se trouvant dans le coeur du serveur. C'est pour eviter cela que nous avons opté pour le premier choix. Le paquetage «common.entities» possédant beaucoup d'interfaces et de classes, nous allons présenter son architecture avec plusieurs diagrammes Généralités sur les entités Toutes les classes définissant des entités métier implémentent l'interface Serializable dans le but de pouvoir être persistés via JPA. Nous n'avons pas précisé les constructeurs de nos entités pour simplifier les diagrammes. De plus elle possèdent toutes une méthode «selfcheck» qui leur permet de vérifier leur cohérence. Cette méthode sera appelée par la classe «EntityService» du paquetage «server.core.dao» afin de vérifier les objets. La méthode «selfcheck» de l'entité fera simplement appel au paquetage «common.rules». Ce sont les classes de ce paquetage qui auront la responsabilité de s'assurer de la cohérence d'un objet. Nous allons détailler le paquetage «common.rules» dans la partie suivante. 11/11/07 Version / 77

35 Entités «Attendee» Nous présentons ci-dessous le diagramme de classe des entités representant les participants aux soutenances : apprentis et membres du jury. Interface Attendee : elle déclare toutes les méthodes qui permettront de manipuler l'ensemble des participants, que ce soit un apprenti ou un membre du jury. 11/11/07 Version / 77

36 Interface Availability : elle represente les méthodes qui offrent la manipulation des disponibilités. Classe AbstractAttendee : cette classe abstraite implémente les deux interfaces décrites ci-dessus. Elle offre la définition des méthodes qui seront applicables à des participants de type apprenti ou membre du jury. Classe Apprentice : elle hérite de AbstractAttendee et offre des méthodes supplementaires qui permettent de manipuler les champs présents dans la classe Apprentice. Par exemple, seul un apprenti possède des tuteurs et un candide. Classe JuryMember : la classe hérite aussi de AbstractAttendee. De la même manière que la classe Apprentice, la classe JuryMember ne définit que les méthodes manipulant des champs relatif au membre du jury. Par exemple ces derniers n'ont qu'une seul adresse, tandis que les apprentis en ont deux : adresse en période académique et professionnelle. Enfin les membres du jury comme les tuteurs ingénieurs sont rattachés à des entreprises. Enum Role : elle represente tous les rôles des participants d'une soutenance : apprentis, tuteur ingénieur, tuteur enseignant, professeur de communication, expert, candide et président du jury. Cette énumération est utilisée par la classe AbstractAttendee pour assigner un ou plusieurs rôles à un participant. Un «Apprentice» n'aura que le rôle apprenti, tandis qu'un «JuryMember» pourra se voir attribuer plusieurs rôles. Enum Field : elle represente les différentes filières présentes à l'ufr Ingénieurs Elle est utilisée par les instances de la classe «Apprentice» pour définir dans quelle filière un apprenti étudie Entités «OralPresentation» Dans le diagramme ci-dessous, nous allons montrer le diagramme de classe des entités représentant des soutenances. 11/11/07 Version / 77

37 Illustration 9: Entité "OralPresentation" Interface OralPresentation : elle déclare toutes les méthodes permettant de manipuler n'importe quel type de soutenance, que ce soit une SMI ou une SDA. Par exemple, tous les type de soutenances se caractérisent par un créneau horaire de déroulement et un numéro de salle. 11/11/07 Version / 77

38 Classe AbstractOralPresentation : cette classe abstraite implémente l'interface OralPresentation afin de définir les méthodes applicables aux deux type de soutenances : SMI et SDA. Classe EngineerOralPresentation : c'est l'entité qui represente une SMI. Elle étend la classe AbstractOralPresentation et définit de nouvelles méthodes propres à la manipulation d'une SMI. Elle permet de gérer les paramètres particuliers d'une SMI, tels que l'expert et le président présent durant la soutenance. Classe ApprenticeOralPresentation : elle hérite de la classe AbstractOralPresentation et y ajoute des méthodes propres à la gestion d'une SDA : modification du professeur de communication présent à la soutenance Entités «Planning» Le diagramme de classe que nous allons montrer ci-dessous représente les entités qui modélisent les plannings de soutenances. 11/11/07 Version / 77

39 Interface Planning : elle déclare les méthodes générales qui permettront de manipuler des plannings de SDA ou de SMI. 11/11/07 Version / 77

40 Interface Availability : elle represente les méthodes qui offrent la manipulation des journées, demi-journées ou plages horaires sur lesquelles s'étend le planning. Classe AbstractPlanning : cette classe abstraite implémente les deux interfaces-ci-dessus. Elle offre donc une définition des fonctions qui permettront de manipuler les deux types de plannings. La classe permettra de gérer les paramètres des plannings, tels que le nombre de salles ou les périodes de temps sur lesquelles se déroulent les différentes soutenances qui composent le planning. Classe EngineerOralPlanning : elle hérite de la classe AbstractPlanning et permet de manipuler les EngineerOralPresentation qui composent un planning. Classe ApprenticeOralPlanning : elle hérite de la classe AbstractPlanning et permet de manipuler les ApprenticeOralPresentation qui composent un planning. Pour les entités représentant les plannings, nous aurions pu faire une interface générique «Planning<T>» avec T le type de soutenance manipulé par le planning : ApprenticeOralPresentation ou EngineerOralPresentation. Il nous aurait suffit de faire deux implémentations de cette interface pour créer nos deux entités EngineerOralPlanning et ApprenticeOralPlanning. Cependant nous n'étions pas certains qu'une entité implémentant une interface générique puisse être persistée par JPA Entités «TimeRange» et «Company» Le dernier diagramme de classe de ce paquetage présente les entités permettant de représenter des créneaux horaires ainsi que des entreprises. 11/11/07 Version / 77

41 Interface TimeRange : elle déclare les méthodes qui permettent de manipuler un créneau horaire. La classe TimeRange est utilisée dans de nombreuses entités : Dans l'interface «OralPresentation» pour définir le jour et l'heure à laquelle se déroule une soutenance Dans l'interface «Attendee», afin de préciser les disponibilités d'un participant. Dans l'interface «Planning», dans le but de de déclarer la période sur laquelle le planning va s'etendre. Classe TimeRangeImpl : implémente l'interface TimeRange. Interface Company : cette interface contient toutes les méthodes permettant de représenter une entreprise. Elle est utilisée pour définir l'entreprise à laquelle 11/11/07 Version / 77

42 appartiennent les tuteurs ingénieurs. Classe CompanyImpl : implémente l'interface Company Classe EntityFactory Ces entités sont créées par des méthodes factory qui sont toutes regroupées dans la classe EntityFactory. Les paramètres des méthodes ne sont pas précisés pour plus de lisibilité dans le diagramme. De plus de nouveaux besoins peuvent apparaître et nous seront donc surement amenés à créer de nouvelles factories avec des arguments différents. Illustration 12: Classe "EntityFactory" Paquetage «common.rules» Ce paquetage contient toutes les classes ayant pour responsabilité de vérifier la cohérences des entités. Ces vérifications seront faites coté client pour plus d'interactivité. Mais elles seront aussi faites coté serveur pour éviter qu'un client n'implémentant pas les 11/11/07 Version / 77

43 vérifications puisse corrompre nos objets. Toutes les classes de ce paquetage ne sont pas instanciables, en effet elles ne contiennent que des méthodes statiques qui seront appellées par les methodes «selfcheck()» des entités décrites dans le paquetage précédent. Ces classes «rules» seront susceptibles de se voir ajouter des méthodes privées statiques (qui ne sont pas précisées dans le diagramme) afin de décomposer le code des méthodes «checkentity()». Nous proposons ci-dessous un diagramme présentant les classes du paquetage «common.rules». Illustration 13: Paquetage "common.rules" 11/11/07 Version / 77

44 Classe StringRules : elle contient des méthodes permettant de vérifier la validité des champs de type String d'une classe. Par exemple elle verifiera que les noms, prénoms ou respectent bien le format attendu par le système (pas de caractère spéciaux interdits, présence du «@» et du nom de domaine, etc). Les méthodes de cette classe seront utilisées par de nombreuses «EntityRules» comme par exemple «AttendeeRules» ou «AddressRules». Classe NumericRules : cette classe définit des méthodes offrant un service de validation des informations devant représenter une valeur numérique : numéro de téléphone ou année d'étude, etc. Ces méthodes seront appelées par des «EntityRules» comme «AddressRules» ou «AttendeeRules». Classe PlanningRules : elle a pour responsabilité de proposer des méthodes de vérification de la cohérence des entités de type «EngineerOralPlanning» et «ApprenticeOralPlanning». Classe AttendeeRules : offre des méthode permettant de vérifier la validité des instances de type «JuryMember» et «Apprentice». Classe OralPresentationRules : permet d'assurer la cohérence des objets «EngineerOralPresentation» et «ApprenticeOralPresentation». Classe CompanyRules : cette classe définit la méthode de validation de la cohérence des objets «Company» Paquetage «common.properties» Ce paquetage contient deux classes permettant de changer la langue de l'application OPS. 11/11/07 Version / 77

45 Classe ResourceBundleConstants : elle contient toutes les constantes qui seront modifiées lors d'un changement de langue. Classe ResourceBundleSingleton : elle permet de fournir l'unique instance du ResourceBundle permettant de changer la langue de l'application. Cette classe utilise le design pattern Singleton Paquetage «common.external» Ce paquetage fournit les services permettant d'utiliser les API externes au logiciel : Lecture d'un fichier Microsoft Excel, via JexcelAPI, dans le cadre de l'import des participants via une feuille de calcul Microsoft Excel (implémenté en V2), Conversion d'un fichier Microsoft Word vers un fichier OpenOffice, et d'un fichier OpenOffice vers un PDF, écriture dans un fichier PDF. Ces fonctionnalités seront 11/11/07 Version / 77

46 utilisées lors de la génération des convocations (implémenté en V3). Les APIs utilisés sont JODReports et JODConverter, Sauvegarde des plannings en fichier PDF via l'api gnujpdf (implémenté en V4), Solveur de contrainte dans le cadre de la génération de planning grâce à l'api Choco (implémenté en V3). Bien que la responsabilité de ce paquetage soit clairement définie, son design interne n'est pas encore précisement fixé etant donné que nous n'utiliserons pas ce paquetage lors de la V Paquetage «ops.heavyweigth» Ce paquetage regroupe toutes les classes qui auront pour rôle de créer et de contrôler l'interface graphique du client lourd. Nous distinguons trois branches principales dans la hiérarchie de paquetage du client lourd : «heavyweight.main» : contient la classe nécessaire au lancement du client lourd. «heavyweight.util» : est composé par des classes offrant des services utiles au bon fonctionnement de l'application (paramètre de configuration du client lourd), ou utilisés de nombreuses fois (session permettant de se connecter au serveur d'application). «heavyweight.gui» : ce paquetage contient les classes permettant de modéliser et de contrôler les différentes parties de l'interface graphique du client lourd. 11/11/07 Version / 77

47 3.4.1 Paquetage «heavyweight.gui.skel» Ce paquetage contient les classes ayant pour responsabilité de créer le squelette de l'interface graphique du client lourd : menu, barre d'état, etc. 11/11/07 Version / 77

48 Classe LoginFrame : cette classe aura pour rôle de créer la fenêtre permettant à l'utilisateur de se logger au démarrage de l'application, ou pendant son fonctionnement. Elle possède aussi une méthode qui sera appelée au lancement du client lourd afin d'afficher le splashscreen pendant le chargement du logiciel. Classe Configuration Panel : elle a la responsabilité de créer la fenêtre permettant de spécifier l'adresse du serveur d'application ou se trouve l'ops. Cette fenêtre sera lancée au premier démarrage du client lourd, ou dans le cas où le fichier de configuration contenant l'adresse du serveur est manquant. Classe SkeletonGUI : cette classe permet de créer le squelette graphique de l'application : barre de menu, barre d'état, le conteneur d'onglets et l'onglet d'accueil Paquetage «gui.attendee» Ce paquetage comporte deux sous paquetages «view» et «model» qui ont pour rôle de réaliser l'interface graphique de gestion des participants dans le client lourd. 11/11/07 Version / 77

49 Paquetage «gui.attendee.view» Les classe présentes dans ce paquetage auront pour rôle de créer tous les composants graphiques permettant la consultation et la gestion des participants. En ce qui concerne les comportements à associer avec les différents composants, pour des comportements simples, ces derniers seront implémentés directement dans la vue sous forme de classe anonyme. Dans le cas de comportements plus complexes, ils seront implémentés dans une classe qui sera placée dans le sous paquetage «controller». Ce paquetage n'est pas représenté dans ce document car nous n'avons pas encore de visibilité claire sur la difficulté des comportements à développer. Nous présentons ci-dessous un diagramme du paquetage «gui.attendee.view». Illustration 17: Paquetage "gui.attendee.view" Classe AttendeeToolbar : elle a pour responsabilité de créer la barre d'outils en rapport avec la gestion des participants. 11/11/07 Version / 77

50 Classe AttendeeViewPanel : cette classe a pour rôle de créer le panneau de visualisation de la liste des participants. Cette liste sera présentée à l'utilisateur sous la forme d'un tableau dont les colonnes seront les informations importantes au sujet du participant : nom, prénom, , etc. Classe AttendeeTableRenderer : elle étend la classe DefaultTableCellRenderer et aura la responsabilité du rendu graphique du tableau representant la liste des participants. Classe AttendeeDetailPanel : cette classe permet de créer les fenêtres permettant de visualiser les informations des participants de façon détaillée. Etant donné que les informations visibles ne sont pas les mêmes suivant le type de participant, la classe est dotée de trois méthodes : une pour la création des parties communes, et les deux autres pour les parties spécifiques à un type de participant (apprenti ou membre du jury) Paquetage «gui.attendee.model» Ce paquetage regroupe tous les modèles qui sont utilisés par les composants graphiques présent dans les différentes interfaces de gestion des participants. Pour le moment ce paquetage ne comporte qu'une seule classe. Cependant durant le développement, nous allons peut être remarquer que nous avons besoin de plusieurs modèles, comme des modèles de listes pour d'éventuels JList ou JCombobox. 11/11/07 Version / 77 Illustration 18: Paquetage "gui.attendee.model"

51 Classe AttendeeTableModel : cette classe hérite de AbstractTableModel et aura pour rôle d'être le modèle de données affiché par la JTable créée par la classe AttendeeViewPanel. La JTable sert de composant graphique pour représenter les participants et leur informations associées Paquetage «heavyweight.util» Ce paquetage est composé par des classes offrant des services utiles au bon fonctionnement de l'application, comme par exemple les classes servant au paramétrage du client lourd. Mais ce paquetage comporte également des classes très souvent utilisées par de nombreux paquetages. Par exemple la classe permettant d'obtenir l'objet session qui est utilisé pour accèder aux services fournis par le serveur d'application. 11/11/07 Version / 77

52 Classe SessionProviderSingleton : cette classe contient une méthode statique qui permet de récuperer l'instance unique de l'objet HeavySessionFacade. C'est cet objet session qui va offrir la possibilité d'accèder aux services offerts par le serveur d'application. Cette classe utilise le design pattern Singleton. Classe ConfigParameters : le rôle de cette classe est de sauvegarder ou de charger les paramètres du client lourd. Pour le moment l'unique paramètre que nous avons défini est l'adresse IP du serveur d'application. Cette classe va donc offrir un service de sauvegarde et de consultation de ce paramètre grâce à des méthodes statiques. 3.5 Evolution de la conception Comme précisé précédemment, la conception logicielle du présent document n'est pas exhaustive et détaille seulement les parties implémentées pour la première version de l'application. Cette partie sera complétée à chaque présentation d'une nouvelle version au client. 11/11/07 Version / 77

53 4 Cas d'utilisation génériques Ce chapitre regroupe l'ensemble des parties communes aux cas d'utilisation spécifiques du cahier des charges fonctionnel. Ces cas d'utilisation génériques s'appuient sur les briques logicielles décrites dans l'étude technique du présent document. 4.1 Cas d'utilisation de persistance Les utilisateurs d'ops auront besoin régulièrement d'accéder aux données de la base de données et d'écrire dans cette dernière. On trouvera donc un ensemble de cas d'utilisation génériques permettant de manipuler la base de donnée à l'aide de la brique logicielle de persistance, dans notre cas le framework TopLink Cas d'utilisation générique #1 : Créer une entité en base de données Ce cas d'utilisation aura lieu à chaque fois qu'un acteur souhaitera enregistrer des données de manière persistante. De ce fait ce cas d'utilisation générique est inclu dans des cas d'utilisation spécifiques décrits dans le cahier des charges fonctionnel. Sa priorité de développement est haute Description Lorsque l'utilisateur souhaite enregistrer une entité dans la base de données, il doit dialoguer avec le serveur d'applications qui va réaliser l'opération pour lui. Ce cas d'utilisation générique est inclu dans le cas d'utilisation #101 «Créer un participant» Acteurs Les acteurs concernés sont l'ensemble des acteurs des cas d'utilisation spécifiques cités ci-dessus. 11/11/07 Version / 77

54 Pré-conditions La base de données doit être créée et l'accès à celle-ci doit être configurée par l'administrateur Cas nominal Acteur(s) 1. L'utilisateur veut enregistrer une entité nouvellement créée. Système 2. Le système demande une session au SessionProvider. 3. Le système demande la création de l'entité à l'entityservice par l'intermédiaire du SessionFacade. 4. L'EntityService demande à l'entité de vérifier sa validité à l'aide des règles de conformité. [exception : #1_err_1] 5. L'EntityService vérifie la présence d'une entité identique dans la base de donnée par l'intermédiaire de l'entitydao. [exception : #1_err_2] 6. L'EntityService demande l'enregistrement de l'entité dans la base de données à l'entitydao. [exception : #1_err_2] [exception : #1_err_3] L'entité est enregistrée en base de données et le cas d'utilisation spécifique reprend à l'endroit où il avait appelé ce cas d'utilisation générique. 11/11/07 Version / 77

55 Flux alternatifs Acteur(s) 9. L'utilisateur choisit de créer un doublon. Système 7. L'EntityService vérifie la présence d'une entité identique dans la base de donnée par l'intermédiaire de l'entitydao. [exception : #1_err_2] 8. Une entité similaire existe déjà en base de données. Une notification est envoyée à l'utilisateur. Un doublon est enregistrée en base de données et le cas d'utilisation spécifique reprend à l'endroit où il avait appelé ce cas d'utilisation générique. Acteur(s) 12. L'utilisateur choisit de créer un doublon. Système 10.L'EntityService vérifie la présence d'une entité identique dans la base de donnée par l'intermédiaire de l'entitydao. [exception : #1_err_2] 11.Une entité similaire existe déjà en base de données. Une notification est envoyée à l'utilisateur. L'entité n'est pas créée en double dans la base de données et le cas d'utilisation spécifique ayant appelé ce cas d'utilisation générique reprend au niveau du flux alternatif correspondant Flux d'erreur #1_err_1 : L'entité à enregistrer n'est pas conforme aux règles en vigueur, une notification est envoyée à l'utilisateur. #1_err_2 : L'accès à la base de données est impossible, une notification est envoyée à l'utilisateur. #1_err_3 : L'écriture dans la base de données est impossible, une notification est envoyée à l'utilisateur. 11/11/07 Version / 77

56 Diagramme de séquence 11/11/07 Version / 77

57 Fonction Qualité Mesure Fonction Fréquence Priorité Qualité Mesure Créer une entité en base de données Moyenne Haute Intégrité des données Rapidité Les données permettant la création de l'entité sont vérifiées à la fois par le client et par des règles présentes sur le serveur d'application. L'ensemble du traitement doit être effectué en moins de 4 secondes Cas d'utilisation générique #2 : Lire une entité en base de données Ce cas d'utilisation aura lieu à chaque fois qu'un acteur souhaitera lire une entité de la base de données. De ce fait ce cas d'utilisation générique est inclu dans des cas d'utilisation spécifiques décrits dans le cahier des charges fonctionnel. Sa priorité de développement est haute Description Lorsque l'utilisateur souhaite lire une entité dans la base de données, il doit dialoguer avec le serveur d'applications qui va aller chercher les informations pour lui. Ce cas d'utilisation générique est inclu dans le cas d'utilisation #108 «Consulter un participant» Acteurs Les acteurs concernés sont l'ensemble des acteurs des cas d'utilisation spécifiques cités ci-dessus. 11/11/07 Version / 77

58 Pré-conditions La base de données doit être créée et l'accès à celle-ci doit être configurée par l'administrateur Cas nominal Acteur(s) 13.L'utilisateur veut lire une entité déjà créée. Système 14.Le système demande une session au SessionProvider. 15.Le système demande la lecture de l'entité à l'entityservice par l'intermédiaire du SessionFacade. 16.L'EntityService cherche l'entité demandée dans la base de donnée par l'intermédiaire de l'entitydao. [exception : #2_err_1] Le système retourne les données de l'entité demandée par l'utilisateur et le cas d'utilisation spécifique reprend à l'endroit où il avait appelé ce cas d'utilisation générique Flux d'erreur #2_err_1 : L'accès à la base de données est impossible, une notification est envoyée à l'utilisateur. 11/11/07 Version / 77

59 Diagramme de séquence 11/11/07 Version / 77

60 Fonction Qualité Mesure Fonction Fréquence Priorité Qualité Mesure Lire une entité en base de données Haute Haute Rapidité L'ensemble du traitement doit être effectué en moins de 2 secondes Cas d'utilisation générique #3 : Modifier une entité en base de données Ce cas d'utilisation aura lieu à chaque fois qu'un acteur souhaitera modifier une entité de la base de données. De ce fait ce cas d'utilisation générique est inclu dans des cas d'utilisation spécifiques décrits dans le cahier des charges fonctionnel. Sa priorité de développement est moyenne Description Lorsque l'utilisateur souhaite lire une entité dans la base de données, il doit dialoguer avec le serveur d'applications qui va aller chercher les informations pour lui. Ce cas d'utilisation générique est inclu dans le cas d'utilisation #105 «Modifier un participant» Acteurs Les acteurs concernés sont l'ensemble des acteurs des cas d'utilisation spécifiques cités ci-dessus. 11/11/07 Version / 77

61 Pré-conditions La base de données doit être créée et l'accès à celle-ci doit être configurée par l'administrateur Cas nominal Acteur(s) 1. L'utilisateur veut modifier une entité déjà créée. Système 2. Le système demande une session au SessionProvider. 3. Le système demande la création de l'entité à l'entityservice par l'intermédiaire du SessionFacade. 4. L'EntityService demande à l'entité de vérifier sa validité à l'aide des règles de conformité. [exception : #3_err_1] 5. L'EntityService vérifie la présence de l'entité dans la base de données par l'intermédiaire de l'entitydao. [exception : #3_err_2] 6. L'EntityService demande la mise à jour de l'entité dans la base de données à l'entitydao. [exception : #3_err_2] [exception : #3_err_3] L'entité est mise à jour dans la base de données et le cas d'utilisation spécifique reprend à l'endroit où il avait appelé ce cas d'utilisation générique. 11/11/07 Version / 77

62 Flux d'erreur #3_err_1 : L'entité à mettre à jour n'est pas conforme aux règles en vigueur, une notification est envoyée à l'utilisateur. #3_err_2 : L'accès à la base de données est impossible, une notification est envoyée à l'utilisateur. #3_err_3 : L'écriture dans la base de données est impossible, une notification est envoyée à l'utilisateur. 11/11/07 Version / 77

63 Diagramme de séquence 11/11/07 Version / 77

64 Fonction Qualité Mesure Fonction Fréquence Priorité Qualité Mesure Modifier une entité en base de données Haute Moyenne Intégrité des données Rapidité Les données permettant la mise à jour de l'entité sont vérifiées à la fois par le client et par des règles présentes sur le serveur d'application. L'ensemble du traitement doit être effectué en moins de 4 secondes Cas d'utilisation générique #4 : Supprimer une entité en base de données Ce cas d'utilisation aura lieu à chaque fois qu'un acteur souhaitera supprimer une entité de la base de données. De ce fait ce cas d'utilisation générique est inclu dans des cas d'utilisation spécifiques décrits dans le cahier des charges fonctionnel. Sa priorité de développement est moyenne Description Lorsque l'utilisateur souhaite enregistrer une entité dans la base de données, il doit dialoguer avec le serveur d'applications qui va réaliser l'opération pour lui. Ce cas d'utilisation générique est inclu dans le cas d'utilisation #109 «Supprimer un participant» Acteurs Les acteurs concernés sont l'ensemble des acteurs des cas d'utilisation spécifiques cités ci-dessus. 11/11/07 Version / 77

65 Pré-conditions La base de données doit être créée et l'accès à celle-ci doit être configurée par l'administrateur Cas nominal Acteur(s) 1. L'utilisateur veut supprimer une entité déjà créée. Système 2. Le système demande une session au SessionProvider. 3. Le système demande la supprimer de l'entité à l'entityservice par l'intermédiaire du SessionFacade. 4. L'EntityService cherche l'entité demandée dans la base de donnée par l'intermédiaire de l'entitydao. [exception : #4_err_1] 5. L'EntityService demande la suppression de l'entité de la base de données à l'entitydao. [exception : #4_err_2] L'entité choisie est supprimée de la base de données et le cas d'utilisation spécifique reprend à l'endroit où il avait appelé ce cas d'utilisation générique Flux d'erreur #4_err_1 : L'accès à la base de données est impossible, une notification est envoyée à l'utilisateur. #4_err_2 : L'écriture dans la base de données est impossible, une notification est envoyée à l'utilisateur. 11/11/07 Version / 77

66 Diagramme de séquence 11/11/07 Version / 77

67 Fonction Qualité Mesure Fonction Fréquence Priorité Qualité Mesure Supprimer une entité en base de données Rare Moyenne Rapidité L'ensemble du traitement doit être effectué en moins de 4 secondes. 11/11/07 Version / 77

68 5 Conventions de codage Nous avons mis en place un ensemble de conventions nous permettant d'assurer une qualité optimale du code produit. Ainsi nous assurons, au fur et à mesure des versions, que l'application reste maintenable et évolutive. 5.1 Langue L'équipe rédigera l'ensemble du code et des commentaires (Javadoc comprise) en anglais. 5.2 Contrôle automatique de la qualité du code Grâce au plugin Checkstyle de Maven, nous avons mis en place un grand nombre de règles de codage à respecter : Présence de la javadoc, Respect des conventions de nommage Java des classes, constantes, variables locales, etc..., Vérification des imports effectués, Cohérence des modificateurs, Vérification de la mise en forme et de l'atteignabilité des blocs, Vérification des problèmes éventuels de codage et de design des classes Java et JEE5, Implémentation de l'ensemble des todos. Ce contrôle automatique du code permet le respect des conventions Java sur le code et la Javadoc. 11/11/07 Version / 77

69 5.3 Versions Nous utilisons l'outil de gestion de version Subversion. Le dépôt où le projet sera stocké est organisé de la facon suivante : Illustration 24: Structure du dépôt Subversion La version qui sera développée sera stockée dans le répertoire trunk. Pour chaque version rendue, une branche sera créée dans laquelle l'équipe pourra implémenter des corrections demandées par le client. Le répertoire tags contiendra les différentes versions acceptées par le client et aucun développement n'y sera fait. Les conventions du dépôt de code sur le gestionnaire de versions sont les suivantes : Le code déposé doit respecter les conventions prédéfinies, Le code déposé ne doit contenir aucune erreur, ni aucun warning, Le code déposé doit avoir passé avec succès une batterie de tests unitaires. 11/11/07 Version / 77