Cahier des charges techniques

Transcription

1 Ecole Ingénieurs 2000 Filière Informatique et Réseaux Version 1.1 Date : Cahier des charges techniques Membres de l'équipe E-MOTEP : Mathieu BRUNET Jérémy FONTERAY Julien JORRY Christophe KELLER Site du projet :

2 Historique du document Version Raison de la modification Date 0.1 Plan de rédaction 30/10/ Modélisation logicielle 4/11/ Injection des briques 5/11/2006 logicielles 0.7 Rédaction de l architecture 5/11/2006 logicielle 0.8 Description des paquetages 6/11/ Injection des diagrammes de 7/11/2006 séquences 1.0 Harmonisation du contenu 8/11/ Enrichissement, correction et validation du contenu 9/11/ /11/2006 Cahier des charges techniques page 2

3 SOMMAIRE INTRODUCTION...6 DESCRIPTION DE L EQUIPE...7 DESCRIPTION DU LOGICIEL...8 ETUDE TECHNIQUE ARCHITECTURE LOGICIELLE...9 La couche présentation...11 La couche métier...12 La couche de données...12 Les Modules COMPOSANTS LOGICIELS UTILISES...14 Serveur d application...14 La base de données...15 La gestion des sources informatiques :...17 La gestion de la documentation :...19 La gestion des bugs :...22 La gestion des tests et de leur couverture : /11/2006 Cahier des charges techniques page 3

4 ANALYSE CONCEPTUELLE PAQUETAGES JAVA...27 Paquetage «SessionHandler»...28 Paquetage «Commons»...29 Paquetage «EntityManager»...30 Paquetage «Entity»...31 Paquetage «ExternalEntity»...32 Paquetage «Analysers»...33 Paquetage «Harvesters»...34 Paquetage «Connectors»...35 Paquetage «ConnectorImpl» DIAGRAMMES DE SEQUENCE Création d un utilisateur : Modification d un utilisateur : Désactiver un utilisateur : Connexion à E-motep : Déconnexion d e-motep Modifier son profil Création d un projet Modification d un projet Création d une tache Modifier une tache Désactiver un projet Désactiver une tache Accéder à une échéance Changer la langue : client léger Changer la langue : client Lourd...65 ORGANISATION DE L EQUIPE...67 CONCLUSION...69 GLOSSAIRE /11/2006 Cahier des charges techniques page 4

5 ILLUSTRATIONS Figure 1: Environnement J2EE Figure 2: Modélisation d'e-motep dans son environnement J2EE Figure 3: Paquetages généraux Figure 4: le paquetage "SessionHandler" Figure 5: le paquetage "Commons" Figure 6: Le paquetage "EntityManager" Figure 7: paquetage "Entity" Figure 8: Paquetage "ExternalEntity" Figure 9: paquetage "Analysers" Figure 10: paquetage "Harvesters" Figure 11: paquetage "Connectors" Figure 11 : sequence Création d'un utilisateur Figure 12 : séquence Modification d'un utilisateur Figure 13 séquence désactiver un utilisateur Figure 14 : séquence connexion à E-motep Figure 15 : séquence déconnexion Figure 16: séquence modifire son profil Figure 17 : séquence création d'un projet Figure 18 : séquence modification d'un projet Figure 19: séquence création d'une tache Figure 20: séquence modification d'une tache Figure 21 : séquence désactiver projet Figure 22 : séquence Désactiver une tache Figure 23 : séquence accéder à une échéance Figure 24: séquence changer la langue Figure 25: séquence changer la langue /11/2006 Cahier des charges techniques page 5

6 Introduction Ce document est le cahier des charges fonctionnelles du logiciel E-motep. Il fait suite à la description des outils de travail et vient en complément du cahier des charges fonctionnelles. Le logiciel E-motep doit permettre le suivi de projets informatique en flux tendu et faciliter le travail collaboratif autour de ces projets. Ce document est une réponse technique au cahier des charges fonctionnelles. Il servira de référence en ce qui concerne l architecture logicielle du projet ainsi que les choix techniques retenus. Dans un premier temps nous nous emploierons à détailler les choix établis dans la Description Des Outils De Travail. Dans cette partie seront expliquer l architecture générale de l outil E-motep. Nous rappellerons les principes établis plus tôt et leur mise en place. La seconde partie du document permettra au lecteur d avoir une connaissance aigue des choix d implémentation pour la programmation de l outil. E-motep proposera de nombreuses fonctionnalités et pourra notamment, se connecter à des outils distants pour récupérer des informations. Ce document expliquera les solutions retenues pour réaliser ces opérations ainsi que les choix d optimisation réalisés par l équipe. 09/11/2006 Cahier des charges techniques page 6

7 Description de l équipe L équipe du projet E-motep est composé de quatre membres chacun ayant des responsabilités différentes afin de concevoir et développer un logiciel de suivi de projet informatique : Jérémy FONTERAY rempli le rôle de chef de projet. Il doit diriger le reste de l équipe, assigner les tâches et veiller au bon déroulement de la réalisation du projet. Il intervient bien sûr également dans les différentes tâches de production. Julien JORRY est responsable de la documentation. Il veille à rassembler les parties rédigées par les différentes personnes du groupe. Il vérifie également la bonne tournure des phrases et corrige les fautes d orthographe. Julien est également responsable de l ergonomie du logiciel, il est à sa charge de définir les interfaces graphiques du logiciel. Mathieu BRUNET est l expert technique de l équipe. Il est chargé de réaliser les différentes recherches permettant de faire les choix d architectures pour la construction du logiciel. Christophe KELLER est responsable tests et qualité. Il doit définir les tests permettant de valider les différentes fonctionnalités de l application E-motep. En tant que responsable qualité, Christophe veille à ce que les documents rendus soient bien mis en page. 09/11/2006 Cahier des charges techniques page 7

