Rapport UML/Java. Projet 2 semestre CSII2. Développement d un site internet de gestion de projet

Transcription

1 2010 Rapport UML/Java Projet 2 semestre CSII2 Développement d un site internet de gestion de projet Teychene Francois / Lecointe Nicolas / Ballard Sylvain EPSI Montpellier 17/01/2010

2 Rapport UML/Java 2 Sommaire Introduction... 4 Cahier des charges... 5 Gestion de projet... 6 Dossier de spécification du logiciel... 7 Calendrier du projet... 8 Plan de développement... 9 Définition du cycle de vie du projet... 9 Développement de la structure de la base Mise en place des accès aux données Mise en place d une couche de contrôle et de traitement Ajout de la sécurité au logiciel Développement de l interface graphique Outils de développement Conteneur de servlet Le choix de l environnement de développement Modélisation de l architecture Dictionnaire de données User: Role: Admin: Guest: Collaborator: Manager: Project: Task: WorkLoad Advancement: Journal:... 14

3 Rapport UML/Java 3 Use case: Diagrammes de séquences systèmes Gérer les projets S authentifier Visualiser les informations d un projet Gérer ses tâches Créer des tâches Gérer les collaborateurs Description de l architecture Java Server Faces Spring Hibernate Diagrammes de classes Diagramme de classe des entités Diagramme des classes de l application Diagramme des classes de la session utilisateur Diagramme d activités Diagramme d activité de lancement de l application Sécurité Diagramme de fonctionnement général du programme Conclusion Annexe Annexe Annexe

4 Rapport UML/Java 4 Introduction Ce rapport à pour but de montrer et d expliquer le travail qui à été effectuer pour la réalisation du projet de 2 semestre de la 2 année ingénieur à l EPSI pour les matières UML et Java. Ce projet avait pour objectif la réalisation par les étudiants d un logiciel web de gestion de projet. La réalisation de ce projet à été effectuée dans l optique de suivre les directives optimales vu en cours de génie logiciel pour la réalisation d application informatiques de qualité. Dans un premier temps nous avons fait une analyse du cahier des charges qui nous a été fourni pour la réalisation du logiciel. A partir de ce cahier des charges nous avons définit un cahier des charges fonctionnel. A partir de cet étape nous avons définit les règles de génies logiciel que nous allions suivre durant la réalisation du projet et nous avons en parallèle définit les spécifications techniques du logiciel. Ensuite le document présentera les points clef de la modélisation du logiciel en présentant le diagramme des cas d utilisation du logiciel, les diagrammes de séquences systèmes ainsi que les diagrammes d activité globaux du système. Le document présentera également l architecture du logiciel. Enfin nous conclurons sur le travail réalisé durant la durée du projet.

5 Rapport UML/Java 5 Cahier des charges Le cahier des charges qui a été fournis aux étudiants demandait la réalisation d un logiciel de gestion de planification de projets et listait les fonctionnalités principales. Le but du logiciel est de permettre la gestion d un projet en permettant aux utilisateurs de gérer les tâches du projet, leurs ressources et de visualiser les informations globales de l avancement du projet. Le logiciel doit donc respecter le cahier des charges suivant : Gestion de planification de projets : Il doit proposer les fonctionnalités de base de ce type d outil : la gestion des tâches, (créer des tâches, les découper, les modifier, les supprimer) la gestion des ressources (envisager la collaboration de partenaire extérieur, avec échange de mails) l affectation des ressources la gestion des dépendances et de l avancement, visualisation du diagramme de Gantt visualisation du pourcentage de réalisation de chaque tâche la gestion des jours fériés et des vacances pour les ressources. Chaque membre de l'équipe pouvant remplir son carnet de bord journalier (avancement des tâches à sa charge) Mise en forme et affichage d'une vue globale de l'avancement du projet avec mise en évidence des dérives. Possibilité de mettre en place un outil permettant à chaque membre de publier les risques identifiés lors de leurs activités et la solution envisagée pour les lever. Après lecture du cahier des charges nous avons choisi de définir un cahier des charges fonctionnel pour définir les besoins précis auxquels nous allions répondre par le développement de leurs projets. Ce document permet de définir les besoins en termes de fonctions que le futur utilisateur aura à accomplir, ou que le système devra accomplir pour lui. Voir le cahier des charges fonctionnel en annexe (Annexe 1).

