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


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


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


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


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


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


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 en parallèle de l’architecture du logiciel. Nous avons également choisit de ne pas


Le plan de développement a été réalisé dans un intervalle de temps très court. Après avoir défini



chaque phase et les outils de développement.

Définition du cycle de vie du projet


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


Développement du code

métier


Rapport UML/Java 9



également choisit de ne pas


Le plan de développement a été réalisé dans un intervalle de temps très court. Après avoir définit 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


Développement du code


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

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.

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 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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

rapport uml/java - oomteam.free.froomteam.free.fr/epsi/rapport uml.pdf · ce rapport à pour but de...

Documents