8 Description du logiciel E-motep est un logiciel de suivi de projet informatique. Il permet de s interfacer différents outils nécessaires lors d un développement informatique : un serveur de gestion de code, un serveur de gestion de la documentation, un logiciel de gestion de bugs, un outil de couverture de tests. Il capable d analyser les différentes productions réalisées pour déduire un état d avancement d une tâche. Il permet ainsi de faciliter le suivi de projets. E-motep repose sur une architecture J2EE. Il est accessible via un client léger ou un client lourd. Le client lourd est utilisé par trois acteurs différents : le chef de projet, le superviseur et l administrateur. L administrateur peut créer ou modifier des utilisateurs, ainsi que paramétrer les connexions aux différents outils. Le chef de projet peut créer de nouveaux projets, assigner des utilisateurs à des tâches et surveiller l état d avancement de ses projets. Le superviseur a quant à lui accès à tous les projets et peut ainsi surveiller le bon déroulement de chacun d eux. Le client léger est destiné à tous les utilisateurs d E-motep, en particulier aux membres de projet. Il leur permet de consulter leur emploi du temps ainsi que celui des projets dont ils font parti. En plus de faciliter le suivi de projet, E-motep est un outil pratique pour le travail collaboratif. Chacun peut facilement accéder aux informations le concernant. 09/11/2006 Cahier des charges techniques page 8

9 Etude technique Le logiciel E-motep repose sur une architecture J2EE. Il proposera un client lourd en Java et un client léger Web. L étude technique qui suit doit détailler plus précisément les implémentations choisies ainsi que leur fonctionnement. 1 Architecture logicielle E-motep est une application destinée à être déployé dans un serveur d application J2EE. Ces serveurs se découpe en 3 tranches conforme à la représentation 3 tiers classique : une couche de présentation, une couche de logique métier et une couche d accès aux données. Couche présentation : Il s agit d une partie servant principalement aux mécanismes d interaction avec l utilisateur, présentant les données et communiquant avec la couche métier Couche métier : Il s agit de la partie fournissant les processus métier de l application. Cette s interface entre la couche de présentation et la couche de données. Couche donnée : Il s agit de la partie fournissant principalement des mécanismes d accès aux données comme la gestion de la persistance par exemple. Dans le cas d un serveur d application J2EE, ces différentes couches sont représentées par des mécanismes et des conteneurs bien spécifiques : - le conteneur de servlets qui s occupe de la couche présentation - le conteneur d EJBs qui s occupe de la couche métier - des mécanismes de gestion de la persistance et d accès aux ressources extérieurs pour la couche donnée 09/11/2006 Cahier des charges techniques page 9

10 La notion de client lourd modifie quelque peu cette représentation puisque ce dernier va pouvoir directement se connecter à la couche métier du serveur via un ORB. Ainsi la couche de présentation est extériorisée du serveur et pris en charge par une application tierce pouvant elle aussi contenir ses propres processus métiers. Nous avons donc l environnement d exécution et de déploiement suivant : Figure 1: Environnement J2EE C est dans ce cadre que E-motep va être conçu et exécuté. Nous allons modéliser l ensemble de l application en respectant l architecture 3 tiers et les designs offerts par la plateforme J2EE. 09/11/2006 Cahier des charges techniques page 10

11 La couche présentation E-motep propose 2 type d interface utilisateur : un client léger et un client lourd, tout deux prenant en charge une IHM spécifique. Le client lourd étant un conteneur externe et le client léger une projection html du conteneur web du serveur, leur modélisation et conception sera différente. En outre E-motep possède des fonctionnalités d affichage sous forme de graphique et de diagramme, fonctionnalité qui ne sont pas native et nécessite des briques logiciel tierces. Le client lourd et le client léger ayant des contextes graphiques différents, les générateurs de graphe seront différents pour les deux vues Le client lourd Comme nous l avons précisé précédemment, le client lourd possédera un module prenant en charge l IHM et un module de génération de graphe. Le client lourd s exécutant dans un contexte différent du serveur d application, l accès a la couche métier ne se fait pas directement. Ce dernier utilisera donc l ORB fourni par le serveur pour accéder a la couche métier. Pour permettre cette connexion, le client lourd devra intégrer un module d accès à la couche métier prenant en charge la connexion distante à l ORB Le client léger Le client léger est une projection en html d une partie du conteneur web. Nous baserons son développement sur la technologie Java Server Faces et ses briques logicielles liées. Comme pour le client lourd, nous y adjoindrons un module de génération de graphe. Au contraire du client lourd, le client léger s exécute dans le conteneur Web du serveur J2EE, ce qui permet d accéder à la couche métier directement via les APIs décrite dans la spécification J2EE. 09/11/2006 Cahier des charges techniques page 11

12 La couche métier La couche métier représenté par le conteneur d EJBs en J2EE a l avantage d offrir ses fonctionnalités simplement et de manière uniforme quelque soit les modes d accès. Ainsi il n y a pas de réel différence conceptuel entre un accès depuis l ORB (client lourd) ou depuis le conteneur web (client léger). Dans le cas d E-motep nous allons trouver différents modules chargés de modéliser l ensemble des fonctionnalités internes dans cette couche : - Les gestionnaires de session : responsable de la gestion des sessions utilisateurs. - Les manageurs d entités : responsable de la manipulation des entités de l application. - Les fournisseurs de logique métier : responsable de la communication entre les différents modules. - Les analyseurs de données : responsable de l analyse des récoltes de données - Les récolteurs de données : responsable de la récolte des données depuis les application tierces. - Les connecteurs externes : responsable de la gestion des connecteurs pour les applications tierces. - L unité de persistance : responsable de la gestion de la persistance. La couche de données La couche de données est modélisée pour E-motep via sa base de données et l ensemble des outils externes. Son accès depuis la couche métier est assuré par le module de «Connecteurs externes» et l unité de persistance. En outre les serveurs d applications J2EE offre un panel d API dédié à cette gestion 09/11/2006 Cahier des charges techniques page 12

13 Les Modules Nous avons définit l ensemble des principaux modules que contient E-motep en fonction de la couche dont ils font partis. Déployé dans un serveur d application, E-motep prendra la forme suivante : Figure 2: Modélisation d'e-motep dans son environnement J2EE 09/11/2006 Cahier des charges techniques page 13