6 Rapport UML/Java 6 Gestion de projet Après avoir définit le cahier des charges fonctionnel de l application, nous avons définit les éléments de gestion de projets prévisionnels que nous allions tenter de suivre durant le développement du projet. En parallèle du cahier des charges fonctionnel nous avons mis en place les outils de suivi et le tableau de bord. Nous avons donc définit le dossier de spécification du logiciel, le calendrier du projet ainsi que le plan de développement. Tableau de bord du projet Afin de planifier et de contrôler l état d avancement nous avons utilisé dans un tableur un tableau de bord qui nous permet de rendre une trace détaillée de ce qui s est passé. Ce tableau est alimenté par le suivi individuel. Remarque : Quand le renseignement périodique n était pas réalisé nous avons pris une répartition uniforme de l avancement sur la période considérée. Elaboration de notre tableau de bord Pour chaque tâche chaque intervenant indique le «temps passé» T et le «restant à faire» R. L avancement A est calculé par différence entre deux informations de «restant à faire», c est donc ce qui n est plus à faire. On cumul le temps passé T et on en déduit le coefficient d utilisation de la ressource (en fonction du nombre de jours ouvrés (ici les chiffres sont faible étant donné le travail multitâches mais il est proportionnellement intéressant de le suivre. La vitesse de l avancement est obtenue par le rapport de l avancement par le temps, l indicateur est bon s il est supérieur à 1. La performance c'est-à-dire l atteinte des objectifs, sur toutes les taches en cours et passées. Charge affectée * 100 / T + R des tâches. Extraits On a considéré que pour rendre compte de la charge de travail nous pouvions plus facilement le faire si l unité de temps était : «les jours où nous pouvions passer du temps dessus». De ce fait les jours et demi-journées indiquées sont plutôt équivalents à 1h30 de travail prévu. Ce qui est une moyenne

7 Rapport UML/Java 7 réaliste entre les jours de cours où le travail est proche de 0 heures en moyenne sur la durée du projet et les autres jours où l on peut se rattraper. Taches Charge totale estimée (en jour) Ressources nb de ressource Tableau de bord élaboration 4 nicolas 1 4 Définition du cdcf 3 francois 1 3 Dossier de spécification du 8 francois 2 4 logiciel nicolas Définition de l'architecture logicielle Développement de la structure de la base Mise en place des accès aux données couche de contrôle et de traitement Ajout de la sécurité au logiciel 24 francois sylvain 8 francois sylvain 8 francois nicolas 8 francois nicolas 9 francois sylvain nicolas IHM 16 nicolas sylvain Test des librairies et outils de 8 nicolas développement sylvain Nombre de jours dans le calendrier Charge affectée totale cumulée François Nicolas Sylvain Total (jours) Période de travail sur le calendrier : 50 jours (10 semaines) Dossier de spécification du logiciel Le dossier de spécification du logiciel permet de définir globalement l application en définissant l environnement, les interfaces ainsi que les fonctionnalités principales. Ce dossier s appuie

8 Rapport UML/Java 8 majoritairement sur le cahier des charges fonctionnel et sur les expériences passées des membres de l équipe de développement pour définir les spécifications du logiciel. Voir le dossier de spécification du logiciel en annexe (Annexe 2). Après définition de ces spécifications techniques nous avons définit l architecture du logicielle en parallèle du calendrier du projet. Calendrier du projet Après définition du dossier de spécification du logiciel il restait 1 mois pour la réalisation du projet nous avons donc mis en place le calendrier suivant : mars-10 D L Ma Me J V S Définition du cahier des charges fonctionnel Dossier de spécification du logiciel avr-10 D L Ma Me J V S mai-10 D L Ma Me J V S

9 Rapport UML/Java 9 Définition de l'architecture logicielle Développement du code métier Développement de l'ihm Répartition du temps de travail en jour 22% 24% 16% 19% 19% Définition du cahier des charges fonctionnel Dossier de spécification du logiciel Définition de l'architecture logicielle Développement du code métier Développement de l'ihm Après avoir définit le calendrier prévisionnel de l application nous avons définit le plan de développement en parallèle de l architecture du logiciel. Nous avons également choisit de ne pas l intégrer dans le calendrier, cette étape devant être très courte et mené en simultané avec un autre tâche. Plan de développement Le plan de développement a été réalisé dans un intervalle de temps très court. Après avoir définit le cahier des charges fonctionnel, le dossier des spécifications du logiciel et le calendrier nous n avions plus qu à définir le découpage du cycle de vie du projet, la définition des tâches à effectuer dans chaque phase et les outils de développement. Définition du cycle de vie du projet Nous avons d abord choisi le cycle de vie de projet que nous allions mettre en place durant le développement du projet et nous avons choisi un développement basé sur cinq cycles : Cycle 1 : Développement des entités de la structure de la base Cycle 2 : Mise en place des accès aux données Cycle 3 : Mise en place d une couche de contrôle et de traitement Cycle 4 : Ajout de la sécurité au logiciel Cycle 5 : Développement de l interface graphique

10 Rapport UML/Java 10 Pour chacune de ces tâches, nous avons définit des tâches à effectuer. Ces tâche ne sont pas liées à un membre du projet mais sont attribué à tous, nous avons choisi de ne pas affecter de tâche à une personne à cause de l expérience des membres du projet dans le langage. Les tâches sont exécutées par tous les membres du groupe à la hauteur de leurs capacité à l effectué. Développement de la structure de la base Définition des entités : Création des classes des entités Application de la couche de persistance : Développement de la structure de la base et du mapping objet/relationnel, Hibernate (utilisation des standard JPA uniquement) Mise en place des accès aux données Ajout du framework Spring Intégration de Spring dans l application pour l injection de dépendance Gestion de la persistance : Configuration de la génération d EntityManager par Spring Définition des Dao : Création des classes d accès aux données Gestion des transactions : Ajout de la gestion automatique des transactions Mise en place d une couche de contrôle et de traitement Définition des contrôleurs : Création des classes de contrôle, définition de leurs portés et la hiérarchie des contrôleurs Intégration de certains traitements «critiques» : Implémentation des méthodes de cohérence de la base de données Ajout de la sécurité au logiciel Sécurisation des appels aux pages internet : Intégration d ACEGI Securité, configuration du filtre global de sécurité Sécurisation des méthodes : Combinaison de Spring AOP et d un filtre ACEGI pour sécuriser les appels aux controleurs Développement de l interface graphique Gestion des avancements théoriques et prévisionnels : Ajout de la classe Advancement et modification de la structure de la base et rajout de Dao et de contrôleurs

11 Rapport UML/Java 11 Ajout du carnet de bord par tâche (plus global) : Ajout d un journal lié à l avancement des tâches par personnes et non plus par tâche de façon globale Intégration de JSF : Mise en place de objets de lien entre les pages internet et les contrôleurs Ajout de la visualisation des données : Création des pages web de visualisation des données. Outils de développement Le choix des outils de développement s est porté sur deux choix : Le conteneur de servlet Le choix de l environnement de développement Les autres choix technologiques notamment concernant les librairies et frameworks utilisés dans le projet ayant été définit dans le dossier de spécification du logiciel. Conteneur de servlet Le choix entre un conteneur de servlet et un serveur d application pour le déploiement de l application s est posé comme le point le plus important pour la définition de l architecture du logiciel. Pour faire notre choix nous avons pris en compte les technologies que nous avons décidé d employer ainsi que de la pertinence d un serveur d application JEE par rapport à ces choix. De plus nous avons décidé d utiliser des librairies ne nécessitant pas l utilisation d un serveur d application, ce choix nous a permis de définir quel serveur choisir indépendamment de l architecture du logiciel. Nous avons donc choisi de porter notre choix sur le conteneur de servlet Tomcat car nous avons voulu utiliser certains frameworks qui sont utilisés dans les entreprises et dont l apprentissage n est pas effectué durant notre formation. La plupart de ces technologies s intègrent bien dans un serveur d application néanmoins nous avons voulu faire gérer la base de données et les transactions par le programme et cette utilisation entraine des problèmes d intégration du logiciel dans un serveur JEE. Néanmoins la possibilité à été émise de prendre du temps à la fin du développement du logiciel pour sortir une version du logiciel intégrant la technologie EJB et pouvant être déployer sur Glassfish. Le choix de l environnement de développement L environnement de développement a été choisi pour sa portabilité et la rapidité de développement que nous pourrions avoir.

12 Rapport UML/Java 12 Nous avons donc choisi de développer sous une machine virtuelle Unix comportant une base de données Mysql-5, un JDK 6 update 17, un Tomcat et un Eclipse Galileo configuré pour gérer les projets web JSF. De plus un SVN dédié à été mis en place sur un serveur personnel accessible depuis l extérieur ainsi qu un logiciel de gestion de projet Trac.

13 Rapport UML/Java 13 Modélisation de l architecture Après terminer les phases de définition du cahier des charges fonctionnel et du dossier de spécification du logiciel, nous nous sommes lancé dans l étude de l architecture que nous allons mettre en place dans le programme en parallèle de la définition des choix de gestion de projet. Dictionnaire de données User: Il s agit des utilisateurs du logiciel, ils possèdent un nom d utilisateur (login) et des mots de passes (password) Chacun des utilisateurs possède des Roles qui lui donnent des droits sur le logiciel Role: Les Roles sont des autorisations définies qui permettent l utilisation de certaines fonctionnalités du logiciel. Les Roles sont utilisé par la couche de sécurité de l application pour l authentification ainsi que pour l accès aux méthodes des Controlers. Admin: Un Admin est une catégorie de User qui gère les Projects. Les Admins peuvent créer, éditer et supprimer des Project et configurer quel en est le Manager. Guest: Les Guests sont une catégorie de User qui permettent d accéder à des informations sur des Projects. Les Guest ne peuvent pas modifier les données des Project auxquels ils ont accès, ils sont juste des point visiteurs sur des Projects. Collaborator: Les Collaborators sont les utilisateurs du logiciel ayant un rôle dans un projet. Ils possèdent un temps de travail journalier, on leurs associe des tâches et ils peuvent publier des informations sur leurs carnet de bord.

14 Rapport UML/Java 14 Manager: Les Managers sont des Collaborator qui ont les droits de gestion des projets. Ce sont les Manager qui définissent les tâches d un projet et qui leurs affilies des Collaborators pour travaillé. Les Manager sont aussi en charge de la liaison de Collaborators et de Guests à un Project. Project: Les Project correspondent à des projets. Ils sont composés d une date de début, d un nom et d une date de fin qui correspond à la deadline du projet. Un projet est également composé d un ensemble de Task qui est le découpage en tâches du projet. Task: Une Task est la représentation d une division du travail d un projet. Elle est constituée d Avancements, d une date de début, d une WorkLoad, une date de fin qui sera automatiquement mise à jour quand tous les Advancements du projet seront complets. Elle possède aussi une marge d erreur qui permet de définir si la tâche est une zone de problème du logiciel. WorkLoad Une WorkLoad correspond à la charge de travail nécessaire à la réalisation d une tâche en nombre d heures de travail. Cette charge permet de calculer la date de fin théorique de la tâche selon les nombres de Collaborator qui lui sont affecté et de leurs temps de travail journalier. Advancement: L Advancement est l affectation d un Collaborator à une Task. La Task correspond aux informations globales de la tâche mais comme une tâche peut être accomplie par plusieurs Collaborator, l Advancement correspond aux informations d une Task par rapport à un des Collaborator qui les est associé. L Advancement est également composé de Journal, il s agit du carnet de bord de la tâche pour un Collaborator. Journal: Un Journal correspond à un texte à une date donnée commentant l avancement d une Tâche pour un Collaborator qui lui est associé.

15 Rapport UML/Java 15 Use case: uc Use Case Gerer les projets Admin S'authentifier User Visualisaer l'avancement d'un projet Guest Visualiser le gantt d'un projet Ecrire dans son carnet de bord Gérer ses tâches «extend» Collaborator Creer des taches «extend» Affilier des tâches à des collaborateurs Manager Gerer les collaborateurs

16 Rapport UML/Java 16 Diagrammes de séquences systèmes Gérer les projets sd Gerer les projets Systeme Admin recupererprojets() :listprojets recupererprojets() :listeprojet selectionnerprojet() :informations opt Modifier Projet modifierprojet(projet) modifierprojet() opt Supprimer Projet supprimerprojet(projet) supprimerprojet(projet) opt Ajouter Projet ajouterprojet() ajouterprojet() (fromuse case)

17 Rapport UML/Java 17 S authentifier sd S'authentifier Systeme User demandepageinternet() alt Authentifier [Utilisateur authentifié] :pageinternet [Utilisateur anonyme] loop Valide utilisateur [utilisateur anonyme] :pageauthentification login(login, password) authentification() enregistrerutilisateur(user) :pageinternet (fromuse case) Visualiser les informations d un projet sd Visualiser les informations d'un projet Systeme Guest recuperermesprojets() :listeprojets selectionprojet(projet, typevisualisation) alt Type visualisation [gantt] :diagrammegantt [avancement] :diagrammeavancement [calendrier] :calendrier (fromuse case)

18 Rapport UML/Java 18 Gérer ses tâches sd Gérer ses taches Systeme Collaborator affichermestachesliéaunprojet(projet) recupererlestachesd'unprojet(projet) filtrertachesliéaucollaborateur() :listetaches selectionnertache(tache) informations() modifiertache() modifiertache() opt ajoutercommentaire() ajoutercommentaireaunetache() (fromuse case) La gestion des tâches se limite uniquement à modifier l état d un avancement. Un avancement représente la gestion d une tache pour chaque collaborateur qui lui est assigné. Une tâche ne peut réellement modifier car elle sert de révérenciel pour tous les avancements qui lui sont liés. C est pour cela que le cycle de vie d une tâche ne peut être gérer que par le manager du projet, les tâches pouvant être partagées par de nombreux collaborateurs si ceux-ci avaient le droit de changer les paramètres d une tâche, ces modifications seraient répercutées pour tous les utilisateurs liés à cette tâche.

19 Rapport UML/Java 19 Créer des tâches sd Créer des tâches Systeme Manager recupererlesprojetquejemanage() recupererlisteprojetmanagépar(manager) :listeprojet selectionprojet(projet) creertache(tache) ajoutertacheauprojet(tache) opt Affilier ressources attacherressource() recupererlistecollaborateurduprojet(projet) :listedescollaborateur selectionnerlescollaborateurs(list<collaborateur>) attacheralatache(tache, List<Collaborateur>) (fromuse case)

20 Rapport UML/Java 20 Gérer les collaborateurs sd Gérer les collaborateurs Systeme Manager recupererlesprojetsquejemanage() recupererlesprojetmanagépar(manager) :listeprojets selectionnerprojet(projet) :listeutilisateurprojet seletionnerutilisateur(utilisateur, Action) alt Action [modifier] modifierutilisateur(utilisateur) [supprimer] supprimerutilisateur(utilisateur) [ajouter] ajoutercollaborateur(utilisateur) (fromuse case)

21 Rapport UML/Java 21 Description de l architecture L architecture du logiciel est basée sur l utilisation de librairies et de framework populaire dans le monde du développement Java qui ne font pas partie des technologies étudiées à l EPSI. L architecture du logiciel est basée sur trois framework : Java Server Faces Spring Hibernate Chacun de ces frameworks est chargé de gérer des parties différentes de l application. Java Server Faces Java Server Faces (abrégé en JSF) est un framework pour le développement d'applications Web. A l'inverse des autres frameworks MVC traditionnels à base d'actions, JSF est basé sur la notion de composants où l'état d'un composant est enregistré lors du rendu de la page, pour être ensuite restauré au retour de la requête. Nous avons choisi d utiliser en combinaison avec le jeu de composants additionnel JBoss RichFace pour la gestion de l ajax. Dans notre architecture les objets managés par JSF sont les objets liés aux requêtes ou au maximum à la session d un utilisateur. Ils sont responsables de la récupération des valeurs nécessaire à l affichage des pages de l application ainsi que de la validation des valeurs passé au logiciel. Nous avons préféré faire gérer les traitements et les accès à la base de données par des objets managés par Spring. Nous avons donc pour cela mis en place un pont depuis les objets JSF vers les objets managé par Spring. Pour cela nous avons utilisé la librairie SpringBeanFacesELResolve permettant d injecter dans un objet JSF un objet géré par Spring. Spring Spring est un framework libre pour construire et définir l'infrastructure d'une application java 1, dont il facilite le développement et les tests. Spring s'appuie principalement sur l'intégration de trois concepts clés : 1. l'inversion de contrôle ou injection de dépendance 2. la programmation orientée aspect 3. une couche d'abstraction.

22 Rapport UML/Java 22 Nous avons voulu utiliser ce framework car il s agit d une solution très utilisé dans les entreprises et qui n est pas enseigné durant le cursus de l EPSI. Nous avons donc tenté d utiliser ce framework autant que possible en utilisant les spécificités du framework. Nous avons donc définit les couches de contrôle et de traitement ainsi que l accès à la base et à la sécurité. Nous avons ainsi définit la gestion des contrôle grâce à la mise en place d objets contrôleur utilisés par les objets JSF. Les contrôleurs sont utilisés via un objet SessionControler qui sert de point d entrée aux objets Spring et qui dispache l appel des traitements à des contrôleurs spécialisés dans certains types de traitement, comme nous pouvons le voir dans le diagramme de classe Session. Tous ces objets de gestion des traitements sont placés en session par le framework. Cette utilisation très limité du framework nous a paru insuffisant pour expliquer l utilisation de cette technologie. Nous avons également choisi d utiliser la programmation par aspect. Cette fonctionnalité nous a paru très intéressante à intégrer pour les fonctions de gestion des transactions et de la sécurité. Les objets Dao (Data Acess Object) gérant les appels à la base sont également géré par Spring mais nous avons rajouté à ces classe la gestion d une qui sert à définir une méthode comme étant une transaction SQL. Nous avons également mis en place un mécanisme pour le déploiement rapide de l application, la persistance est gérée par un objet EntityManager qui est créé par un EntityManagerFactory. Spring configuré permet d injecter un EntityManager dans les classes qu il gère, il s agit de la solution que nous avons choisi de mettre en place. Nous avons également utilisé cette fonction de programmation par aspect pour la sécurité des appels aux couches contrôleurs. Chaque appel aux fonctions est intercepté par un objet Spring qui vérifie si l utilisateur possède les droits d accès à cette méthode, si celui-ci ne les possède pas, l objet remonte une exception à l objet JSF appelant qui permet de le renvoyer sur une page d erreur. Hibernate Nous avons choisi d utilisé les standard JPA (Java Persistance Api) pour la gestion de la persistance des données. Pour cela nous avons choisi l implémentation Hibernate néanmoins nous aurions pu utiliser tout autre implémentation de JPA tel que TopLink ou d autres. Nous avons choisi d utiliser des annotations directement dans le code pour le mapping des objets avec la base de données.

23 Rapport UML/Java 23 Récapitulatif Page JSP 2 JSF 3 4 ProjectManager CalendarView 10 TaskManager 1 Spring Securité RessourceInterceptor MethodInterceptor 5 Intercepteur Controler SessionControler 6 7 AdvancementControl ProjectControler UserController Data Acess Object Transaction 8 Advancement Dao UserDao TaskDao ProjectDao RoleDao JournalDao 9 Base de données

24 Rapport UML/Java 24 Diagrammes de classes Le diagramme de classe du système a été divisé en trois parties : Diagramme de classe des entités Ce diagramme concerne les classes qui correspondent aux données gérées par le système. Elles représentent également le schéma de la base de données. Diagramme de classe de l application Ce diagramme correspond aux classes qui gèrent les accès aux données et sont globales à l application. Toutes ces classes sont définies en scope application Diagramme de classe de la session utilisateur Ce diagramme présente les classes qui sont stockées durant la session d un utilisateur. Ces classes permettent de faire le lien avec les accès à la base et permettent à l affichage des données. Toutes ces classes sont définies en scope session

25 Rapport UML/Java 25 Diagramme de classe des entités class entity entity::admin + Admin() entity::collaborator - name: String - projects: List<Project> - secondname: String - tasks: List<Advancement> + addproject(project) : void + addtask(advancement) : void + Collaborator() + getname() : String + getprojects() : List<Project> + getsecondname() : String + gettaskbyproject(project) : List<Advancement> + gettasks() : List<Advancement> + removeproject(project) : void + removetask(advancement) : void + setname(string) : void + setprojects(list<project>) : void + setsecondname(string) : void + settasks(list<advancement>) : void + tostring() : String -collaborator 1 -tasks 0..* entity::user - login: String - password: String - roles: List<Role> + equals(object) : boolean + getlogin() : String + getpassword() : String + getroles() : List<Role> + setlogin(string) : void + setpassword(string) : void + setroles(list<role>) : void + User() entity::manager - myprojects: List<Project> + getmyprojects() : List<Project> + Manager() + setmyprojects(list<project>) : void -users 0..* -manager myprojects 0..* entity::guest - projects: List<Project> + getprojects() : List<Project> + Guest() + setprojects(list<project>) : void entity::project entity::role - id: int - users: List<User> - value: String -roles + equals(object) : boolean 0..* + getid() : int + getusers() : List<User> + getvalue() : String + Role() + setid(int) : void + setusers(list<user>) : void + setvalue(string) : void - begindate: Calendar - collaborators: List<Collaborator> - enddate: Calendar - guest: List<Guest> - id: int - manager: Manager - name: String - tasks: List<Task> entity::advancement - accomplishment: int - collaborator: Collaborator - comment: List<Journal> - enddate: Calendar - id: int - task: Task + Advancement() + Advancement(Task, Collaborator) + equals(object) : boolean + getaccomplishment() : int + getcollaborator() : Collaborator + getcomment() : List<Journal> + getenddate() : Calendar + getid() : int + gettask() : Task + setaccomplishment(int) : void + setcollaborator(collaborator) : void + setcomment(list<journal>) : void + setenddate(calendar) : void + setid(int) : void + settask(task) : void -assigned -task 0..* 0..1 entity::task - assigned: List<Advancement> - id: int - name: String - project: Project + equals(object) : boolean + getassigned() : List<Advancement> + getid() : int + getname() : String + getproject() : Project + setassigned(list<advancement>) : void + setid(int) : void + setname(string) : void + setproject(project) : void + Task() -tasks 0..* -project 1 + addtask(task) : void + equals(object) : boolean + getbegindate() : Calendar + getcollaborators() : List<Collaborator> + getenddate() : Calendar + getguest() : List<Guest> + getid() : int + getmanager() : Manager + getname() : String + gettasks() : List<Task> + Project() + removetask(task) : void + removetask(int) : void + setbegindate(calendar) : void + setcollaborators(list<collaborator>) : void + setenddate(calendar) : void + setguest(list<guest>) : void + setid(int) : void + setmanager(manager) : void + setname(string) : void + settasks(list<task>) : void -advancement 1 -comment 0..* entity::journal - advancement: Advancement - date: Calendar - id: int - text: String + getadvancement() : Advancement + getdate() : Calendar + getid() : int + gettext() : String + Journal() + setadvancement(advancement) : void + setdate(calendar) : void + setid(int) : void + settext(string) : void

26 Rapport UML/Java 26 Diagramme des classes de l application class dao dao::bddschemacreator - admininfo: String - collaboratorinfo: String - guestinfo: String - projectmanagerinfo: String + BddSchemaCreator() + getadmininfo() : String + getcollaboratorinfo() : String + getguestinfo() : String + getprojectmanagerinfo() : String + setadmininfo(string) : void + setcollaboratorinfo(string) : void + setguestinfo(string) : void + setprojectmanagerinfo(string) : void dao::abstractdao Type Id - entitymanager: EntityManager + get(id) : Type + getall() : List<Type> + getentitymanager() : EntityManager + merge(type) : Type + persist(type) : void + refresh(type) : void + remove(type) : void + setentitymanager(entitymanager) : void LocalContainerEntityManagerFactoryBean dao::entitymanagerprovider + createnativeentitymanagerfactory() : EntityManagerFactory + EntityManagerProvider() dao::projectdao + get(integer) : Project + getall() : List<Project> + getprojectmanagedby(manager) : List<Project> + getprojectsascollaborator(collaborator) : List<Project> + merge(project) : Project + persist(project) : void + refresh(project) : void + remove(project) : void dao::roledao + get(integer) : Role + getall() : List<Role> + merge(role) : Role + persist(role) : void + refresh(role) : void + remove(role) : void dao::taskdao + get(integer) : Task + getall() : List<Task> + gettaskbyproject(project) : List<Task> + merge(task) : Task + persist(task) : void + refresh(task) : void + remove(task) : void dao::advancementdao + get(integer) : Advancement + getadvancementsbytask(task) : List<Advancement> + getall() : List<Advancement> + merge(advancement) : Advancement + persist(advancement) : void + refresh(advancement) : void + remove(advancement) : void dao::userdao + get(string) : User + get(string, String) : User + getall() : List<User> + merge(user) : User + persist(user) : void + refresh(user) : void + remove(user) : void + UserDao()

27 Rapport UML/Java 27 Diagramme des classes de la session utilisateur class controler controler::usercontroler - roledao: RoleDao - userdao: UserDao + getroledao() : RoleDao + getuserdao() : UserDao + merge(user) : User + persist(user) : void + refresh(user) : void + remove(user) : void + setroledao(roledao) : void + setuserdao(userdao) : void + UserControler() -usercontroler controler:: SessionInformation - user: User + getuser() : User + SessionInformation() + setuser(user) : void -sessioninformation controler::advancementcontroler - advancementdao: AdvancementDao + AdvancementControler() + getadvancementdao() : AdvancementDao + merge(advancement) : Advancement + persist(advancement) : void + refresh(advancement) : void + remove(advancement) : void + removeadvancementfromtask(task) : void + setadvancementdao(advancementdao) : void -advancementcontroler -projectcontroler - projectdao: ProjectDao - taskdao: TaskDao controler::projectcontroler + getprojectdao() : ProjectDao + getprojectmanagedby(manager) : List<Project> + getprojectsascollaborator(collaborator) : List<Project> + gettaskbyproject(project) : List<Task> + gettaskdao() : TaskDao + merge(project) : Project + merge(task) : Task + persist(project) : void + persist(task) : void + ProjectControler() + refresh(project) : void + refresh(task) : void + remove(project) : void + remove(task) : void + setmanager(manager, Project) : void + setprojectdao(projectdao) : void + settaskdao(taskdao) : void controler::sessioncontroler - advancementcontroler: AdvancementControler - projectcontroler: ProjectControler - sessioninformation: SessionInformation - usercontroler: UserControler + addproject(project) : void + addtaskonproject(project, Task) : Task + adduser(user) : void + assignecollaboratortotask(task, Collaborator) : void + assigneprojecttocollaborator(collaborator, Project) : void + getadvancementcontroler() : AdvancementControler + getprojectcontroler() : ProjectControler + getprojectmanagedby(manager) : List<Project> + getprojectsascollaborator(collaborator) : List<Project> + getsessioninformation() : SessionInformation + gettaskbyproject(project) : List<Task> + getusercontroler() : UserControler + mergeproject(project) : Project + mergeuser(user) : User + removemanagerforproject(project) : void + removeproject(project) : void + removeprojecttocollaborator(collaborator, Project) : void + removeuser(user) : void + SessionControler() + setadvancementcontroler(advancementcontroler) : void + setmanagerforproject(project, Manager) : void + setprojectcontroler(projectcontroler) : void + setsessioninformation(sessioninformation) : void + setusercontroler(usercontroler) : void dao + AbstractDao + AdvancementDao + BddSchemaCreator + EntityManagerProvider + ProjectDao + RoleDao + TaskDao + UserDao (fromproject)

28 Rapport UML/Java 28 Diagramme d activités Diagramme d activité de lancement de l application act Activité global Programme Spring Conteneur de servlet JSF Demarrage du programme Analyse web.xml Analyse des fichiers de configuration Définition des filtres Instanciation des servlets du programme Définition du contexte JSF Instanciation des Manager de persistance Instanciation des Dao Instanciation de la servlet JSF Définition des mapping des URL Attente d'une connection Fin du lancement de l'application Il s agit d une vue simplifié du démarrage de l application. Les points les plus importants de ce diagramme sont l utilisation du framework Spring qui se charge de l instanciation et des liens entre les objets de l application par rapport à des fichiers de configuration ainsi que de l instanciation de la Servlet JSF qui gère tous les appels au programme (toutes les pages de l application étant des pages JSF).

29 Rapport UML/Java 29 Sécurité act Securité Conteneur de servlet Spring Programme Reception requete Verification filtre [Url de deconnection] Url? [Url d'authentification] Verification de l'utilisateur Détacher l'utilisateur de la session [Autre] Afficher page d'authentification [Non] Utilisateur déja enregistré? [Non] Utilisateur valide? [Oui] [Oui] Verification des droit d'accès Enregistrement de l'utilisateur Afficher page Roles valide? Afficher l'erreur La configuration de la sécurité c est effectué grâce aux rôles des utilisateurs. Les url des pages sont configurées pour nécessiter certains rôles pour pouvoir y accéder. De même la configuration de la sécurité permet de gérer selon le même fonctionnement l appel aux méthodes des objets instanciées par le framework Spring. On a donc put ajouter une solution de sécurité sur l appel à des ressources mais également sur des appels à certaines méthodes en cas de faille de la première couche de sécurité.

30 Rapport UML/Java 30 Diagramme de fonctionnement général du programme act Fonctionnement général Conteneur de servlet JSF Spring Securité Reception requete Url [*.jsf] Affichage de la page [Autre] Reception demande méthode Affichage d'une erreur d'accès a la ressource Appel de la méthode du bean JSF Securité Erreur Execution des méthodes Recherche des règles de navigation concernant la page «datastore» Modifications de la base Appel à la ressource concerné Fin execution Le fonctionnement général du projet est basé sur l utilisation de toutes les couches de l architecture qui s occupe des appels aux méthodes des autres objets. L utilisateur demande une ressource, le programme applique le filtre de sécurité pour obliger l authentification de l utilisateur. Après validation, l utilisateur récupère la page jsp modifié par JSF selon les valeurs des objets managés. En cas d appel d une méthode le filtre de sécurité s applique de

31 Rapport UML/Java 31 nouveau pour vérifier que l utilisateur possède bien les droits d utiliser cette méthode et exécute ensuite les méthodes. Après avoir exécuté les méthodes, JSF vérifie le retour de la méthode appeler et cherche dans les navigation-case si une valeur correspond à cette valeur pour déterminer la ressource à appeler.

32 Rapport UML/Java 32 Conclusion Le développement de ce logiciel nous a permis de nous former au développement web dans une architecture JEE. Nous avons choisi de nous focaliser sur les technologies à employer et sur leur intégration dans notre projet, plus que sur les fonctionnalités du logiciel car nous avons travaillé sur ce projet dans une optique de formation complémentaire à celle qui nous est proposé à l EPSI en travaillant sur des technologies non approfondies en cours, ce qui nous à conduit la mise en œuvre de nombreuse configuration invisible en terme de fonctionnement du logiciel. Ce travail nous a familiarisé avec les contraintes de la gestion de projets et nous avons essayé de nous tenir au mieux aux résultats de la phase préliminaire de gestion de projet, que nous nous étions fixés. Néanmoins s agissant d un projet étudiant l adaptation des contraintes de gestion de projets (calcul du temps nécessaire des tâches, tenu d un carnet de bord journalier, ) n ont pas put être toutes prises en compte à cause de la disparité du temps de travail en réaction aux autres projets et travaux a réaliser. L analyse du travail réalisé est présentée en Annexe 3. Malgré tout nous avons tenté de réaliser un travail propre qui malgré la non adéquation avec le travail que nous aurions voulu réaliser permet l intégration de nouvelles fonctionnalités de façon assez rapide grâce à une bonne séparation des couches de l application. De plus l équipe de travail était assez hétérogène dans les compétences de chacun au début du projet. Le développement de cette application a permis à chacun d apprendre de nouvelles choses et nous a sensibilisé aux difficultés de concevoir une architecture fiable et robuste dans un environnement JEE. Nous avons beaucoup apprécié le développement avec les framework que nous avons utilisé et pensons que leur apprentissage permettra une meilleure connaissance des possibilités du JEE couplé aux enseignements de l année prochaine en Java.

33 Annexe 1

34 Annexe 2

35 Annexe 3