ensemble me moire
TRANSCRIPT
Remerciements : D’abord, je loue l’Eternel qui m’a donné santé et qui m’a bénie, sans qui je ne pourrai
jamais faire ce mémoire.
Ce présent mémoire a lieu grâce au concours de certaines personnes à qui j’adresse un
sincère remerciement, entre autres :
Monsieur RAKOTOMALALA Vahatriniaina, notre Directeur de stage qui a su me transmettre
son savoir et ses acquis.
Monsieur ANDRIANIAINA Jean Marie, Directeur de la bibliothèque universitaire qui a bien
voulu m’accueillir au sein de son établissement,
Monsieur RABIAZAMAHOLY Marc, Directeur de la MISA ainsi que le corps enseignant de
la MISA,
Ma famille pour leurs soutiens financier et moral,
La MISA2007 en particulier Dosy, Hasina,
Enfin à tous ceux qui m’ont aidée de près ou de loin, qu’ils trouvent en ce mémoire ma
reconnaissance et ma gratitude.
Merci
TABLE DES MATIERES : INTRODUCTION …………………………………………………………………………….5I PRESENTATION GENERALE DU PROJET ............................................................. 6
I.1 PRESENTATION DE LA BIBLIOTHEQUE UNIVERSITAIRE : ................................. 7 I.1.1 Historique : ................................................................................................................. 7 I.1.2 Les conditions d’accès : ............................................................................................. 7 I.1.3 Le personnel de la bibliothèque : ................................................................................ 7 I.1.4 Structure de la bibliothèque universitaire : ................................................................. 8
I.2 Contexte du projet : ........................................................................................................... 9 I.3 Objectif du projet : ............................................................................................................. 9
II ANALYSE ................................................................................................................ 10 ............................................................................................................................................... 10 II.1 Analyse des besoins : ..................................................................................................... 11
II.1.1 Demande de congé et demande d’autorisation d’absence : ..................................... 11 II.1.2 Gestion de l’employé : ............................................................................................ 12
II.2 Fonctionnalités attendues : ............................................................................................. 12 II.2.1 Enregistrement d’un nouvel employé : ................................................................... 12 II.2.2 Consultation de la description de l’employé : ......................................................... 13 II.2.3 Suppression d’un employé : .................................................................................... 13 II.2.4 Demande de congé et demande d’autorisation d’absence : ..................................... 13 II.2.5 Droit et Sécurité: .................................................................................................... 14
II.3 La collecte d’informations : ........................................................................................... 15 II.4 Les technologies utilisées et les moyens techniques mis à disposition du stagiaire : .... 15
II.4.1 Au niveau de la base de données : Postgresql : ....................................................... 15 II.4.2 Langages utilisés : ................................................................................................. 16 II.4.3 Les logiciels utilisés : .............................................................................................. 17
III CONCEPTION ........................................................................................................ 19 III.1.1 Architecture de l’application : ................................................................................ 20
III.1.1.1 Struts : ............................................................................................................. 21 III.1.1.2 Spring .............................................................................................................. 21 III.1.1.3 Hibernate : ....................................................................................................... 22
III.2 Modélisation de la base de données : ............................................................................ 22 III.2.1 Le modèle conceptuel des données : ...................................................................... 22
III.2.1.1 La gestion de Permission et de Congé : .......................................................... 22 III.2.1.2 Gestion de la sécurité et structure de la bibliothèque : ................................... 25 III.2.1.3 La gestion du personnel : ................................................................................ 26
III.2.2 Modèle physique des données : ............................................................................. 27 III.2.2.1 La gestion de congé et de permission : ........................................................... 28 III.2.2.2 La gestion du personnel: ................................................................................. 29
IV PHASE DE DEVELOPPEMENT DE L’APPLICATION ......................................... 30 IV.1 DEVELOPPEMENT : .................................................................................................. 31
IV.1.1 La couche persistance : .......................................................................................... 31 IV.1.1.1 Les business objects : ...................................................................................... 31 IV.1.1.2 Les fichiers de mapping : ................................................................................ 31 IV.1.1.3 Les data Access Object (DAO) : ..................................................................... 31
IV.1.2 La couche service : ................................................................................................ 32
2
IV.1.2.1 Les services : ................................................................................................... 32 IV.1.2.2 Les transactions: ............................................................................................. 32 IV.1.2.3 ApplicationContext.xml : ................................................................................ 33 IV.1.2.4 Le testng : ........................................................................................................ 33
IV.1.3 La couche présentation : ........................................................................................ 33 IV.1.3.1 La maquette : .................................................................................................. 33 IV.1.3.2 Les action Struts : .......................................................................................... 37 IV.1.3.3 Les formulaires et leur validation : ................................................................. 37 IV.1.3.4 L’intégration des résultats des action struts dans les jsp : .............................. 37 IV.1.3.5 Configuration de struts : ................................................................................. 37
IV.2 Les problèmes rencontrés : ........................................................................................... 37 IV.3 Les tests sur l’application : ........................................................................................... 38 IV.4 RESULTATS : .............................................................................................................. 38
IV.4.1 Les fonctionnalités mises en place : ..................................................................... 38 IV.4.1.1 La gestion de congé et de permission : ........................................................... 38 IV.4.1.2 La gestion du personnel : ................................................................................ 38
V BILAN ET CONCLUSION : ..................................................................................... 39 VI BIBLIOGRAPHIE: .................................................................................................. 40 VII ANNEXE ................................................................................................................ 41
3
TABLE DES FIGURES :
Figure 1 : architecture multi-tiers ...........................................................................21Figure 2 : architecture de notre application...........................................................22Figure 3 : mcd congé permission ...........................................................................24Figure 4 :mcd de la structure de la bibliothèque et la sécurité............................25Figure 5 : mcd des renseignements sur les employés.........................................27Figure 6 : mpd de la gestion de congé et de permission......................................28Figure 7 : mpd de la gestion de personnel.............................................................29Figure 8 : Page de login............................................................................................33Figure 9 : menu pour le droit du directeur ............................................................ 34Figure 10 : Liste des employés................................................................................34Figure 11 : Page de demande de congé ou de demande de permission............ 35Figure 12 : recherche par division...........................................................................36Figure 13 : Enregistrement d’un nouvel employé................................................. 36
LISTE DES ABBREVIATIONS :
API : Application Programming Interface
BU : Bibliothèque Universitaire d’Antananarivo
DAO : Data Access Object
J2EE : java Enterprise Edition
MCD : Modèle conceptuel des Données
MISA : Maîtrise en informatique et Statistique Appliquées
MPD : Modèle Physique des Données
MVC : Model-view-controller
4
INTRODUCTION :
Si la réussite au sein d’une entreprise se fait sentir, on le doit premièrement aux
ressources humaines qu’elle dispose. Aussi, outre les objectifs fixés et les
obligations d’une société, motiver son personnel est un impératif. Ceci se traduit par
l’amélioration des outils utilisés, la formation du personnel ainsi qu’à l’application de
ses droits. C’est dans cette optique que l’idée est née à la bibliothèque universitaire
de mettre en place un logiciel de gestion des ressources humaines.
D’un autre côté, à la MISA, une école rattachée au département de Mathématiques
et Informatique, chaque étudiant doit effectuer un stage en entreprise pour boucler
les deux années passées à cet établissement dans le but d’obtenir une Maîtrise en
Informatique et Statistiques Appliquées. Pour passer cet infaillible stade, nous avons
passé six mois de stage à la bibliothèque universitaire d’Antananarivo.
Notre mission a été de réaliser l’application qui gère les congés, les autorisations
d’absence ainsi que de concevoir un outil générique de gestion du personnel. Nous
détaillons dans ce présent document le déroulement de la réalisation de l’application.
La première partie aborde la présentation et les préfaces du projet. Ensuite, nous
parlerons des choix technologiques, l’architecture de l’application. La réalisation
proprement dite terminera ce mémoire.
5
I PRESENTATION GENERALE DU PROJET
6
I.1 PRESENTATION DE LA BIBLIOTHEQUE UNIVERSITAIRE :
I.1.1 Historique :
La Bibliothèque Universitaire de Madagascar a vu le jour à Befelatanana le lundi 18
janvier 1960. L’inauguration officielle a eu lieu le 10 novembre 1960 lors du
vernissage de l’exposition « Madagascar- Regards vers le passé».
Le 08 Octobre 1968, le bâtiment actuel à Ambohitsaina a été inauguré. En 1988, la
dénomination «Bibliothèque Universitaire d’Antananarivo» a été adoptée à la suite de
la décentralisation de la formation supérieure dans les chefs-lieux des provinces.
La BU occupe une superficie de 2758m² étendue sur trois niveaux. Elle comporte
deux grandes salles qui peuvent accueillir 500 personnes en places assises.
I.1.2 Les conditions d’accès :
L’accès à la BU est soumis aux conditions suivantes :
Pour la communauté universitaire : présentation de la carte d’étudiant ou de la
carte de service pour les enseignants, le personnel administratif et financier.
Présentation de la carte d’adhérent pour les lecteurs autorisés. Pour
l’adhésion, il faut fournir une photo d’identité, un certificat de résidence, une
attestation d’emploi pour les salariés, un droit d’adhésion.
I.1.3 Le personnel de la bibliothèque :
La bibliothèque universitaire compte à son actif 58 employés répartis dans quatorze
divisions dont : L’administration des bases de données, l’infothèque, le Centre
d’Accès Internet, la division Madagascar Océan Indien, la division Lettres et
Sciences Humaines, la division Droit et Sciences Sociales, la division Médecine, la
division Sciences et Techniques, la division Recherche Documentaire, la division
Personnel, la division Maintenance, la division Reliure, la division Réprographie, la
division Acquisition et la division Comptabilité.
7
I.1.4 Structure de la bibliothèque universitaire :
PRESIDENT DE L’UNIVERSITE
VICE-PRESIDENT CHARGE DES RELATIONS AVEC LES
INSTITUTIONS, DU PARTENARIAT ET DE LA COMMUNICATION
DIRECTEUR DE LA BIBLIOTHEQUE UNIVERSITAIRE
Adjoint du Directeur Chargé du service technique
Adjoint au Directeur chargé du Service Général et
Administratif
Infothèque
CAI
Madagascar Océan Indien
Lettres et Sciences humaines
Droit et Sciences Sociales
Médecine
Personnel
Maintenance
Reliure
Reprographie
Acquisition
Administration de la base de données Comptabilité
8
I.2 Contexte du projet :
La bibliothèque universitaire est en train de mettre sur pieds des projets qui
changeront l’aspect de cette entité ainsi que les services qu’elle offre aux adhérents.
Ces projets s’orientent généralement à la mise en place des systèmes informatisés
que ce soit pour les membres de la bibliothèque que pour les employés.
Parmi ces projets figure la conception d’un logiciel de gestion des ressources
humaines de la bibliothèque.
I.3 Objectif du projet :
L’objectif est d’avoir une application qui sera à la fois :
• Un outil de communication entre les employés
• Un outil qui permet de trouver facilement les informations sur les employés
• Un outil de gestion des droits des employés (congé, distinctions honorifiques,
permissions)
• Un outil qui simplifie le suivi des employés
• Un outil de suivi des évolutions des évènements concernant les employés
(démission, départ à la retraite, congé, permission,…).
• Un outil qui donne un aperçu en temps réel de la situation administrative des
employés.
Comme la bibliothèque ne dispose pas assez de personnel pour développer cette
application, de plus Le Directeur souhaite que ce soit un développement en interne
c’est-à-dire qu’il veut engager quelqu’un à la bibliothèque universitaire afin de
réaliser le projet ; Nous avons été engagée comme stagiaire au sein de cet
établissement. L’ensemble de notre mission était :
D’étudier la faisabilité du projet : l’analyse des besoins, la collecte des
informations nécessaires.
De proposer les technologies utilisées dans l’application mais également de les
fournir en fonction des nécessités et de ceux qui existent à la bibliothèque
De concevoir la base de données
De développer l’application et enfin pour former les utilisateurs au terme du
stage.
9
II ANALYSE
10
II.1 Analyse des besoins :
II.1.1 Demande de congé et demande d’autorisation d’absence :
Les processus de demande de congé et de demande de permission au sein de la BU
se passent comme suit auparavant :
Il faut suivre quatre étapes avant d’obtenir un congé ou une permission :
1. D’abord, après avoir rempli sa demande de permission, chaque employé doit
l’emmener au chef de division qui lui est appropriée.
2. Le chef de division doit approuver cette demande pour qu’elle puisse passer
à l’étape suivante. S’il refuse la demande, celle-ci retourne au demandeur.
3. C’est au tour de l’adjoint du directeur chargé des affaires techniques ou des
affaires générales d’approuver la demande après le passage au chef de
division.
4. Enfin, Le directeur de la bibliothèque universitaire signe la demande qui est
acheminée à la présidence de l’université.
DIRECTEUR
ADJOINT DU DIRECTEUR
ADJOINT DU DIRECTEUR
DIVISION DIVISIONDIVISION DIVISION DIVISION DIVISION
11
De plus, ces processus se présentent non seulement lors de la demande de congé
ou permission mais à toutes les paperasses administratives des employés.
Quelles en sont les conséquences ?
• D’abord, comme ces processus se passent manuellement, Il y a donc perte de
temps qui diminuerait les heures consacrées aux travaux proprement dits.
• On ne sait pas exactement qui sont en congé
• Chacun calcule dans sa tête le droit de congé qui lui est resté sinon les
responsables du personnel doivent encore consulter dans les archives des
renseignements de l’employé.
II.1.2 Gestion de l’employé :
L’insertion d’un nouvel employé au sein de la bibliothèque universitaire se fait sur
papiers. Nombreux sont les inconvénients de cette méthode archaïque :
• Le tri des employés que ce soit par division ou par grade est faisable
seulement après consultation des archives sur les renseignements de
l’employé
• Cette dernière est d’ailleurs très difficile à faire étant donné qu’on doit voir tous
les dossiers des employés
• Une mise à jour de la fiche d’un employé est peu recommandée
II.2 Fonctionnalités attendues :
II.2.1 Enregistrement d’un nouvel employé :
Ceci englobe l’enregistrement des
Renseignements personnels de l’employé ceux de son époux (se) et ceux de
ses enfants
Renseignements sur les diplômes obtenus
Les expériences professionnelles et les stages
Les distinctions honorifiques qu’il a obtenues
La place qu’il va occuper au sein de la bibliothèque universitaire ( grade,
division, imputation budgétaire)
12
II.2.2 Consultation de la description de l’employé :
La consultation des descriptions d’un employé résulte de la recherche multicritère sur
la liste des employés.
Liste de tous les employés de la bibliothèque universitaire
La liste des employés par division
Aussi, après ces recherches, on veut voir les renseignements détaillés sur l’employé
recherché ou éventuellement modifier ces renseignements (selon le droit de
l’utilisateur).
II.2.3 Suppression d’un employé :
Il ne s’agit pas de supprimer définitivement l’employé de la base de données mais de
lui attribuer le statut non actif c’est-à-dire en précisant la raison de sa
suppression(démission, retraite, licenciement) et de la date de son départ de la BU.
II.2.4 Demande de congé et demande d’autorisation d’absence :
Il s’agit d’informatiser les processus étalés ci-dessus :
Un formulaire de demande de congé ou d’autorisation d’absence est à remplir
par chaque membre du personnel voulant demander un congé ou une
autorisation d’absence.
La validation des demandes dans l’application se fait exactement comme
dans ce qui existait avant c’est-à-dire étape par étape (Chef de division puis
adjoint du directeur et Directeur).
Chaque employé peut consulter son droit de congé dans le logiciel.
Un tableau de bord rafraîchi à un temps précis sera présenté à chaque chef
de division, chaque adjoint du directeur ainsi qu’au Directeur afin de leur
permettre de réagir au moindre événement qui nécessite leur attention et leur
validation (Cas de la demande d’autorisation d’absence).
L’application donnera également la liste des employés en congé et en
permission le jour où on consulte cette fonctionnalité.
13
La liste des congés pris entre deux dates seront aussi présentée dans cette
application.
II.2.5 Droit et Sécurité:
La sécurité de l’application est de mise étant donné qu’elle fait circuler des données
confidentielles ; c’est pourquoi chaque employé aura son propre login et mot de
passe pour entrer dans l’application. L’authentification sera également régie par des
droits selon la hiérarchie au sein de la bibliothèque. C’est en fonction de ces droits
que seront réparties les actions dans l’application :
Droit Type de l’employé ActionsDirecteur Directeur Toutes les fonctionnalités
seront accessibles Adjoint du
directeur
Adjoint du directeur Toutes les fonctionnalités
accessibles par le simple
utilisateur
Validation des demandes
déjà passées aux chefs
de divisions
Consulter les employés
en congéChef de division Chef de division Toutes les fonctionnalités
accessibles par le simple
utilisateur
Validation des demandes
de congé et permission
au sein de sa divisionSimple utilisateur Employé dans chaque
division
Demander un congé ou
une permission
Consulter son droit de
congé
Consulter les détails des
renseignements le
concernant
14
Changer son mot de
passe
II.3 La collecte d’informations :
Afin de concevoir une application facile à recycler, réutilisable et surtout afin de
faciliter la mise en place d’autres modules dans l’application, nous avons pensé à
rassembler tous les moyens et les données non seulement concernant les congés et
les permissions mais également celles d’une gestion de personnel toute entière.
Pour avoir toutes les informations nécessaires à la mise en œuvre du projet, nous
nous sommes donc entretenues avec le responsable du personnel. Ainsi, on a pu
avoir les informations qui doivent figurer sur la fiche personnelle de chaque
employé : les renseignements personnels, les diplômes obtenus , les expériences
acquises avant et pendant le travail à la bibliothèque ; les stages effectués par la
personne depuis son arrivée , ainsi que les distinctions honorifiques déjà obtenues.
Pour les congés et les permissions, ce sont surtout les règles qui régissent la
demande de celles-ci; par exemple la durée du congé qui ne devra pas excéder le
droit fixé à un mois de 30 jours par an.
II.4 Les technologies utilisées et les moyens techniques mis à disposition du stagiaire :
II.4.1 Au niveau de la base de données : Postgresql :
Le système de gestion de base de données que nous utilisons devra avoir les
caractéristiques exigées par la mise en œuvre de notre application. Aussi,
• Vu qu’on ne doit pas se créer des problèmes avec le prix et le coût, le SGBD
doit être gratuit ou open source
• Il doit gérer les transactions puisque qu’il faut qu’on ne valide les opérations
sur la base de données que si elles sont correctement effectuées.
• Il doit être puissant et stable puisqu’il contiendra des données à la fois
importante et énorme.
15
• On doit également se référer à ce qui existe dans la bibliothèque dans les
différentes applications qu’elle dispose.
Après ce diagnostic, nous avons opté pour PostgreSQL qui répond à ces critères.
De plus, postgresql repose sur le modèle relationnel, c’est-à-dire qu’il dispose
d’un ensemble de données structurées dans la table dont les colonnes peuvent
servir de liaisons entre les autres tables.
II.4.2 Langages utilisés :
JAVA : Pour le développement de notre application, on a utilisé java étant donné que celui-ci
fournit des avantages énormes :
D’abord, java est orienté objet. La programmation orientée objet permet la modularité
de l’application qui implique une facilité au niveau de l’organisation et de la
conception. On pourra aussi réutiliser les codes pour les prochains projets.
Java est également indépendant de toute plate-forme.
Il dispose de nombreux APIs qui permettent de s’interfacer avec des systèmes
d'information existants. Ces APIs sont entre autres : JDBC pour l’accès à la base de
données.
JSP : Les JSP (Java Server Pages) sont une technologie de java qui permettent la
génération des pages web dynamiques. Ils permettent d'introduire du code Java
dans des tags prédéfinis à l'intérieur d'une page HTML. La technologie JSP mélange
la puissance de Java côté serveur et la facilité de mise en page d'HTML côté client.
Les JSP ont pour rôle de séparer la partie présentation et la logique métier.
Javascript :
Javascript est le langage de validation des formulaires par excellence. Il permet de
vérifier les données entrées par le client, selon la conformité aux types de données
qui doivent être introduites. En outre, ce langage permet d’introduire d’autres champs
selon le choix du client parmi les listes de choix proposées. Pour l’illustration, un
menu des situations matrimoniales est proposé dans le formulaire d’enregistrement
16
d’un nouvel employé, si l’employé n’est pas célibataire, des renseignements sur son
conjoint sont exigés.
Xml :
Notre application a demandé une grande connaissance de xml étant donné que tous
les fichiers de configuration doivent être écrits avec ce langage. Par exemples, les
fichiers de mapping de hibernate, l’applicationcontext de spring ainsi que le fichier de
configuration de struts.
II.4.3 Les logiciels utilisés :
Poweramc :
On a utilisé poweramc lors de la modélisation de la base de données c’est-à-dire
pendant la conception du modèle conceptuel des données, la réalisation du modèle
physique des données. Ce logiciel fournit quatre types de modélisation à savoir :
• Le modèle conceptuel des données ( MCD)
• Le modèle physique des données
• Le modèle orienté Objet
• Le modèle de processus de métiers.
Eclipse :
On a utilisé l’éditeur eclipse 3.2 pour faire tout le projet, en effet, eclipse prend en
charge la cohabitation des classes java, jsp,… Nous avons ajouté à cet éditeur le
plugin « lomboz » afin de lui permettre de déployer les modules j2ee.
Apache :
Apache est le serveur web que nous avons utilisé. C’est le serveur http le plus
répandu à travers le monde, il est sécurisé et stable, de plus c’est un logiciel open
source.
Display tag et les EL :
17
Les Expressions Languages (EL) permettent de manipuler les données au sein d'une
page JSP (ou d'un fichier *.tag) plus simplement qu'avec les scriptlets Java. Une EL
permet d'accéder simplement aux beans des différents scopes de l'application web
(page, request, session et application). Utilisée conjointement avec des librairies de
tags, elle permet de se passer totalement des scriptlets. Les display tag sont des
open source librairies de tags qui fournissent une présentation web de haut niveau,
ils sont adaptés pour fonctionner dans les architectures MVC(Modèle Vue côntrole).
18
III CONCEPTION
19
Après les analyses des besoins et les choix des outils, nous entrons dans la phase
de conception qui consiste à donner la structure globale de l’application. Nous avons
été amenées à regrouper les fonctionnalités de notre application en deux parties :
La gestion de l’employé, la gestion de congé et la gestion de permission.
III.1.1 Architecture de l’application :
Tout système d'information nécessite la réalisation de trois groupes de fonctions: le
stockage des données, la logique applicative et la présentation. Ces trois parties sont
indépendantes les unes des autres: on peut ainsi vouloir modifier la présentation
sans modifier la logique applicative. La conception de chaque partie doit également
être indépendante, toutefois la conception de la couche la plus basse est utilisée
dans la couche d'au dessus. La conception de la logique applicative se base donc
sur le modèle de données, alors que la conception de la présentation dépend de la
logique applicative.
Nous avons donc choisi l’architecture multi-tiers pour notre application. Elle hérite
l’architecture trois-tiers qui consiste à séparer la réalisation des trois parties vues
précédemment (stockage des données, logique applicative, présentation). La mise
en place de ce type d'architecture permet une plus grande évolutivité du système.
Les éléments permettant la réalisation classique d'un système en architecture trois
tiers sont les suivants:
• système de base de donnée relationnel (SGBDR) pour le stockage des
données
• serveur applicatif pour la logique applicative
• navigateur web pour la présentation
L’inconvénient de l’architecture trois-tiers est l’implémentation des métiers dans le
code d’affichage. Ce dernier ne sera pas alors réutilisable.
D’où le choix de l’architecture multi-tiers. L'avantage principal de celle-ci est la facilité
de déploiement. L'application en elle même n'est déployée que sur la partie serveur
(serveur applicatif et serveur de base de données). Le client ne nécessite qu'une
installation et une configuration minime.
20
Figure 1 : architecture multi-tiers
III.1.1.1Struts :
Dans notre application, La couche présentation est assurée par le framework Struts
qui est un projet d’Apache Software Foundation, il a pour but de fournir un cadre
standard de développement d'applications web en Java respectant l'architecture
trois-tiers.
III.1.1.2Spring
Nous avons choisi spring pour faire la logique applicative avec hibernate. SPRING
est un conteneur dit « léger », c'est-à-dire une infrastructure similaire à un serveur
d'application J2EE. Il prend donc en charge la création d'objets et la mise en relation
d'objets par l'intermédiaire d'un fichier de configuration (applicationcontext.xml) qui
décrit les objets à fabriquer et les relations de dépendances entre ces objets.
SPRING propose tout un ensemble d'abstractions permettant de gérer entre autres :
• Le mode transactionnel
• La persistance d'objets
• La création d'une interface Web
• L'appel et la création de WebServices
Serveur de base données
Serveur d’affichage Serveur d’application
21
III.1.1.3Hibernate :
Hibernate est quant à lui chargé de la persistance des objets. Il fait la relation des
requêtes avec les objets. Pour cela, hibernate utilise le langage HQL (Hibernate
Query Language) ou avec un API associé à java, le HQL utilise les objets au lieu des
tables et les attributs au lieu des colonnes. Une image qui illustre l’architecture de
notre application :
Figure 2 : architecture de notre application
III.2 Modélisation de la base de données :
III.2.1 Le modèle conceptuel des données :
Nous avons affirmé précédemment que dans l’architecture multi-tiers la conception
de la couche plus basse dépend de celle d’en haut. Il faut donc penser au
déploiement de la logique applicative dans la conception de la base de donnée.
Notre système d’information est divisé en trois parties qui se résument par la gestion
des congés et des permissions, la gestion du personnel qui englobe les catégories,
la description de l’employé et ses acquis, enfin la structure de la bibliothèque avec la
gestion de la sécurité.
III.2.1.1La gestion de Permission et de Congé :
III.2.1.1.1Consultation du droit de congé : Tous les employés enregistrés dans la base de données peuvent consulter leur droit
de congé restant pour l’année en cours sous réserve d’être authentifié à son compte.
Chaque employé a droit à un mois de congé soit 30jours par an. Celui-ci peut
cumuler son congé mais le droit de congé cumulé ne peut pas dépasser les 90 jours.
22
III.2.1.1.2Enregistrement d’une demande de congé et d’une demande de permission:
Chaque employé de la bibliothèque universitaire peut demander un congé ou une
permission (autorisation d’absence). Des états de congé et de permission régissent
cette demande : au cas où c’est un employé que nous appelons simple utilisateur qui
demande un congé (éventuellement une permission), la demande passe d’abord par
l’état 1, si c’est un chef de division, la demande est tout de suite à l’état 2 ; état 3
pour l’adjoint du directeur et état 4 pour le directeur.
Lorsque une demande de congé a un état 4, cela veut dire que le demandeur a
obtenu un congé donc on peut retrancher au droit de congé le nombre de jours
demandés. La date de la demande de congé et le début de congé doit s’espacer de
15 jours.
Si le nombre de jours écrit par le demandeur dans le formulaire excède donc le droit
de congé qu’il dispose, l’application retourne une erreur.
Pour la permission, chaque employé a droit généralement 15 jours par an, et une
seule permission ne doit pas excéder 3 jours.
III.2.1.1.3Validation d’une demande de congé et de permission : Les chefs de divisions, les adjoints du directeur ainsi que le directeur lui-même
peuvent accéder à cette fonctionnalité. Une validation consiste à changer le statut ou
état du congé et de la permission.
Les chefs de divisions valident les demandes de congé des employés qui sont
rattachés à sa division, ils changent l’état 1 des demandes en état 2. Les adjoints du
directeur valident les demandes qui ont un état 2 et qui appartiennent à ses
responsabilités. Le directeur change le statut 3 à l’état 4. La non-validation d’une
demande signifie que la demande a été refusée et l’application tient le demandeur
au courant de cela.
Au cas où c’est le chef de division qui demande un congé :
1. Si la division est rattachée aux affaires générales (secrétariat,
Recherche documentaire, Maintenance, Reliure, Acquisition) la
demande passe à l’adjoint aux affaires générales avant de passer à la
direction.
23
2. Si la division est rattachée aux affaires techniques (Fonds local, CAI,
Médecine, Sciences, Droit, Lettres, Infothèque), la demande passe à
l’adjoint aux affaires techniques avant de passer à la direction.
III.2.1.1.4Consultation des employés en congé et en permission : Les adjoints du directeur et le directeur peuvent voir les personnes en congé ou en
permission le jour où il est connecté à l’application.
On a déduit de cette analyse le modèle conceptuel de données suivant :
Figure 3 : mcd congé permission
24
III.2.1.2Gestion de la sécurité et structure de la bibliothèque :
III.2.1.2.1Authentification : L’authentification est régie par l’entrée d’un login et d’un mot de passe. Chaque
employé possède un compte qui lui permet d’entrer dans l’application. Comme c’est
une application qui fait tourner des données confidentielles, nous avons insisté sur la
sécurité. Le droit prend un rôle important également, car il limite les fonctionnalités
qu’un employé peut faire dans le logiciel. Le droit dépend de la fonction de la
personne à la bibliothèque d’où la sécurité va de pair avec la structure hiérarchique à
la bibliothèque.
III.2.1.2.2La création d’un compte : La création d’un compte est réservée au directeur de la bibliothèque juste après
l’enregistrement de l’employé. Lorsque la personne est connectée dans l’application,
elle peut changer son mot de passe.
Le modèle conceptuel correspondant est donc le suivant :
Figure 4 :mcd de la structure de la bibliothèque et la sécurité
25
III.2.1.3La gestion du personnel :
III.2.1.3.1L’Enregistrement d’un nouvel employé : Seul, le directeur de la bibliothèque sera autorisé à enregistrer un nouvel employé. Il
doit donc être connecté en tant que tel. Certains détails comme tous les
renseignements personnels y compris ceux des enfants, si le nouvel employé en a et
ceux de l’éventuel époux sont obligatoires. En général les données qui doivent être
enregistrées sont :
• Les renseignements personnels
• Les diplômes obtenus
• Les expériences acquises
• Les distinctions honorifiques obtenues
• Les fonctions que le nouvel employé va occuper au sein de la BU.
III.2.1.3.2Consultation des descriptions d’un employé : Après une recherche multicritère, par division, par ordre alphabétique, le directeur et
les adjoints du directeur peuvent voir les descriptions d’un employé. Ceci implique
également qu’ils peuvent voir la liste de tous les employés de la bibliothèque.
Toutefois, chaque employé peut accéder à sa fiche personnelle en se connectant
dans son compte.
III.2.1.3.3Modification des descriptions d’un employé : Après une recherche multicritère, le directeur peut changer le profil d’un employé.
Les renseignements sur l’employé sont affichés en guise de valeurs par défauts d’un
formulaire, il peut alors modifier ce formulaire.
III.2.1.3.4Suppression d’un employé : Le directeur de la bibliothèque est habilité à supprimer un employé. Ce dernier n’est
pas rayé de la base de données mais sa fiche sera simplement munie d’une date de
suppression et de la raison de la suppression : démission, retraite, licenciement.
Le modèle conceptuel des données est le suivant :
26
Figure 5 : mcd des renseignements sur les employés
III.2.2 Modèle physique des données :
Après la validation des MCD, nous avons entamé la conception du modèle logique
des données suivie du modèle physique des données. Nous avons divisé ce dernier
en deux parties : la gestion de congé et de permission d’un côté et la gestion de
personnel de l’autre.
27
III.2.2.1La gestion de congé et de permission :
Figure 6 : mpd de la gestion de congé et de permission
28
III.2.2.2La gestion du personnel:
Figure 7 : mpd de la gestion de personnel
29
IV PHASE DE DEVELOPPEMENT DE L’APPLICATION
30
IV.1 DEVELOPPEMENT :
Après avoir mis en place la base de données à utiliser, Pour chaque cas d’utilisation,
on a suivi le plan suivant lors du développement de l’application :
IV.1.1 La couche persistance :
C’est dans cette couche que Hibernate entre en jeu.
IV.1.1.1Les business objects : Nous avons d’abord créé des classes dites Business Object qui correspondent à
chaque entité et chaque association du modèle conceptuel des données.
IV.1.1.2Les fichiers de mapping : Nous avons créé après, les fichiers de mapping qui indiquent à hibernate dans
quelle table de la base de données doit-il accéder et quelles colonnes de cette table
il utilise. A une classe du business object est associée un fichier de mapping. Ces
fichiers sont écrits en xml, ils donnent également à hibernate l’indication de relier une
table avec une autre (Relation une-à-une, relation une-à-plusieurs, héritage,.. .).
IV.1.1.3Les data Access Object (DAO) : Puis, nous avons créé les interfaces DAO qui servent simplement à faire les
opérations génériques pour accéder à la base de données à partir des classes
conçues précédemment:
1. la suppression des données
2. l’insertion
3. la mise à jour des données
4. la liste des objets
Une fois les interfaces DAO mises en place, il faut créer les classes DAO qui les
implémentent.
31
IV.1.2 La couche service :
IV.1.2.1Les services : Les services sont en réalité les fonctionnalités de l’application. Cette partie est
assurée par spring. Nous avons conçu les interfaces services qui correspondent
d’abord aux opérations faites dans les DAO. Puis à chaque cas d’utilisation
correspond un service, on y cite les méthodes pour faire une fonctionnalité. Nous
avons procédé ensuite à la création des classes services qui implémentent les
interfaces de service, spring a appelé les DAO pour fabriquer les méthodes dans les
classes services.
IV.1.2.2Les transactions:
Pour exécuter les séries de requêtes qui devront être faites ensemble ou les
transactions, nous avons pris l’avantage de spring qui offre ce module en l’intégrant
dans le fichier de configuration de spring. Ci-dessous un extrait de ce fichier qui
donne les paramètres de transaction.
32
<bean id="dataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource"><property name="driverClassName">
<value>org.postgresql.Driver</value></property><property name="url">
<value>jdbc:postgresql://localhost:5432/vdfidb</value></property><property name="username">
<value>postgres</value></property><property name="password">
<value></value></property>
</bean><bean id="transactionManager"
class="org.springframework.orm.hibernate3.HibernateTransactionManager"><property name="sessionFactory" ref="sessionFactory" />
</bean><bean id="hibernateTemplate"
class="org.springframework.orm.hibernate3.HibernateTemplate"><property name="sessionFactory">
<ref bean="sessionFactory" /></property>
</bean>
IV.1.2.3ApplicationContext.xml : C’est un fichier de configuration de spring, il indique à ce dernier les fichiers de
mapping d’hibernate, la liste des DAO et enfin la liste de tous les services de
l’application. On y trouve également les paramètres de configuration pour établir la
connexion d’hibernate à la base de données.
IV.1.2.4Le testng : Spring est pourvu d’un module appelé testng qui sert à faire des tests internes dans
l’application. Une fois les services mis en place, nous avons créé des classes pour
tester la crédibilité et le fonctionnement de nos services. Il s’agit des classes qui
testent les fonctionnalités de l’application sans l’affichage web. Le testng parcourt la
classe et exécute les méthodes publiques affiche le résultat dans le console
d’Eclipse.
IV.1.3 La couche présentation :
La couche présentation est assurée par le framework struts.
IV.1.3.1La maquette : Nous avons élaboré les formes générales des pages, la présentation de celles-ci
pour chaque fonctionnalité, les informations à mettre sur chaque page.
IV.1.3.1.1La page de login : Voici la page lors de l’ouverture de la session :
Figure 8 : Page de login
33
IV.1.3.1.2Le menu : Le menu varie selon le droit de chaque utilisateur, l’affichage du menu est géré par la
variable de session.
Figure 9 : menu pour le droit du directeur
IV.1.3.1.3Les listes : Les listes affichées dans l’application à savoir, liste des employés trouvés après une
recherche ont l’allure suivante :
Figure 10 : Liste des employés
34
IV.1.3.1.4La demande de congé et la demande de permission : Comme les renseignements personnels nécessaires à la demande à savoir le nom et
prénoms du demandeur, sa fonction, son grade et son immatricule sont récupérables
par la session, seules les informations sur le congé ou la permission sont
indispensables dans le formulaire de demande de congé ou de demande de
permission.
Figure 11 : Page de demande de congé ou de demande de permission
IV.1.3.1.5La recherche d’employé par division : La liste des divisions dans le formulaire provient de la base de données.
35
Figure 12 : recherche par division
IV.1.3.1.6La page d’enregistrement d’un nouvel employé : Voici une partie des renseignements à insérer lors de l’enregistrement d’un nouvel
employé.
Figure 13 : Enregistrement d’un nouvel employé
36
IV.1.3.2 Les action Struts : Les action struts sont des classes que nous avons créées afin de gérer les requêtes
demandées par les clients et les réponses qui leur sont envoyées d’un côté et les
services mis en place de l’autre. Ce sont donc des classes qui relient la couche
service et celle de l’affichage. On y trouve la déclaration des variables de session et
les variables de httprequest, la manipulation de ces variables et des services
spécifiques. Elles retournent enfin les résultats qui seront affichés dans les pages
jsp.
IV.1.3.3Les formulaires et leur validation : Les informations à insérer dans la base de données passent par les formulaires, il
faut s’assurer de la compatibilité des types de ces données, nous avons donc
associé aux formulaires des fichiers javascript pour les valider et pour tester les
champs vides.
IV.1.3.4L’intégration des résultats des action struts dans les jsp : Nous disposons des formes des pages, des formulaires, de leur validation et enfin
des résultats obtenus dans les classes action struts. Nous sommes amenées par la
suite à intégrer ces résultats dans les pages jsp :
• La manipulation des variables de session pour connaître le rôle attribué à la
personne connectée puisque le menu en dépend.
• Les résultats envoyés par les action struts sont traités par les displaytag et les
expressions langages qui sont chargés de les afficher.
IV.1.3.5Configuration de struts : Nous avons également fait la configuration de struts dans cette couche, avec le fichier struts-config.xml.
IV.2 Les problèmes rencontrés :
Les prises en main des technologies ont retardé le démarrage du développement
étant donné que ces outils sont nouveaux pour nous.
L’ordinateur que nous avons utilisé ne permet pas d’avoir la configuration optimale
exigée par l’éditeur et par les technologies utilisées, ce problème a freiné notre
rythme de travail. Des solutions ont été apportées à ces blocages grâce à l’achat de
nouveaux matériels adaptés.
37
IV.3 Les tests sur l’application : Des tests sont effectués dans l’application, d’abord le testng, au niveau des
services ; puis nous avons testé également au niveau de l’affichage et enfin des
tests sur les fonctionnalités entières sont entrepris , ils étaient basés sur les cahiers
de test.
IV.4 RESULTATS :
IV.4.1 Les fonctionnalités mises en place :
Après le développement et les tests, les fonctionnalités mises en place et qui sont
opérationnelles sont :
IV.4.1.1La gestion de congé et de permission :
• Les demandes de congé et de permission
• Les validations des demandes au niveau des chefs de divisions, des adjoints
du directeur et du directeur de la BU.
• La liste des personnes en congé ou en permission
• Le tableau de bord du directeur qui montre les congés, les permissions en
attente ainsi que les employés en congé,
• La consultation du droit de congé de chacun
IV.4.1.2La gestion du personnel :
• L’enregistrement d’un nouvel employé
• La suppression d’un employé
• La recherche multicritère d’un employé
• La modification du profil d’un employé
• Le tri des employés par division ou par grade.
Notons qu’une version imprimable est proposée après l’obtention d’un congé d’une
permission, et après l’enregistrement d’un nouvel employé.
38
V BILAN ET CONCLUSION :
Un bilan positif pour la bibliothèque universitaire d’Antananarivo qui dispose
désormais d’un système de gestion de personnel opérationnel. Elle a en effet atteint
son objectif du début du projet : informatiser les processus de demande de congé et
de permission et les informations sur les employés. La prochaine étape serait sans
doute d’optimiser cette application en ajoutant d’autres fonctionnalités :
L’automatisation de l’attribution des distinctions honorifiques et des promotions selon
le nombre d’années passées au service de la bibliothèque par exemple. La base de
données conçue est d’ailleurs adaptée à des nouvelles fonctionnalités comme celle-
là. Les codes seront réutilisables donc simplifient leur développement.
Nous avons appris de notre côté à appliquer et adapter les acquis théoriques dans
une application qui a exigé des compétences adéquates. De nombreux leçons sont
reçues de cette expérience : la conduite de projet, la vie professionnelle,
l’enrichissement de notre bagage intellectuel.
39
VI BIBLIOGRAPHIE: [ John C. Worsley & joshua D. Drake], PostgreSQL par la pratique, 2002, Edition
O’REILLY
[Claude DELANNOY], Programmer en java, 2004, Edition EYROLLES
Sites web visités :
Java.developpez.com : site du club des développeurs : section java
Java.sun.com : site officiel de Sun MicroSystems
www.hibernate.org: site officiel de hibernate
www.springframework.org : site officiel du framework Spring.
40
VIIANNEXE
41
Glossaire :
API(Application Programming Interface) : C’est un ensemble de fonctions
prédéfinies permettant de programmer des applications qui permettent d’obtenir des
bibliothèques de fonctions pour une programmation plus aisée .
Le protocole http(HyperText transfer Protocol) permet au navigateur web
d’interroger tout service Web qui, en réponse, retourne au navigateur des fichiers au
format HTML( Hypertext Markup Language).
JDBC (Java Database Connectivity) : un api qui permet de se connecter à une
base de données, à la recherche, à la récupération et à la manipulation des
données.
Serveur web : C’est un logiciel de service web installé sur une machine qui prend
ainsi l’appellation de serveur web. Il écoute et traite des requêtes http provenant des
clients.
Servlet : programme côté serveur qui permet d’embarquer la logique applicative
dans le processus de réponses aux requêtes http.
SQL : Langage standardisé des bases de données relationnelles permettant d’agir
sur la structure et les données d’une base de données.
42
Exemple de fichier de mapping : <?xml version="1.0"?><!DOCTYPE hibernate-mapping PUBLIC"-//Hibernate/Hibernate Mapping DTD 3.0//EN""http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"><hibernate-mapping package="bo.employee"><class name="Employe" table="employe">
<id name="id" type="integer" column="id_employe"><generator class="sequence">
<param name="sequence">employe_id_employe_seq</param></generator>
</id><property name="adresse" /><property name="nom" /><property name="prenom" /><property name="nomJeuneFille" column="nom_jeune_fille"/><property name="immatricule" column="im"/><property name="telephone"/><property name="numActeMariage" column="num_acte_mariage"/><property name="dateNaissance" column="date_naissance"/><property name="dateEntree" type="timestamp" column="date_entree"/><property name="dateSuppression" type="timestamp" column="date_suppression"/><property name="logement"/><property name="voiture"/><set name="listEnfants" table="enfant" inverse="true" cascade="all" >
<key column="id_employe" not-null="true"/> <one-to-many class="bo.employeDerivees.Enfant"/> </set> <set name="listDemandeConge" table="demande_conge" inverse="true" cascade="all" lazy="false">
<key column="id_employe" not-null="true"/> <one-to-many class="bo.congePermission.DemandeConge"/> </set> <set name="listDemandePermission" table="demande_permission" inverse="true" cascade="all" lazy="false">
<key column="id_employe" not-null="true"/> <one-to-many class="bo.congePermission.DemandePermission"/> </set>
<set name="listEmployeBanque" table="employe_banque" cascade="all" inverse="true" lazy="false">
<key column="id_employe" /> <one-to-many class="bo.employeDerivees.EmployeBanque" /> </set>
<set name="listEmployeDiplome" table="employe_diplome" cascade="all" inverse="true" lazy="false">
<key column="id_employe" /> <one-to-many class="bo.employeDerivees.EmployeDiplome"/> </set>
</hibernate-mapping>
43
Liste des services utilises et quelques méthodes principales:
44