14 2 Composants logiciels utilisés E-motep est une solution J2EE et nécessite donc un serveur d application J2EE. Etant donnée le volume important de donnée qui sera traité, nous y adjoindrons une base de données destinée à stocker les informations En outre Le logiciel E-motep doit être capable de se connecter à plusieurs types de serveurs distants, l ensemble de ces services devant permettre de récupérer les informations principales. Dans cette optique, nous utiliserons différentes briques logiciel destinées à assurer ces connections. Serveur d application Pour pouvoir implémenter une solution J2EE, il faut sélectionner un serveur d application. Le coeur métier de notre logiciel fonctionnera sur cette plate-forme. Les principaux serveurs d application J2EE : Sun Java System Application Server (Sun - gratuit) : Il s agit de l implémentation de référence des technologies J2EE de Sun. SJSAS est gratuit sous licence CDDL et intégralement compatible J2EE 5 Tomcat (Apache - Open Source) : Il s agit d une implémentation partielle des spécifications J2EE. Tomcat propose des fonctionnalités orientées WEB tel que les Servlets, JSP. Ce serveur est Open Source sous licence LGPL et bénéficie d une grande quantité de librairies externes. Websphere (IBM - payant) : Websphere est une plate-forme applicative générique couvrant un ensemble de solutions développées par IBM. Cette plate-forme fournie une gamme de serveur applicatif basée sur J2EE. 09/11/2006 Cahier des charges techniques page 14

15 JBoss AS (JBoss Open Source) : Il s agit d un serveur J2EE Open Source édité par JBoss (RedHat) respectant les spécifications J2EE 1.4 et partiellement 1.5. JBoss AS est très rependu et utilise divers module Open Source très réputé tel que Tomcat ou encore Hibernate. Serveur Remarque Note /5 SJSAS Pleinement compatible J2EE 5. 5 Tomcat Websphere JBoss AS Nombreuses librairies externes. Ne gère pas les EJB Très efficace mais payant. Disponible en 1.4 Très efficace. Non disponible en La solution retenue : Nous avons décidé d utiliser SJSAS. Ce dernier est gratuit et propose une implémentation pleinement compatible avec les spécifications J2EE 1.5. Il nous permettra donc d utiliser les nombreuses avancées du 1.5 (Generics, annotations, etc ). La base de données Les problèmes & choix possibles Dans le choix de la technologie, plusieurs critères nous sont apparus comme critiques : - Respect de la norme SQL Gestion de gros volume de données. - Rapidité d exécution des requêtes SQL. La première contrainte est établie par les spécifications J2EE 1.5. En effet pour pleinement profiter des mécanismes offerts par le «mapping objet relationnel» (ORM), il est nécessaire que le SGBD sélectionné soit compatible SQL 99. La gestion de gros volume de données et la rapidité d exécution sont quant à eux intra sec au mécanisme d ORM. La corrélation objet relationnel étant automatique, les requêtes SQL généré ne sont donc pas toujours optimisées. 09/11/2006 Cahier des charges techniques page 15

16 Dans une optique d allier les coûts à une efficacité nous proposons d utiliser l un des deux SGBD suivant : MySQL : Il s agit d un SGBDR simple d utilisation et dont l interface est facilement jumelable via le driver JDBC qu i l accompagne. Actuellement dans sa version 5.0, il propose les particularités suivantes : - utilisation d un moteur CVS - équipé du moteur InnoDB, il est apte à gérer les transactions et les clés étrangères, et propose une méthode propre d archivage - Interface de gestion en ligne possible. Toutefois la version 5 est encore instable. PostGreSQL : Véritable SGBDRO à part entière, fonctionnant sous licence GPL tout comme MySQl, il propose des avantages en matière de fiabilité & de sécurité. Il se trouve actuellement dans sa version 8.1. Si les deux SGBD proposent une interface JDBC permettant de commuter avec le serveur d application J2EE qui sera mis en œuvre, MySQL est tout de même plus rapide en matière de traitement de requête d insertion et de délétion. Cependant, PostGreSQL présente les avantages suivants : - Conception de bases de données complexes - Jeux de règles complexes (règles opérationnelles) - Utilisation de langages procéduraux sur le serveur - Transactions - Utilisation de procédures stockées - Utilisation de données géographiques En effet la fiabilité de MySQL restant plus légère, la persistance de données peut être mis a mal dans le cas de travail collaboratif simultané important. Rappelons ici que le cahier des charges stipule un fonctionnement en charge maximum pour 20 projets et 100 utilisateurs simultanés. Par ailleurs la complexité de PostGreSQL peut imposer, en cas de panne sur le serveur d application, une intervention requièrant une technicité experte. 09/11/2006 Cahier des charges techniques page 16

17 La gestion des sources informatiques : Description Dans un projet informatique collaboratif, il est impératif d avoir un outil centralisant les fichiers de code et gérant leurs versions. Chaque développeur travaille localement sur sa machine mais il peut envoyer ses fichiers modifiés sur le serveur central et récupérer ceux de ses collègues. La création des packages constituant un logiciel est répartie entre diverses personnes. Grâce à un tel outil, les différents participants peuvent accéder au travail des autres, ce qui est essentiel lorsque différentes fonctionnalités interagissent entre elles. Les outils choisis pour gérer les sources informatiques sont CVS et Subversion (SVN), les deux outils les plus utilisés aujourd hui Les différents outils disponibles CSV CVS (Concurrent Versions System) cet outil est très utilisé dans le monde du logiciel libre. Le fonctionnement de CVS s'appuie sur une base centralisée appelée «repository», hébergée sur un serveur, contenant l'historique de l'ensemble des versions successives de chaque fichier. Trois commandes caractérisent CVS : «checkout» permet de récupérer les sources d un projet, «commit» permet d envoyer les modifications à la base, «update» sert à charger les modifications réalisées par d autres développeurs. Outils de communication avec l outil : jcvs : API proposant un client/serveur complet qui permet à n importe quel programme JAVA d accéder aux différentes opérations possibles sur un serveur CVS. Il est écrit entièrement en JAVA et gratuit. javacvs : Similaire à jcvs, cet API est également gratuite et écrite entièrement en JAVA donc facilement intégrable à notre logiciel E-motep. 09/11/2006 Cahier des charges techniques page 17

