Rapport UML/Java - oomteam.free.froomteam.free.fr/EPSI/Rapport UML.pdf · Ce rapport à pour but de...
Transcript of Rapport UML/Java - oomteam.free.froomteam.free.fr/EPSI/Rapport UML.pdf · Ce rapport à pour but de...
Rapport UML/Java Projet 2 semestre CSII2
Développement d’un site internet de gestion de projet
2010
Teychene Francois / Lecointe Nicolas / Ballard Sylvain
EPSI Montpellier
17/01/2010
Rapport UML/Java 2
EPSI Montpellier | 2010
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 ............................................................................... 10
Mise en place des accès aux données ....................................................................................... 10
Mise en place d’une couche de contrôle et de traitement ....................................................... 10
Ajout de la sécurité au logiciel .................................................................................................. 10
Développement de l’interface graphique ................................................................................. 10
Outils de développement .............................................................................................................. 11
Conteneur de servlet ................................................................................................................. 11
Le choix de l’environnement de développement ..................................................................... 11
Modélisation de l’architecture .............................................................................................................. 13
Dictionnaire de données ................................................................................................................... 13
User: ...................................................................................................................................... 13
Role: ....................................................................................................................................... 13
Admin: ................................................................................................................................... 13
Guest: .................................................................................................................................... 13
Collaborator: .......................................................................................................................... 13
Manager: ............................................................................................................................... 14
Project: .................................................................................................................................. 14
Task: ....................................................................................................................................... 14
WorkLoad .............................................................................................................................. 14
Advancement: ....................................................................................................................... 14
Journal: .................................................................................................................................. 14
Rapport UML/Java 3
EPSI Montpellier | 2010
Use case: ............................................................................................................................................ 15
Diagrammes de séquences systèmes ................................................................................................ 16
Gérer les projets ............................................................................................................................ 16
S’authentifier ................................................................................................................................. 17
Visualiser les informations d’un projet ......................................................................................... 17
Gérer ses tâches ............................................................................................................................ 18
Créer des tâches ............................................................................................................................ 19
Gérer les collaborateurs ................................................................................................................ 20
Description de l’architecture ............................................................................................................. 21
Java Server Faces ........................................................................................................................... 21
Spring ............................................................................................................................................. 21
Hibernate ....................................................................................................................................... 22
Diagrammes de classes ..................................................................................................................... 24
Diagramme de classe des entités .................................................................................................. 25
Diagramme des classes de l’application ........................................................................................ 26
Diagramme des classes de la session utilisateur ........................................................................... 27
Diagramme d’activités ....................................................................................................................... 28
Diagramme d’activité de lancement de l’application ................................................................... 28
Sécurité .......................................................................................................................................... 29
Diagramme de fonctionnement général du programme .............................................................. 30
Conclusion ............................................................................................................................................. 32
Annexe 1 ................................................................................................................................................ 33
Annexe 2 ................................................................................................................................................ 34
Annexe 3 ................................................................................................................................................ 35
Rapport UML/Java 4
EPSI Montpellier | 2010
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.
Rapport UML/Java 5
EPSI Montpellier | 2010
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).
Rapport UML/Java 6
EPSI Montpellier | 2010
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
Rapport UML/Java 7
EPSI Montpellier | 2010
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
Nombre de jours
dans le calendrier
Tableau de bord élaboration 4 nicolas 1 4
Définition du cdcf 3 francois 1 3
Dossier de spécification du
logiciel
8 francois
nicolas
2 4
Définition de l'architecture
logicielle
24 francois
sylvain
2 12
Développement de la
structure de la base
8 francois
sylvain
2 4
Mise en place des accès aux
données
8 francois
nicolas
2 4
couche de contrôle et de
traitement
8 francois
nicolas
2 4
Ajout de la sécurité au
logiciel
9 francois
sylvain
nicolas
3 3
IHM 16 nicolas
sylvain
2 8
Test des librairies et outils de
développement
8 nicolas
sylvain
2 4
Charge affectée totale cumulée
François Nicolas Sylvain Total
(jours)
34 31 31 96
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
Rapport UML/Java 8
EPSI Montpellier | 2010
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
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
Définition du cahier des charges fonctionnel
Dossier de spécification du logiciel
avr-10
D L Ma Me J V S
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
mai-10
D L Ma Me J V S
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
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
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éfini
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
• 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
22%
24%
Répartition du temps de travail en
Rapport UML/Java
EPSI Montpellier
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
Le plan de développement a été réalisé dans un intervalle de temps très court. Après avoir défini
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
: Développement des entités 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
16%
19%
19%
Répartition du temps de travail en
jour
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
Rapport UML/Java 9
EPSI Montpellier | 2010
Après avoir définit le calendrier prévisionnel de l’application nous avons définit le plan de
é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
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
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 :
Définition du cahier des
charges fonctionnel
Dossier de spécification
l'architecture logicielle
Développement du code
Développement de l'IHM
Rapport UML/Java 10
EPSI Montpellier | 2010
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
Rapport UML/Java 11
EPSI Montpellier | 2010
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.
Rapport UML/Java 12
EPSI Montpellier | 2010
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 6.0.26 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.
Rapport UML/Java 13
EPSI Montpellier | 2010
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.
Rapport UML/Java 14
EPSI Montpellier | 2010
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é.
Rapport UML/Java 15
EPSI Montpellier | 2010
Use case:
uc Use Case
Guest
Admin
Collaborator
Manager
User
Gerer les projets
Visualisaer l'avancement d'un
projet
Visualiser le gantt d'un projet
S'authentifier
Creer des taches
Affilier des tâches à des collaborateurs
Gérer ses tâches
Gerer les collaborateurs
Ecrire dans son carnet de bord
«extend»
«extend»
Rapport UML/Java 16
EPSI Montpellier | 2010
Diagrammes de séquences systèmes
Gérer les projets
sd Gerer les projets
Admin
(from Use case)
Systeme
opt Ajouter Projet
opt Modifier Projet
opt Supprimer Projet
recupererProjets()
recupererProjets():listeProjet
:listProjets
selectionnerProjet()
:informations
modifierProjet(projet)
modifierProjet()
supprimerProjet(projet)
supprimerProjet(projet)
ajouterProjet()
ajouterProjet()
Rapport UML/Java 17
EPSI Montpellier | 2010
S’authentifier
Visualiser les informations d’un projet
sd S'authentifier
User
(from Use case)
Systeme
alt Authentifier
[Utilisateur authentifié]
[Utilisateur anonyme]
loop Valide utilisateur
[utilisateur anonyme]
demandePageInternet()
:pageInternet
:pageAuthentification
login(login, password)
authentification()
enregistrerUtilisateur(User)
:pageInternet
sd Visualiser les informations d'un projet
Guest
(from Use case)
Systeme
alt Type visualisation
[gantt]
[avancement]
[calendrier]
recupererMesProjets()
:listeProjets
selectionProjet(Projet, typeVisualisation)
:diagrammeGantt
:diagrammeAvancement
:calendrier
Rapport UML/Java 18
EPSI Montpellier | 2010
Gérer ses tâches
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.
sd Gérer ses taches
Collaborator
(from Use case)
Systeme
opt
afficherMesTachesLiéAUnProjet(Projet)
recupererLesTachesD'unProjet(Projet)
filtrerTachesLiéAuCollaborateur()
:listeTaches
selectionnerTache(Tache)
informations()
modifierTache()
modifierTache()
ajouterCommentaire()
ajouterCommentaireAUneTache()
Rapport UML/Java 19
EPSI Montpellier | 2010
Créer des tâches
sd Créer des tâches
Systeme
Manager
(from Use case)
opt Affilier ressources
recupererLesProjetQueJeManage()
recupererListeProjetManagéPar(Manager)
:listeProjet
selectionProjet(Projet)
creerTache(Tache)
ajouterTacheAuProjet(Tache)
attacherRessource()
recupererListeCollaborateurDuProjet(Projet)
:listeDesCollaborateur
selectionnerLesCollaborateurs(List<Collaborateur>)
attacherALaTache(TAche, List<Collaborateur>)
Rapport UML/Java 20
EPSI Montpellier | 2010
Gérer les collaborateurs
sd Gérer les collaborateurs
Systeme
Manager
(from Use case)
alt Action
[modifier]
[supprimer]
[ajouter]
recupererLesProjetsQueJeManage()
recupererLesProjetManagéPar(Manager)
:listeProjets
selectionnerProjet(Projet)
:listeUtilisateurProjet
seletionnerUtilisateur(Utilisateur, Action)
modifierUtilisateur(Utilisateur)
supprimerUtilisateur(Utilisateur)
ajouterCollaborateur(Utilisateur)
Rapport UML/Java 21
EPSI Montpellier | 2010
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.
Rapport UML/Java 22
EPSI Montpellier | 2010
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 annotation @Transactional 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.
Rapport UML/Java 23
EPSI Montpellier | 2010
Récapitulatif
Page JSP
JSF
Spring
Controler
Data Acess Object
CalendarView
Securité
Base de données
RessourceInterceptor
ProjectManager
TaskManager
MethodInterceptor
SessionControler
ProjectControler
UserController
AdvancementControl
Pro
ject
Da
o
Ta
skD
ao
Use
rDa
o
Ad
va
nce
me
nt
Da
o
Ro
leD
ao
Jou
rna
lDa
o
Transaction
1
2 3 4
5
6 7
8
9
10
Intercepteur
Rapport UML/Java 24
EPSI Montpellier | 2010
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
Rapport UML/Java 25
EPSI Montpellier | 2010
Diagramme de classe des entités
class entity
entity::Admin
+ Admin()
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
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
entity::Guest
- projects: List<Project>
+ getProjects() : List<Project>+ Guest()+ setProjects(List<Project>) : void
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
entity::Manager
- myProjects: List<Project>
+ getMyProjects() : List<Project>+ Manager()+ setMyProjects(List<Project>) : void
entity::Project
- beginDate: Calendar- collaborators: List<Collaborator>- endDate: Calendar- guest: List<Guest>- id: int- manager: Manager- name: String- tasks: List<Task>
+ 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
entity::Role
- id: int- users: List<User>- value: String
+ equals(Object) : boolean+ getId() : int+ getUsers() : List<User>+ getValue() : String+ Role()+ setId(int) : void+ setUsers(List<User>) : void+ setValue(String) : void
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()
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()
-tasks
0..*
-project
1
-myProjects
0..*
-manager 0..1
-comment 0..*
-advancement 1
-assigned
0..*
-task
0..1
-tasks 0..*
-collaborator 1
-users
0..*
-roles
0..*
Rapport UML/Java 26
EPSI Montpellier | 2010
Diagramme des classes de l’application
class dao
TypeId
dao::AbstractDao
- 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
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::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
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::UserDao
+ get(String) : User+ get(String, String) : User+ getAll() : List<User>+ merge(User) : User+ persist(User) : void+ refresh(User) : void+ remove(User) : void+ UserDao()
Rapport UML/Java 27
EPSI Montpellier | 2010
Diagramme des classes de la session utilisateur
class controler
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
controler::ProjectControler
- projectDao: ProjectDao- taskDao: TaskDao
+ 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
controler::SessionInformation
- user: User
+ getUser() : User+ SessionInformation()+ setUser(User) : void
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()
dao
+ AbstractDao
+ AdvancementDao
+ BddSchemaCreator
+ EntityManagerProvider
+ ProjectDao
+ RoleDao
+ TaskDao
+ UserDao
(from project)
-userControler
-sessionInformation
-projectControler
-advancementControler
Rapport UML/Java 28
EPSI Montpellier | 2010
Diagramme d’activités
Diagramme d’activité de 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).
act Activité global
JSFConteneur de servletSpringProgramme
Demarrage duprogramme
Analyse web.xml
Instanciation des servlets du programme
Analyse des fichiers de configuration
Définition des filtres
Instanciation des Manager de persistance
Instanciation des Dao
Attente d'une connection
Définition du contexte JSF
Définition des mapping des URL
Fin du lancementde l'application
Instanciation de la servlet JSF
Rapport UML/Java 29
EPSI Montpellier | 2010
Sécurité
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é.
act Securité
Conteneur de servlet Spring Programme
Reception requete
Verification filtre Verification de l'utilisateur
Utilisateur valide ?
Utilisateur déjaenregistré ?
Verification des droit d'accès
Afficher page d'authentification
Url ?
Enregistrement de l'utilisateur
Détacher l'utilisateur de la session
Roles valide ?Afficher page
Afficher l'erreur
[Urld'authentification]
[Autre]
[Non]
[Oui] [Oui]
[Non]
[Url de deconnection]
Rapport UML/Java 30
EPSI Montpellier | 2010
Diagramme de fonctionnement général du programme
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
act Fonctionnement général
JSFConteneur de servlet Spring
Securité
Reception requete
Url Affichage de la page
Reception demande méthode
Appel de la méthode du bean JSF
Execution des méthodes
«datastore»Modifications de la
base
Recherche des règles de navigation concernant la
page
Appel à la ressource concerné
Affichage d'une erreur d'accès a la ressource
Erreur
Finexecution
Securité
[*.jsf]
[Autre]
Rapport UML/Java 31
EPSI Montpellier | 2010
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.
Rapport UML/Java 32
EPSI Montpellier | 2010
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.
Annexe 1
Annexe 2
Annexe 3