18 Subversion Subversion (SVN) a été conçut comme une amélioration de CVS, il en garde le concept, mais propose une nouvelle implémentation. Il apporte des améliorations à CVS comme par exemple la gestion de version à un niveau global et non plus par fichier ce qui simplifie les retours en arrière. Outils de communication avec l outil : javasvn : Librairie open source écrite en java qui permet d accéder et modifier les sources sur un repository Subversion. javasvn ne nécessite aucune configuration ou sources particulières pour fonctionner sur n importe quelle plateforme. jsvn : Similaire à javasvn, cette bibliothèque permet de créer facilement des applications graphiques Swing en java permettant l accès aux repository SVN via HTTP. Cette librairie est développée par TMateSoft sous une licence TMate qui autorise son utilisation sous réserve que le logiciel qui l utilise soit lui-même librement distribuable. JavaHL : Bibliothèque faisant partie du projet Subversion. La communauté de développement autour de Subversion a développé celle-ci pour permettre d accéder à Subversion depuis un programme Java. JavaHL est développé principalement en Java, mais une partie est en C++ et ne peut pas être portée sur toutes les plateformes. Seul Windows, Linux et Mac OS X sont supportés. SVN4J : SVN4J est une librairie en Java qui remplace javahl, une API qui accède à Subversion en java. Cette librairie est gratuite (sourceforge) mais peu documenté. 09/11/2006 Cahier des charges techniques page 18

19 2.3.3 Comparatif et choix Nous avons choisit d utiliser CVS et SubVersion avec les outils suivants : CVS : jcvs et javacvs sont très similaire. La seule différence est que jcvs est plus largement utilisé ainsi que plus documenté, c est pourquoi nous avons choisi jcvs. Il n y a aucune implication sur notre architecture, juste une API de plus à ajouter à notre projet. SubVersion : De même qu avec CVS, les librairies jsvn et javasvn sont très similaires. Notre choix s est porté sur jsvn pour la documentation complète trouvé sur internet. La gestion de la documentation : Description La documentation d un projet a une importance primordiale : c est l outil de communication et de dialogue entre les membres de l équipe projet et les intervenants extérieurs (chef de projet, utilisateurs, développeurs etc.). Elle assure aussi la pérennité des informations au sein du projet et de l entreprise Les différents outils disponibles Alfresco Alfresco est un projet open-source, utilisant des standards ouverts, et basé sur la technologie J2EE. Alfresco a développé une architecture moderne qui utilise les derniers outils open-source pour optimiser les performances, et la Programmation Orientée Aspects (AOP) facilitant ainsi la modularité et l adaptabilité de l application. Cette solution est basée sur une application web qui stocke ses données dans un système de fichiers. 09/11/2006 Cahier des charges techniques page 19

20 Outils de communication avec l outil : Rmi-jcr : L objectif du JCR RMI d Alfresco est de rendre transparent l accès à des objets distribués de l API Alfresco avec une facilité à la mise en oeuvre et l utilisation d objets distants Java. JCR (Java Content Repository) est une API qui a été définie pour accéder de manière standard à des dépôts de contenu de manière indépendante de la solution utilisée. WebService : Il est possible d interagir avec Alfresco via différents WebService, programme fournissant une fonctionnalité particulière à d'autres programmes. Les programmes clients utilisent les protocoles de l'internet, en particulier le HTTP, pour accéder à ces services. API Java : En récupérant le contexte de l application, il est possible de l utiliser dans notre programme. Seul problème, c est que cela nécessite que le client s exécute dans la même JVM que notre serveur, or Alfresco utilise Tomcat et nous JSAS Maarch Maarch (Maerys Archive) est une infrastructure d archivage GED Open source complète pour la conservation de gros volumes de ressources numériques. Cette solution est éditée par Maerys sous licence GPL. Ce GED utilise la technologie PHP5 couplé à une base de données. Les systèmes de gestion de base de données supportés sont MySQL, SQL Server, Oracle. L application est multi plateforme. Outils de communication avec l outil Base de donnée : Il est possible d accéder directement à la base de données utilisée par Maarch (MySQL) et utiliser ainsi ces données dans notre programme. 09/11/2006 Cahier des charges techniques page 20

21 WebService : Il est possible d interagir avec Maarch via différents WebService, programme fournissant une fonctionnalité particulière à d'autres programmes. Les programmes clients utilisent les protocoles de l'internet, en particulier le HTTP, pour accéder à ces services Contineo Contineo est une GED open-source développée par une communauté libre. Cette solution est basée sur une application Web en Java avec des Servlets. Contineo est en cours de développement mais est déjà très abouti. Ainsi on peut utiliser différentes bases de données comme PostgreSQL, MySQL, HSQLBD etc Outils de communication avec l outil : WebService : Il est possible d interagir avec Contineo via différents WebService, programme fournissant une fonctionnalité particulière à d'autres programmes. Les programmes clients utilisent les protocoles de l'internet, en particulier le HTTP, pour accéder à ces services Comparatif et choix Nous avons choisit d utiliser Maarch et Contineo avec les outils suivants : Maarch : Maarch peut être aisément interrogé via des WebServices disponibles et correctement documenté. Contineo : Les WebServices étant facilement utilisable pour notre application et Contineo étant libre et en java, nous pouvons interférer avec celui-ci de manière assez simple. 09/11/2006 Cahier des charges techniques page 21

22 La gestion des bugs : Description Afin d optimiser la correction des bugs en période de tests, il est nécessaire de pouvoir archiver les problèmes rencontrés et leurs corrections effectuées. Pour cela, il leur est possible de créer des fiches de bug où le problème peut être expliqué grâce à différents outils. Lorsque l erreur est trouvée et corrigée, il est alors possible de clore la fiche Les différents outils disponibles Argus Issue Tracking System Argus est un logiciel simple permettant de créer une fiche de bug, de lui donner une priorité, de pouvoir la modifier. Il permet également de voir un avancement des bugs traités. Ce produit est sous licence BSD. Repose sur un environnement J2EE et PostGreSQL. Outils de communication avec l outil : Base de données : Il est possible d accéder directement à la base de données utilisée par Argus (PostgreSQL) et utiliser ainsi ces données dans notre programme ITracker ITracker est un logiciel de suivit de bug reposant sur une technologie J2EE. Il est possible d ajouter des bugs, de les assigner à différentes personnes et de suivre leur évolution (correction, validation). Il est disponible sous licence GPL. Outils de communication avec l outil : WebService : Il est possible d interagir avec ITracker via différents WebServices AXIS (apache), programme fournissant une fonctionnalité particulière à d'autres programmes. Les programmes clients utilisent les protocoles de l'internet, en particulier le HTTP, pour accéder à ces services. Base de données : Il est possible d accéder directement à la base de données utilisée par ITracker (n importe quel SGBDR) et utiliser ainsi ces données dans notre programme. 09/11/2006 Cahier des charges techniques page 22

23 Mantis Mantis est un logiciel de suivi de bug basé sur un serveur Php couplé à une base de données MySql. Il est compatible avec les systèmes d exploitation Windows, MacOS, OS/2, Linux, Solaris, et BSD. C est un logiciel gratuit sous licence GPL. Outils de communication avec l outil : MantisConnect : MantisConnect est un ensemble de bibliothèques permettant l interaction entre le système Mantis et des logiciels ou programmes externes. Elle existe sous licence GPL et sous licence payante permettant l intégration dans un logiciel non libre et peut être utilisé en Java. Base de données : Il est possible d accéder directement à la base de données utilisée par Mantis (MySQL) et utiliser ainsi ces données dans notre programme BugZilla Bugzilla est un logiciel de suivi de Bug développé par The Mozilla Organization en Perl et utilisant une base de données MySql. C est un logiciel libre et gratuit sous licence Mozilla Public Licence. Outils de communication avec l outil : JagZilla: Jagzilla est une API Java permettant d interfacer Bugzilla avec une application Java et facilitant la communication entre notre application et BugZilla. Cet API est libre, documenté et écrite en java. Base de données : Il est possible d accéder directement à la base de données utilisée par BugZilla (MySQL) et utiliser ainsi ces données dans notre programme. 09/11/2006 Cahier des charges techniques page 23

24 Comparatif, choix et implications Nous avons choisit d utiliser ITracker et BugZilla avec les outils suivants : ITracker : ITracker peut être aisément interrogé via des WebServices (AXIS) disponibles et correctement documenté. BugZilla : JagZilla étant libre de droit, très documenté et écrit tout en java, il est clair que son utilisation pour s interfacer avec BugZilla est la solution la plus simple. La gestion des tests et de leur couverture : Description Afin de s assurer du bon fonctionnement du logiciel E-motep, il est important que l équipe utilise un bon outil de gestion des tests. Ce logiciel doit permettre de connaître la couverture des tests, c'est-à-dire savoir si toutes les classes et méthodes sont testées. Il faut donc créer en parallèle des tests unitaires qui seront lancés pour valider une partie du code Les différents outils disponibles JCoverage Ce logiciel permet de connaître le pourcentage du code qui a été testé. Il permet également de créer des rapports après exécution afin d avoir immédiatement les informations sur les problèmes rencontrés. Outils de communication avec l outil : XML : JCoverage permet de sortir des fichiers XML facilement exploitable donc pour notre logiciel. 09/11/2006 Cahier des charges techniques page 24

25 JBlanket Ce logiciel permet de connaître le pourcentage du code qui a été testé. Un rapport peut être édité afin de voir l état de la couverture d une classe. Ce logiciel est Open Source. Outils de communication avec l outil : XML : JBlanket permet de sortir des fichiers XML facilement exploitable donc pour notre logiciel Cobertura Cobertura est un outil d analyse de la couverture des tests sur un projet Java qui affiche en pourcentage la couverture des tests. Outils de communication avec l outil : XML : Cobertura permet de sortir des fichiers XML facilement exploitable donc pour notre logiciel. HTML : Cobertura permet aussi de sortir des fichiers HTML Emma Emma permet de générer des rapports de couverture complet sous forme HTML, XML et de façon succincte en texte. Outils de communication avec l outil : XML : Emma permet de sortir des fichiers XML facilement exploitable donc pour notre logiciel. HTML : Emma permet aussi de sortir des fichiers HTML. 09/11/2006 Cahier des charges techniques page 25

26 Comparatif et choix Nous avons choisit d utiliser JBlanket et Emma avec les outils suivants : JBlanket: JBlanket génère des fichiers XML que l on peut aisément récupérer et assurer ainsi le suivi des tests et de leur couverture. Emma : Emma génère des fichiers XML que l on peut aisément récupérer et assurer ainsi le suivi des tests et de leur couverture. 09/11/2006 Cahier des charges techniques page 26

27 Analyse conceptuelle L analyse conceptuelle consiste à analyser le domaine d application pour en extraire les règles de comportement auxquelles sont soumis les objets du domaine. Il faut pour cela modéliser ces objets, définir leur comportement et modéliser les mécanismes de traitement associé. 1 Paquetages JAVA Les paquetages JAVA d E-motep recouvre les différents modules énoncés précédemment. Les paquetages du conteneur d EJBs : Figure 3: Paquetages généraux Il s agit ici de présenter les packages de l application. Cette figure illustre la composition du logiciel E-motep suivant une arborescence de couche. Les couches «basses», sont les couches métier. Il s agit des packages qui permettront les traitements par le logiciel. Les couches hautes, sont celles permettant la communication entre le serveur et l utilisateur. Nous allons détailler plus précisément chacun de ces packages. 09/11/2006 Cahier des charges techniques page 27

28 Paquetage «SessionHandler» Il s agit du paquetage regroupant les classes de connexions utilisateurs. Les utilisateurs sont encapsulés dans des «EJBs session Stateful» selon leur provenance (client léger ou client lourd) tout le long de leur connexion. Figure 4: le paquetage "SessionHandler" Le paquetage «SessionHandler» possède les classes suivantes : HeavySessionContext : Cette classe fournie les opérations principales et est directement accessible depuis le client lourd. Il s agit d un EJB session Stateful. LightSessionContext : Cette classe fournie les opérations principales et est directement accessible depuis le client léger. Il s agit d un EJB session Stateful. 09/11/2006 Cahier des charges techniques page 28

29 Paquetage «Commons» Il s agit du paquetage regroupant les processus métiers utiles pour l ensemble de l application E-motep. Figure 5: le paquetage "Commons" On trouve dans ce paquetage, le sous paquetage «Exceptions» contenant toutes les classes «Exception» définies pour l application E-motep. En outre, le paquetage «Commons» possède les classes suivantes : MessageHanlder : La classe «MessageHandler» a pour responsabilité de gérer l ensemble des messages internes et externes ( par exemple) utilisé au sein d E-motep 09/11/2006 Cahier des charges techniques page 29

30 Paquetage «EntityManager» Il s agit du paquetage regroupant les «Factory et MethodFactory» des principales entités que manipule E-motep. Figure 6: Le paquetage "EntityManager" On trouve dans ce paquetage des classes conformes aux «design pattern» «Factory» et «MethodFactory» basé sur des «EJBs session Stateless»: UserManager : Manipule les entités «UserEntity» et «ProfilEntity» ProjectManager : Manipule les entités «ProjectEntity» PlanningManager : Manipule les entités «PlanningEntity» et «TaskEntity» ExternalManager : Manipule les entités «GEDEntity», «SRCEntity», «TESTEntity» et «BUGEntity» 09/11/2006 Cahier des charges techniques page 30

31 Paquetage «Entity» Il s agit du paquetage regroupant les différentes entités gérées par E-motep. Figure 7: paquetage "Entity" Ce paquetage possède les classes suivantes : UserEntity : Modélise un utilisateur du système ProfilEntity : Modélise les informations du profil d un utilisateur du système ProjectEntity : Modélise un projet du système PanningEntity : Modélise un planning de projet du système TaskEntity : Modélise une tache d un planning 09/11/2006 Cahier des charges techniques page 31

32 Paquetage «ExternalEntity» Il s agit du paquetage regroupant les différentes entités externes gérées par E-motep. Figure 8: Paquetage "ExternalEntity" GEDEntity : Modélise les informations de connexion d une application de GED d un projet. GEDHarvestEntity : Modélise une récolte de donnée d une application de GED. SRCEntity : Modélise les informations de connexion d une application de gestion de versioning d un projet. SRCHarvestEntity : Modélise une récolte de donnée d une application de versioning. TESTEntity : Modélise les informations de connexion d une application de gestion des tests d un projet. TESTHarvestEntity : Modélise une récolte de donnée d une application de gestion de tests. BUGEntity : Modélise les informations de connexion d une application de gestion des bogues d un projet. BUGHarvestEntity : Modélise une récolte de donnée d une application de gestion de bogues. 09/11/2006 Cahier des charges techniques page 32

33 Paquetage «Analysers» Il s agit d un paquetage regroupant les analyseurs de données. Chaque analyseur est destiné a reconnaître un type particulier de récolte de données et à les traiter. L implémentation de ces classes seront conformes au «design pattern» «strategy». Figure 9: paquetage "Analysers" Le paquetage possède 4 classes : GEDAnalyser : En charge d analyser les récoltes de donnée de type «GEDHarvestEntity» BUGAnalyser : En charge d analyser les récoltes de donnée de type «BUGHarvestEntity» TESTAnalyser : En charge d analyser les récoltes de donnée de type «TESTHarvestEntity» SRCAnalyser : En charge d analyser les récoltes de donnée de type «SRCHarvestEntity» 09/11/2006 Cahier des charges techniques page 33

34 Paquetage «Harvesters» Ce paquetage regroupe les récolteurs de données. Chaque classe est spécifique a un type d outils externe et produisent des récolte de données de type «XXXHarvestEntity». Figure 10: paquetage "Harvesters" On y trouve les classes suivantes : GEDHarvester : Récolteur de donnée d application de GED. BUGHarvester : Récolteur de données d application de gestion de bogues. TESTHarvester : Récolteur de données d application de gestion de testes. SRCHarvester : Récolteur de données d application de versioning. 09/11/2006 Cahier des charges techniques page 34

35 Paquetage «Connectors» Il s agit du paquetage gérant les différents connecteurs vers les applications tierces. Le mécanisme d obtention de connecteur fonctionne via le «design pattern» «Factory». Ce paquetage contient en outre le paquetage «ConnectorImpl» que nous détaillerons après. Figure 11: paquetage "Connectors" Ce paquetage possède les classes suivantes : ConnectorFactory : Permet obtenir des connecteurs pour les applications tierces. GEDConnector : Interface définissant un connecteur vers une application de GED. BUGConnector : Interface définissant un connecteur vers une application de gestion de bogues. SRCConnector : Interface définissant un connecteur vers une application de versioning. TESTConnector : Interface définissant un connecteur vers une application de gestion de testes. 09/11/2006 Cahier des charges techniques page 35

36 Paquetage «ConnectorImpl» Il s agit du paquetage contenant les implémentations de connecteurs. Chacun de ces connecteurs implémente l interface propre a son type d applications. Ces classes sont conforme au «design pattern» «adapter». 09/11/2006 Cahier des charges techniques page 36

37 2 Diagrammes de séquence Cette partie du document présente les diagrammes de séquence pour la version 1 du logiciel E-motep. Nous y détaillons les imbrications entre les différents packages. 2.1 Création d un utilisateur : Voici le diagramme de séquence UML correspondant au Use-Case «Créer un utilisateur» Figure 12 : séquence Création d'un utilisateur 09/11/2006 Cahier des charges techniques page 37

38 Scénario : Lors de la création d un nouvel utilisateur au sein du logiciel E-motep sur le client lourd, une méthode createuser( ) est appelé sur le «HeavySessionContext» (le contexte du client lourd) qui appelle lui-même la méthode createuser( ) sur le «UserManager» qui est la «factory» gérant les utilisateurs. Les paramètres passés à la méthode createuser ( ) sont : - Login (une chaîne de caractère) : la clé primaire ou id - Mot de passe : permettant à l utilisateur de se connecter à E-motep - Droits : les droits accordés à cet utilisateur (admin, chef de projet, superviseur). Celle-ci crée une nouvelle entité «UserEntity» et appelle les différents Setter nécessaires pour cet objet crée. Ensuite le «UserManager» crée l entité «ProfilEntity» contenant le profil de l utilisateur et l attache à l utilisateur crée précédemment et exécute les «setters» en conséquence. Le «UserManager» appelle ensuite la méthode persist() au niveau de l unité de persistance du serveur pour enregistrer ce nouvel objet en base. La chaîne alors renvoi au client une instance de l «UserEntity» crée. 09/11/2006 Cahier des charges techniques page 38

39 2.2 Modification d un utilisateur : Voici le diagramme de séquence UML correspondant au Use-Case «Modifier un utilisateur» Figure 13 : séquence Modification d'un utilisateur 09/11/2006 Cahier des charges techniques page 39

40 Scénario : Lorsqu un utilisateur est modifié au niveau du client lourd, cela appelle la méthode modifuser( ) dans le «HeavySessionContext» (le contexte du client lourd) qui appelle luimême la méthode modifuser ( ) sur le «UserManager». Les paramètres passés à la méthode modifuser( ) sont : - l id de l utilisateur (correspond à son login) - une map contenant le nom de chaque champ comme clé et la nouvelle valeur de celui-ci (la map ne contenant que les champs modifiés) C est ensuite grâce à la réflexion sur les Beans qu on appellera les bonnes méthodes sur l objet «UserEntity» permettant de modifier ces différents paramètres. Le «UserManager» appelle ensuite la méthode update() au niveau de «l unité de persistance» du serveur pour enregistrer ce nouvel objet en base. La chaîne alors renvoi au client une instance de l «UserEntity» modifié. 09/11/2006 Cahier des charges techniques page 40

41 2.3 Désactiver un utilisateur : Voici le diagramme de séquence UML correspondant au Use-Case «Desactiver un utilisateur» Figure 14 séquence désactiver un utilisateur 09/11/2006 Cahier des charges techniques page 41

42 Scénario : Lors de la désactivation d un utilisateur, le client lourd appelle la méthode sup( ) dans le «HeavySessionContext» (le contexte du client lourd) qui appelle lui-même la méthode delete( ) sur le «UserManager». Les paramètres passés à la méthode delete ( ) sont : - le login de l utilisateur à désactiver puisque le login est l id de celui-ci. - La désactivation met le paramètre booléen «isdeseactivate» à «true». L «UserManager» renvoi alors la nouvelle instance de l «UserEntity» après l avoir mis à jour en base en appelant la méthode update() sur l unité de persistance. 09/11/2006 Cahier des charges techniques page 42

43 2.4 Connexion à E-motep : Voici le diagramme de séquence UML correspondant au Use-Case «Se connecter à E- motep» Figure 15 : séquence connexion à E-motep 09/11/2006 Cahier des charges techniques page 43

44 Scénario : Lorsqu un utilisateur souhaite se connecter à E-motep, voilà le processus déclenché : L interface appelle la méthode login( ) sur le «SessionContext» («LightSessionContext» pour le client léger et «HeavySessionContext» pour le client lourd). Cette méthode a deux paramètres : le login et le mot de passe entré par l utilisateur. Le SessionContext appelle alors la méthode find( ) sur le «UserManager» qui appelle aussi la méthode find( ) sur l unité de persistance. Cela permet de retourner l instance de l «UserEntity» trouvé et faire les vérifications, via la méthode verif( ), des droits de l utilisateur et du mot de passe entré par celui-ci. Si le login existe, le mot de passe correct et les droits suffisants, alors l utilisateur est logué sur l interface et une nouvelle session est crée. 09/11/2006 Cahier des charges techniques page 44

45 2.5 Déconnexion d e-motep Voici le diagramme de séquence UML correspondant au Use-Case «Se de connecter d Emotep» Figure 16 : séquence déconnexion 09/11/2006 Cahier des charges techniques page 45

46 Scénario : Lorsqu un utilisateur souhaite se déconnecter à E-motep, voilà le processus déclenché : L interface appelle la méthode logout( ) sur le «SessionContext» («LightSessionContext» pour le client léger et «HeavySessionContext» pour le client lourd). Le contexte détruit alors la session et l utilisateur est redirigé vers la page, frame de connexion. 09/11/2006 Cahier des charges techniques page 46

47 2.6 Modifier son profil Voici le diagramme de séquence UML correspondant au Use-Case «Modifier son profil» Figure 17: séquence modifier son profil 09/11/2006 Cahier des charges techniques page 47

48 Scénario : Lorsqu un utilisateur souhaite modifié son profil, cela appelle la méthode modifprofiluser( ) dans le «SessionContext» qui appelle lui-même la méthode modifprofiluser( ) sur le «UserManager». Les paramètres passés à la méthode modifprofiluser( ) sont : - l id de l utilisateur (correspond à son login). - une map contenant le nom de chaque champ du profil comme clé et la nouvelle valeur de celui-ci (la map ne contenant que les champs modifiés). C est ensuite grâce à la réflexion sur les Bean qu on appellera les bonnes méthodes sur l objet «ProfilEntity» permettant de modifier ces différents paramètres. Le «UserManager» appelle ensuite la méthode update() au niveau de «l unité de persistance» du serveur pour enregistrer ce nouvel objet en base. La chaîne alors renvoi au client une instance de l «UserEntity» modifié. 09/11/2006 Cahier des charges techniques page 48

49 2.7 Création d un projet Voici le diagramme de séquence UML correspondant au Use-Case «Créer un projet» Figure 18 : séquence création d'un projet 09/11/2006 Cahier des charges techniques page 49

50 Scénario : Lors de création d un projet, une méthode createproject( ) est appelée depuis le client lourd vers le «HeavySessionContext» qui appelle cette même méthode sur le «ProjectManager». Cette méthode possède plusieurs paramètres : - Users : le ou les chefs de projet actif sur ce projet. - Nom : le nom du projet qui est la clé primaire des projets et qui devra donc être unique pour chaque projet. C est l id du projet. - Date de début : la date de début du projet. - Date de fin : la date de fin supposé du projet Cette méthode permet de créer l objet «ProjectEntity» représentant un projet. Le «ProjectManager» appelle ensuite une méthode createplanning( ) sur le «PlanningManager» prenant en paramètre les dates de début et de fin du projet. Le manageur de planning crée alors l instance de «PlanningEntity» qui est persisté dans l unité de persistance pour l enregistrement de l objet. Le «ProjectManager» s occupe alors d attacher ce planning au projet crée précédemment. L objet «ProjectEntity» crée est alors persisté à l unité de persistance. Cet objet, pour finir, est renvoyé au client pour son utilisation. 09/11/2006 Cahier des charges techniques page 50

51 2.8 Modification d un projet Voici le diagramme de séquence UML correspondant au Use-Case «Modifier un projet» Figure 19 : séquence modification d'un projet 09/11/2006 Cahier des charges techniques page 51

52 Scénario : Lors de création d un projet, une méthode changeproject( ) est appelée depuis le client lourd vers le «HeavySessionContext» qui appelle cette même méthode sur le «ProjectManager». Cette méthode possède plusieurs paramètres : - l id du projet (correspond à son nom) - une map contenant le nom de chaque champ comme clé et la nouvelle valeur de celui-ci (la map ne contenant que les champs modifiés) Cette méthode permet de créer l objet «ProjectEntity» représentant un projet. Le «ProjectManager» appelle ensuite une méthode changeplanning( ) sur le «PlanningManager» prenant en paramètre les dates de début et de fin du projet. Le manageur de planning crée alors l instance de «PlanningEntity» qui est persisté dans l unité de persistance pour l enregistrement de l objet. Le «ProjectManager» s occupe alors d attacher ce planning au projet modifié précédemment. L objet «ProjectEntity» crée est alors persisté à l unité de persistance. Cet objet, pour finir, est renvoyé au client pour son utilisation. 09/11/2006 Cahier des charges techniques page 52

53 2.9 Création d une tache Voici le diagramme de séquence UML correspondant au Use-Case «Créer une tache» Figure 20: séquence création d'une tache 09/11/2006 Cahier des charges techniques page 53

54 Scénario : La création d une tâche implique un certains nombre d appels de méthode au sein de nos entités, manageurs. Une méthode createtask( ) est appelé par l interface du client lourd. Celle-ci possède les paramètres suivants : - Une map d Utilisateur permettant d associer la tâche aux ressources en question - Une date de début - Une date de fin - Un libellé permettant de préciser la nature de la tâche - La liste des tâches précédentes associés à celle en cours de création. Cette même méthode est appelée sur le «ProjectManager» depuis le contexte. Il faut, pour modifier les tâches d un projet, obtenir son planning grâce à la méthode get() sur le «PlanningEntity». La méthode createtask( ) est alors appelé sur le «PlanningManager» pour pouvoir modifier le planning avec la nouvelle tâche créée. Le planning modifié est alors persisté sur l unité de persistance. Le projet modifié est retourné à l interface pour la mise à jour et un message est envoyé aux utilisateurs concernés par l ajout de cette tâche. 09/11/2006 Cahier des charges techniques page 54

55 2.10 Modifier une tache Voici le diagramme de séquence UML correspondant au Use-Case «Modifier une tache» Figure 21: séquence modification d'une tache 09/11/2006 Cahier des charges techniques page 55

56 Scénario : La modification d une tâche implique un certains d appels de méthode au sein de nos entités, manageurs. Une méthode modiftask( ) est appelé par l interface du client lourd. Celle-ci possède les paramètres suivants : - Une map des nouveaux Utilisateurs permettant d associer la tâche aux ressources en question - Une map des nouveaux paramètres modifiés à prendre en compte. Cette même méthode est appelée sur le «ProjectManager» depuis le contexte. Il faut, pour modifier les tâches d un projet, obtenir son planning grâce à la méthode get() sur le «PlanningEntity». La méthode modiftask( ) est alors appelé sur le «PlanningManager» pour pouvoir modifier le planning avec la tâche modifiée. Le planning modifié est alors persisté sur l unité de persistance. Le projet modifié est retourné à l interface pour la mise à jour et un message est envoyé aux utilisateurs concernés par la modification de cette tâche. 09/11/2006 Cahier des charges techniques page 56

57 2.11 Désactiver un projet Voici le diagramme de séquence UML correspondant au Use-Case «Desactiver un projet» Figure 22 : séquence désactiver projet 09/11/2006 Cahier des charges techniques page 57

58 Scénario : Le fait de désactiver un projet comporte beaucoup d implication. L appel se fait classiquement depuis le client lourd avec en paramètre l id du projet à désactiver. A ce niveau plusieurs mécanismes interviennent : En premier lieu la désactivation du planning du projet. Un update des objets persistants permet de mettre à jours toutes les informations liées au planning. En second lieu un mécanisme similaire se déroule pour désactiver les objets externes acquis sur le projet souhaité (le ProjectManager faisant appel au ExternalManager via la méthode «desactivateexternal»). Enfin, les information persistantes liées au projet sont mises à jour dans la base via la méthode update() du projectmanager, apte a mettre a jour la base de donnée. 09/11/2006 Cahier des charges techniques page 58