1. Recherche Scientifique et de la Technologie
*** * ***
Universit´ de Carthage
e
*** * ***
Institut National des Sciences
Appliqu´es et de Technologie
e
´
Projet de Fin d’Etudes
Pour l’obtention du
Diplˆme National d’Ing´nieur
o e
en Sciences Appliqu´es et en Technologie
e
Fili`re : G´nie Logiciel
e e
Sujet :
Conception de l’architecture et d´veloppement
e
des modules d’un ERP Universitaire
R´alis´ par :Slimen Belhaj Ali
e e
Entreprise d’accueil :ITIPart
Responsable entreprise : Monsieur Allaeddinne Bahri
Responsable INSAT : Madame Saloua Ben yahia
Ann´e Universitaire : 2012/2013
e
2. Recherche Scientifique et de la Technologie
*** * ***
Universit´ de Carthage
e
*** * ***
Institut National des Sciences
Appliqu´es et de Technologie
e ,
´
Projet de Fin d’Etudes
Pour l’obtention du
Diplˆme National d’Ing´nieur
o e
en Sciences Appliqu´es et en Technologie
e
Fili`re : G´nie Logiciel
e e
Sujet :
Conception de l’architecture et d´veloppement
e
des modules d’un ERP Universitaire
R´alis´ par :Slimen Belhaj Ali
e e
Entreprise d’accueil :ITIPart
Responsable entreprise : Responsable INSAT :
Monsieur Allaeddinne Bahri Madame Saloua Ben yahia
Cachet & Signature Signature
Ann´e Universitaire : 2012/2013
e
3. DEDICACES
`
A mon p`re, ` qui je dois tout et qui m’a toujours montr´ le chemin a suivre dans la vie
e a e `
`
A ma m´re pour sa bont´, sa g´n´rosit´ et son d´vouement.
e e e e e e
`
A ma soeur Hanen, qui m’a toujours t´moign´e son soutien et son affection
e e
`
A mes fr´res, Salem, Adnen et Ahmed Amine pour qui j’ai une grande admiration.
e
`
A tous ceux qui m’ont aid´ a l’´laboration de ce travail
e` e
II
4. REMERCIMENT
Je voudrais avant tout adresser mes sinc`res remerciements aux personnes qui m’ont
e
apport´ leur aide et leur soutien durant tout le d´roulement de mon stage et notamment a :
e e `
Madame Saloua Ben Yahia pour sa collaboration, sa disponibilit´ et ses pr´cieux conseils.
e e
Madame Salwa Chaouali, pour son accueil chaleureux au sein de son entreprise ITIPart.
Monsieur Allaeddinne Bahri, Chef de projet chez ITIPart, a qui nous tenons a exprimer
` `
toute notre gratitude pour l’aide qu’il nous a prodigu´e durant toutes les phases de ce stage.
e
Tous les membres du jury pour avoir accept´ d’apporter leur jugement ` mon travail.
e a
III
12. LISTE DES TABLEAUX
2.1 Module gestion biblioth`que : messages ´mis et re¸us . . . . . . . . . . . . . . . 15
e e c
2.2 Module gestion des inscriptions et des formations : messages ´mis et re¸us
e c . . . 17
2.3 Module gestion des notes et des r´sultats : messages ´mis et re¸us . . . . . . . . 19
e e c
2.4 Module services administratifs et r´clamations : messages ´mis et re¸us . . . . . 21
e e c
5.1 Description de l’environnement logiciel utilis´ . . . . . . . . . . . . . . . . . . . 51
e
XI
13. ´ ´
INTRODUCTION GENERALE
De nos jours les entreprises expriment de plus en plus le besoin de capitalisation du savoir.
En effet l’information est de plus en plus un facteur crucial dans la gestion de l’entreprise et sa
relation aussi bien avec les partenaires externes (clients, fournisseurs) qu’avec les collaborateurs.
Cela va de mˆme pour les organisations de types ´ducatifs, instituts et universit´s, qui expriment
e e e
´galement le besoin d’acheminer rapidement et clairement l’information a tous ses acteurs. Ceci
e `
n´cessite de disposer des outils informatiques et des m´thodes de gestion.
e e
Les ERP d’entreprise se posent comme solution ´ventuelle de capitalisation du savoir. Son
e
objectif principal est de centraliser l’acc`s au syst`me d’information afin de pouvoir recenser les
e e
donn´es et les placer sur un tableau de bord ´lectronique. Ceci offre un suivi permanent des indi-
e e
cateurs de performances. Dans ce sens l’ERP est l’un des points clefs du syst`me d’information
e
d’entreprise actuel. Il agit en tant que concentrateur d’informations. C’est un excellent moyen
pour profiter des m´thodes de travail tel que le travail en ´quipe, le partage des ressources,
e e
l’acc`s aux services internes, et la collaboration entre les entreprises.
e
C’est dans ce contexte que la mise en place d’un ERP universitaire a ´t´ propos´e comme
ee e
un projet de fin d’´tude, pour pouvoir mettre en oeuvre toutes les possibilit´s offertes par les
e e
ERP d’entreprise et ´voluer du simple site web vers un ERP offrant plus de services et plus de
e
possibilit´s a ses adh´rents.
e ` e
1
14. ´ ´
. INTRODUCTION GENERALE
Le pr´sent rapport est de ce fait la synth`se des ´tapes de mise en oeuvre d’un ERP univer-
e e e
sitaire. Il a pour but de situer le contexte du projet, de d´crire son sujet, les m´thodes et outils
e e
utilis´s ainsi que les r´sultats obtenus. Il est organis´ comme suit :
e e e
Le premier chapitre intitul´ Pr´sentation du projet est consacr´ a la pr´sentation de
e e e ` e
l’organisme d’accueil, ainsi que la mise en contexte du projet. Nous expliquerons aussi dans
ce chapitre les notions th´oriques en relation avec notre sujet. C’est ´galement a ce niveau
e e `
que nous pr´senterons la m´thodologie que l’on va adopter tout au long de l’´laboration de ce
e e e
projet.
Le chapitre suivant s’intitule Pr´sentation de l’environnement technologique, dans ce
e
chapitre, nous pr´senterons nos besoins techniques ainsi que les diff´rents choix ´labor´s.
e e e e
La sp´cification et l’analyse des besoins seront pr´sent´es dans le troisi`me chapitre intitul´
e e e e e
Analyse et sp´cification des besoins dans lequel nous ´tudierons en d´tails les besoins
e e e
fonctionnels et non fonctionnels ainsi que la mod´lisation de ces besoins par le recours aux
e
diagrammes de cas d’utilisation.
Le quatri`me chapitre intitul´ Architecture et conception de la solution sera d´di´ `
e e e ea
la pr´sentation de l’architecture op´rationnelle et les architectures applicatives et offrira un
e e
aper¸u des patrons de conception utilis´s. Cet aper¸u m`nera a la conception des diff´rentes
c e c e ` e
fonctionnalit´s offertes.
e
Le cinqui`me chapitre intitul´ Mise en oeuvre et int´gration pr´sentera les ´tapes de la
e e e e e
r´alisation du projet et les tests ´labor´s.
e e e
Nous clˆturons ce rapport par une conclusion g´n´rale dans laquelle nous ´valuerons les
o e e e
r´sultats atteints et nous exposerons les perspectives ´ventuelles du pr´sent projet.
e e e
2
16. ´
CHAPITRE 1. PRESENTATION DU PROJET
1.1 Introduction
Dans ce chapitre, nous aborderons tout d’abord l’environnement du stage en pr´sentant
e
l’entreprise d’accueil connue sous le nom de ITIPart. Puis, nous pr´senterons le cahier de
e
charges du projet ainsi que ses enjeux et ses avantages. Nous clˆturons ce chapitre par la
o
description de la m´thodologie adopt´e pour la r´alisation de l’ERP.
e e e
1.2 Pr´sentation d’organisme d’acceuil
e
ITIpart est une soci´t´ d’ing´nierie infor-
ee e
matique sp´cialis´e dans le d´veloppement et
e e e
la mise en place des solutions globales au-
tour des syst`mes d’information d’entreprise.
e
Elle est sp´cialis´e dans le d´veloppement et
e e e
la mise en place des solutions globales autour
des syst`mes d’information d’entreprise.
e
Tr`s orient´e vers ses Clients/Partenaires, ITIpart les place au coeur de sa strat´gie de
e e e
d´veloppement et leur propose de les accompagner dans leur challenges Business dans le cadre
e
d’une ´troite collaboration et d’une relation de partenariat autour de ses valeurs fondamentales :
e
Transparence, Engagement et Qualit´.
e
1.2.1 Web agency
ITIPart propose a ses clients de concevoir et r´aliser leurs site Internet professionnels, E-
` e
commerce, r´seau social r´pondant aux normes et standards du web et en parfaite ad´quation
e e e
avec les activit´s et les cibles du client.
e
1.2.2 Mobile agency
ITIPart propose a ses clients l’accompagnement dont ils ont besoin pour prendre en douceur le
`
virage de la mobilit´ et d’envisager ce changement important dans leurs syst`me d’information
e e
4
17. ´
CHAPITRE 1. PRESENTATION DU PROJET
de fa¸on beaucoup plus sereine. ITIPart d´veloppe des applications mobiles sous Android,
c e
IPhome, Blackberry, etc.
1.2.3 Nearshoring
Il se concr´tise par la mise en place de centres de services bas´s a Tunis int´grant des
e e ` e
comp´tences a la pointe des nouvelles technologies (JEE, .net. Web 2.0, etc) avec une int´gration
e ` e
sur mesure de l’environnement du client (plate-forme, s´curit´, PAQ, etc).
e e
1.2.4 Int´grateur Open Source
e
ItiPart met ` la disposition de ses clients ses experts afin de leur permettre de b´n´ficier
a e e
pleinement et toute s´curit´ de meilleures solutions de l’open source autour de la GED, CRM...
e e
1.3 Pr´sentation du projet
e
Nous envisageons dans ce qui suit la pr´sentation du projet du stage pour bien le comprendre
e
et d´limiter ce qui est demand´ pour passer a l’action et r´pondre aux sp´cifications d’une fa¸on
e e ` e e c
concise et efficace.
1.3.1 Description du projet
Ce projet s’intitule Conception de l’architecture et d´veloppement des modules
e
d’un ERP Universitaire. Les modules qui constituent ce travail sont pr´sent´s ci-dessous :
e e
-Module gestion de la biblioth`que.
e
-Module gestion des inscriptions et des formations.
-Module gestion des notes et des r´sultat.
e
-Module gestion des services administratifs et des r´clamations.
e
Ce travail rentre dans le cadre de mon projet de fin d’´tudes qui vient conclure notre formation
e
d’ing´nieur en g´nie logiciel ` Institut National des Sciences Appliqu´es et de Technologie
e e a e
(INSAT). Il s’int`gre dans le cadre des projets de d´veloppement d’ITIPart.
e e
5
18. ´
CHAPITRE 1. PRESENTATION DU PROJET
1.3.2 Cahier des charges
Il s’agit de r´aliser un ERP universitaire modulaire, cet ERP doit couvrir tous les services et
e
les d´partements de l’universit´. Les modules sont :
e e
- Gestion de la biblioth`que
e
L’adh´rent peut chercher en ligne les ouvrages disponibles par mots cl´s, auteur, titre, ann´e,
e e e
ou domaine. La consultation peut d´voiler la liste des ouvrages qui seront disponibles dans les
e
trois jours ouvrables suivants. L’adh´rent pourra alors demander la r´servation de l’ouvrage.
e e
Le responsable de la biblioth`que doit pouvoir g´rer la biblioth`que directement depuis le
e e e
syst`me. La gestion de la biblioth`que doit supporter :
e e
-Prˆts de livres, gestion des emprunteurs, livres ` rendre, livres rendus.
e a
-Nombre d’exemplaires en possession de chaque utilisateur.
-Historique des emprunts.
-Recherche multicrit`res et s´lective.
e e
-Saisie assist´e.
e
-Classement par genre.
Le syst`me doit informer les adh´rents de leurs d´passements du d´lai de retour de l’ouvrage,
e e e e
ainsi que les annulations des r´servations effectu´es dans le cas o` l’adh´rent n’empruntent pas
e e u e
l’ouvrage dans le d´lai.
e
-Module gestion des inscriptions et des formations
La gestion des inscriptions devra permettre l’inscription d’un nouveau membre sous r´serve
e
de validation par l’administrateur qui devra alors lui accorder le statut (Rˆles, Sites...) ad´quat.
o e
La gestion des formations doit comporter la gestion des cycles, fili`res, niveaux. La d´finition
e e
des modules et des mati`res doit ˆtre faite par le personnel administratif.
e e
Chaque enseignant peut d´finir les cours pour les mati`res qu’il enseigne, ces cours seront
e e
valid´s selon un WorkFlow.
e
6
19. ´
CHAPITRE 1. PRESENTATION DU PROJET
-Module gestion des notes et des r´sultats
e
Le responsable scolarit´ doit pouvoir importer directement depuis les donn´es saisies par
e e
l’enseignant dans le syst`me de notation utilis´ par l’Ecole. Ce module permettra d’acc´l´rer
e e ee
la saisie des notes et de r´duire les erreurs de saisie.
e
Le syst`me doit g´n´rer les relev´s de notes a partir de la base de donn´es, ces relev´s seront
e e e e ` e e
g´r´s dans un serveur de gestion des documents.
ee
-Module gestion des services administratifs et des r´clamations
e
Les membres de l’ERP peuvent passer des r´clamations, ils peuvent aussi joindre un docu-
e
ment avec la r´clamation.
e
Le responsable administratif doit pouvoir traiter les r´clamations pr´sent´es par l’enseignant
e e e
ou un administratif et lui r´pondre par le biais du mˆme syst`me . Une r´clamation est un
e e e e
e e `
message qui peut ˆtre garni par des documents attach´s. A son envoi elle rend l’´tat Non
e
trait´e.
e
Lorsque le responsable administratif re¸oit la r´clamation, il peut changer son ´tat en ac-
c e e
cus´ de r´ception, en cours, rejet´e, non soluble ou termin´e selon l’´tat d’avance-
e e e e e
ment du traitement de la r´clamation. L’´tat d’avancement reste accessible a l’initiateur de la
e e `
r´clamation.
e
1.3.3 Enjeux et avantages
Les enjeux de ce projet sont multiples, on peut citer :
-D´finir une plateforme d’´change entre corps enseignants, ´tudiants, administratifs et
e e e
industriels.
-Num´risation des documents de l’universit´ : G´rer, organiser et d´finir les droits d’acc`s
e e e e e
aux documents ´lectroniques (Document Management System).
e
-Faciliter la recherche de l’information : Ce service permet au public de chercher par un
ou plusieurs mots cl´. Lorsque ce module est utilis´ par un membre authentifi´, la recherche
e e e
doit se faire dans toutes les pages accessibles par ce membre.
7
20. ´
CHAPITRE 1. PRESENTATION DU PROJET
1.3.4 Objectif
L’objectif de ce projet est d’avoir une version bˆta qui couvre la majorit´ des fonctionnalit´s
e e e
d’un ERP universitaire. Nous devons avoir des modules coh´rents au niveau des fonctionnalit´s
e e
et une vision claire sur le r´sultat attendu.
e
1.4 M´thodologie adopt´e : 2TUP
e e
1.4.1 Pr´sentation de la m´thodologie 2TUP
e e
Nous avons opt´ pour le processus 2TUP pour des raisons multiples. D’une part, 2TUP donne
e
une grande importance a la technologie ce qui est important pour notre projet, d’autre part,
`
2TUP est un processus en Y qui contient une branche technique et autre fonctionnelle. Ces
deux branches peuvent ˆtre exploit´es en parall`le.
e e e
De ce fait, si la technologie ´volue lors de d´roulement du projet il y a apparence d’un besoin
e e
technique, la branche technique peut ˆtre trait´e puis r´int´gr´e dans le projet facilement. De
e e e e e
mˆme si une nouvelle fonctionnalit´ se pr´sente, seule la branche fonctionnelle va ˆtre trait´e
e e e e e
sans toucher ` l’autre branche.
a
Principe :
Ce processus commence par une ´tude pr´liminaire qui permet d’identifier les acteurs du
e e
syst`me a mettre en oeuvre qui est consid´r´ comme une boˆ noir tout en pr´sentant les
e ` ee ıte e
diff´rents messages entre les utilisateurs et ce syst`me et d’´laborer le cahier de charges. La
e e e
figure montre les diff´rentes ´tapes de processus 2TUP.
e e
8
21. ´
CHAPITRE 1. PRESENTATION DU PROJET
Figure 1.1 – Cycle du d´veloppement par la m´thodologie 2TUP.
e e
D’apr`s la figure, on remarque que 2TUP est compos´ essentiellement de trois ´tapes :
e e e
1/Une branche fonctionnelle (` gauche) :
a
Capture des besoins fonctionnels, qui produit les mod`les des besoins en se basant sur le
e
m´tier des utilisateurs. Cette ´tape ´limine le risque d’avoir un syst`me inadapt´ aux besoins
e e e e e
des utilisateurs.
L’analyse qui consiste a ´tudier les besoins fonctionnels de mani`re ` obtenir une id´e de
`e e a e
ce que va r´aliser le syst`me en terme m´tier.
e e e
2/Une branche technique (` droite) :
a
Capture des besoins techniques, cette ´tape permet de recenser les contraintes de choix de
e
dimensionnement et de conception du syst`me. Les outils s´lectionn´s ainsi que les contraintes
e e e
d’int´gration avec l’existant (pr´-requis d’architecture technique).
e e
9
22. ´
CHAPITRE 1. PRESENTATION DU PROJET
L’´tape conception g´n´rique d´finit ensuite les composants n´cessaires a la construction de
e e e e e `
l’architecture technique. Cette conception est compl`tement ind´pendante des aspects fonc-
e e
tionnels.
3/Une branche de r´alisation (au milieu) :
e
La conception pr´liminaire, c’est une ´tape un peu d´licate, car elle int`gre le mod`le
e e e e e
d’analyse fonctionnel dans l’architecture technique de mani`re a tracer la cartographie des
e `
composants du syst`me ` d´velopper.
e a e
La conception d´taill´e, qui permet d’´tudier comment r´aliser chaque composant.
e e e e
L’´tape de codage, qui est ensuite l’´tape de production de ces composants ainsi que les tests
e e
unitaires au fur et ` mesure sur chaque composant.
a
L’´tape de recette, qui consiste enfin a la validation des diff´rentes fonctionnalit´s du syst`me.
e ` e e e
Outil de mod´lisation
e
Nous avons choisi comme langage de mod´lisation UML reconnu comme ´tant le standard
e e
industriel par excellence de la mod´lisation objet. Cela est d’autant plus probant quand on
e
prend connaissance qu’UML unifie a la fois les notations et les concepts orient´s objets.
` e
1.4.2 Application du 2TUP dans notre projet
Dans notre projet, nous avons commenc´ par la d´finition des besoins fonctionnels, nous
e e
avons d´coup´ l’ERP en dix modules.
e e
Ce PFE comporte quatre modules avec la mise en place de l’environnement. Nous avons
pr´cis´ l’architecture op´rationnelle ainsi que les architectures fonctionnelles. Par la suite, nous
e e e
nous sommes focalis´s sur la conception de la base de donn´es de L’ERP. Puis, nous avons
e e
commenc´ le d´veloppement des modules, chacun a part. Enfin, nous avons r´serv´ quatre
e e ` e e
semaines pour la r´daction du rapport.
e
10
23. ´
CHAPITRE 1. PRESENTATION DU PROJET
Le figure ci-dessous pr´sente en d´tail le d´roulement du projet ` l’aide d’un diagramme de
e e e a
Gantt :
Figure 1.2 – Diagramme de Gantt
Ce stage a dur´ six mois, nous avons commenc´ le 2 Juillet 20012 et nous avons fini le 28
e e
d´cembre 2012. Nous avons commenc´ par une ´tude pour capturer les besoins fonctionnels et
e e e
non-fonctionnels et les besoins techniques, cette phase a dur´ un mois.
e
Pendant quatre mois, nous avons ´t´ initi´s aux technologies pour qui nous avons opt´ dans
ee e e
notre travail et nous avons con¸u et d´velopp´ notre ERP. Au dernier mois, nous avons r´dig´
c e e e e
le rapport.
1.5 Conclusion
Dans ce chapitre, nous avons pr´sent´ l’entreprise d’accueil ITIPart ainsi que le travail
e e
´labor´, nous avons exprim´ le cahier de charge et les avantages de l’ERP dans l’universit´.
e e e e
Enfin, nous avons pr´sent´ la m´thodologie adopt´e. Dans le chapitre suivant, nous allons
e e e e
sp´cifier nos besoins en d´tail.
e e
11
24. CHAPITRE 2
´
ANALYSE ET SPECIFICATION DES BESOINS
12
25. ´
CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS
2.1 Introduction
Dans ce chapitre, nous pr´sentons les diff´rentes ´tapes suivies pour r´aliser l’analyse et
e e e e
sp´cification des besoins en se r´f´rant au processus unifi´ 2TUP. Nous commen¸ons par l’i-
e ee e c
dentification des acteurs principaux. Puis, nous allons analyser les besoins fonctionnels pour
chaque module et les besoins non-fonctionnels de la solution.
2.2 Les acteurs du syst`me
e
Dans notre projet, nous pouvons avoir plusieurs acteurs, nous allons nous int´resser unique-
e
ment aux acteurs principaux :
2.2.1 Administrateur
Cet acteur poss`de tous les droits d’acc`s qui lui permettent d’administrer le syst`me. Ses
e e e
fonctions principales sont la gestion des acc`s, la gestion des droits des utilisateurs du syst`me
e e
et la mise a jour du contenu des portlets du portail si n´cessaire.
` e
2.2.2 ´
Etudiant
Chaque ´tudiant aura un espace priv´ et un espace public, dans lequel il pourra consulter
e e
les informations et les services autoris´s par l’administrateur (notes, emploi du temps, Bib-
e
lioth`que...). Il pourra utiliser l’espace collaboratif de l’ERP tel que les blogs, les forums, les
e
wikis...
2.2.3 Enseignant
L’enseignant pourra g´rer son espace dans le portail en diffusant des messages et des annonces
e
pour ses ´tudiants. Il aura ´galement b´n´fici´ des services sp´cifiques comme les services de la
e e e e e e
biblioth`que, le passage d’une r´clamation, la saisie des notes en ligne...
e e
13
26. ´
CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS
2.2.4 Personnel administratif
Ce sont les responsables de la gestion et de l’´mission des documents administratifs inh´rents
e e
aux besoins des ´tudiants (certificats de r´ussite, de pr´sence, etc...), la gestion des ouvrages,
e e e
des emprunts, gestion des inscriptions, formations....
2.2.5 Public (visiteur)
L’utilisateur guest pourra consulter les pages publics du portail, qui contiennent des infor-
mations g´n´rales concernant l’universit´.
e e e
2.3 Sp´cifications fonctionnelles d´taill´es
e e e
La capture des besoins fonctionnels est la premi`re ´tape de la branche gauche du cycle en
e e
Y. Elle formalise et d´taille les cas d’utilisation et les associe aux acteurs appropri´s.
e e
2.3.1 Module gestion de la biblioth`que
e
Identification de la liste des cas d’utilisation
Dans la table ci-dessous, nous allons pr´senter les diff´rents cas d’utilisation du Module
e e
gestion de la biblioth`que avec les messages re¸us et ´mis :
e c e
14
27. ´
CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS
Cas d’utilisation Sous cas d’utilisation Acteurs Messages re¸us/´mis
c e
D´finition des rˆles
e o
Module Gestion G´r´e par le panneau
ee
et des permissions Administrateur
biblioth`que
e de configuration du Liferay
pour chaque utilisateur
Re¸us : Liste des
c
Traiter les demandes Personnel demandes d’inscription
d’inscription administratif Emis : Accepter ou refuser
les demandes
Re¸us : Liste des adh´rents
c e
Gestion des Personnel
Emis : Bloquer ou
adh´rents
e administratif
b´bloquer adh´rent
e e
Re¸us : Liste des ouvrages
c
Gestion des Personnel ´
Emis : Ajouter, supprimer
ouvrages administratif
ou modifier ouvrage
Re¸us : Liste des adh´rents et
c e
Gestion des Personnel liste des ouvrages
emprunts administratif ´
Emis : Acquisition ou retour
d’un ouvrage
Re¸us : Liste des ouvrages
c
R´server un ouvrage
e Adh´rent
e ´
Emis : R´server
e
un ouvrage
Re¸us : Liste des
c
adh´rents et liste
e
Annuler une
Adfh´rent
e des ouvrages
r´servation
e ´
Emis : Annuler une
r´servation.
e
Re¸us : Formulaire a
c `
remplir
Demander d’inscription Adfh´rent
e ´
Emis : Demande
d’inscription
Re¸us : Liste des favoris
c
Gestion des favoris Adfh´rent
e ´
Emis : Ajouter, supprimer
les favoris
Re¸us : Liste des
c
r´servations qui
e
Annuler les r´servations
e
Syst`me
e d´ppassent le d´lai.
e e
et informer les adh´rents
e ´
Emis : Des emails pour
informer les adh´rents
e
Re¸us : Liste des
c
emprunts qui
Notifier les adh´rents
e
Syst`me
e d´ppassent le d´lai.
e e
de leurs d´passements
e ´
Emis : Des emails pour
informer les adh´rents
e
Table 2.1 – Module gestion biblioth`que : messages ´mis et re¸us
e e c
15
28. ´
CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS
Description du cas d’utilisation
Nous pr´sentons dans la figure 2.1 le cas d’utilisation du module gestion biblioth`que :
e e
Figure 2.1 – Module Gestion biblioth`que : Diagramme de cas d’utilisation
e
2.3.2 Module gestion des inscriptions et des formations
Identification de la liste des cas d’utilisation
Dans la table ci-dessous, nous allons pr´senter les diff´rents cas d’utilisation du Module
e e
gestion des inscriptions et des formations avec les messages re¸us et ´mis :
c e
16
29. ´
CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS
Cas d’utilisation Sous cas d’utilisation Acteurs Messages re¸us/´mis
c e
Re¸us : Liste des cycles,
c
Module Gestion
Personnel formulaire
des inscriptions Gestion des cycles ´
administratif Emis : Ajouter, supprimer
et des formations
ou modifier cycle
Re¸us : Liste des fili`res,
c e
Personnel formulaire
Gestion des Fili`res
e ´
administratif Emis : Ajouter, supprimer
ou modifier fili`re
e
Re¸us : Liste des niveaux,
c
Personnel formulaire
Gestion des niveaux ´
administratif Emis : Ajouter, supprimer
ou modifier niveau
Re¸us : Liste des modules,
c
Personnel formulaire
Gestion des modules ´
administratif Emis : Ajouter, supprimer
ou modifier module
Re¸us : Liste des mati`res,
c e
Personnel formulaire
Gestion des mati`res
e ´
administratif Emis : Ajouter, supprimer
ou modifier mati`re
e
Re¸us : Liste des groupes,
c
Personnel formulaire
Gestion des groupes ´
administratif Emis : Ajouter, supprimer
ou modifier groupe
Re¸us : Liste des demandes
c
Traiter les demandes Personnel d’inscription
d’inscriptions administratif ´
Emis : Accepter ou refuser
une demande d’inscription
Re¸us : Formulaire
c
Demande d’inscription ´tudiant
e ´
Emis : Demande d’inscription
Table 2.2 – Module gestion des inscriptions et des formations : messages ´mis et re¸us
e c
Description du cas d’utilisation
Nous pr´sentons dans la figure 2.2 le cas d’utilisation du module gestion des inscriptions et des
e
formations :
17
30. ´
CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS
Figure 2.2 – Module Gestion des inscriptions et des formations : Diagramme de cas d’utilisa-
tion
2.3.3 Module gestion des notes et des r´sultats
e
Identification de la liste des cas d’utilisation
Dans la table ci-dessous, nous allons pr´senter les diff´rents cas d’utilisation du Module
e e
gestion des notes et des r´sultats avec les messages re¸us et ´mis :
e c e
18
31. ´
CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS
Cas d’utilisation Sous cas d’utilisation Acteurs Messages re¸us/´mis
c e
Module Gestion
Visualiser les notes
des notes et ´tudiant
e Re¸us : Liste des notes
c
et les r´sultats
e
des r´sultats
e
Re¸us : Liste des ´tudiants
c e
Personnel
Saisie des notes et des mati`res
e
administratif ´
Emis : Les notes saisies
Re¸us : Liste des ´tudiants
c e
Calculer les Personnel et des mati`res
e
moyennes par mati`re
e ´
administratif Emis : Lancement du calcul
des moyennes par mati`ree
Re¸us : Liste des ´tudiants
c e
Calculer les Personnel et des modules
moyennes par module ´
administratif Emis : Lancement du calcul
des moyennes par module
Re¸us : Liste des ´tudiants
c e
Calculer les Personnel ´
Emis : Lancement du calcul
moyennes g´n´rals
e e administratif
des moyennes g´n´rales.
e e
Re¸us : Liste des ´tudiants
c e
Personnel ´
D´terminer les r´sultats
e e Emis : D´terminer les
e
administratif
r´sultats et les mentions
e
Re¸us : Liste des ´tudiants
c e
G´n´rer les relev´s
e e e Personnel ´
Emis : G´n´rer les
e e
de notes administratif
relev´s de notes des ´tudiants
e e
Table 2.3 – Module gestion des notes et des r´sultats : messages ´mis et re¸us
e e c
Description du cas d’utilisation
Nous pr´sentons dans la figure 2.3 le cas d’utilisation du module gestion des notes et des
e
r´sultats :
e
19
32. ´
CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS
Figure 2.3 – Module Gestion des notes et des r´sultats : Diagramme de cas d’utilisation
e
2.3.4 Module gestion des services administratifs et des r´clamations
e
Identification de la liste des cas d’utilisation
Dans la table ci-dessous, nous allons pr´senter les diff´rents cas d’utilisation du module
e e
services administratifs et r´clamations avec les massages re¸us et ´mis :
e c e
20
33. ´
CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS
Cas d’utilisation Sous cas d’utilisation Acteurs Messages re¸us/´mis
c e
Module Gestion Re¸us : Liste des
c
Suivre l’´tat d’une
e
des services Membre r´clamations avec
e
r´clamation
e
et r´clamations
e leurs d´tails
e
Re¸us : Formulaire
c
Passer une r´clamation
e Membre ´mis : Passer une
e
r´clamation
e
Re¸us : Formulaire
c
Damander un service Membre ´
Emis : demander
service
Re¸us : Liste des
c
Suivre l’´tat d’un service
e Membre demandes de services
avec leurs d´tails
e
Re¸us : Liste des demandes
c
Personnel de services
Traiter les services ´
administratif Emis : Traiter une
demande de service
Re¸us : Liste des
c
Personnel r´clamations
e
Traiter les r´clamations
e ´
administratif Emis : Traiter une
r´clamation
e
Re¸us : Formulaire
c
D´finir les types
e Personnel ´
Emis : Ajouter un
de services administratif
nouveau type de service
Re¸us : Formulaire
c
D´finir les types de
e Personnel ´
Emis : Ajouter un
r´clamations
e administratif nouveau type de
r´clamation
e
Table 2.4 – Module services administratifs et r´clamations : messages ´mis et re¸us
e e c
Description du cas d’utilisation
Nous pr´sentons dans la figure 2.4 le cas d’utilisation du module services administratifs et
e
r´clamations :
e
21
34. ´
CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS
Figure 2.4 – Module Gestion des services et r´clamations : Diagramme de cas d’utilisation
e
2.4 Sp´cifications non-fonctionnelles
e
2.4.1 Extensibilit´
e
L’extensibilit´ l’une des sp´cifications important d’un ERP. Notre architecture doit supporter
e e
les extensions de nouvelles fonctionnalit´s sans pour autant la modifier ´norm´ment. Notre code
e e e
devra ˆtre ferm´ a la modification et ouvert a l’extension.
e e` `
22
35. ´
CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS
2.4.2 S´curit´
e e
L’ERP doit respecter certaines r`gles relatives a la s´curit´ des syst`mes informatiques, nous
e ` e e e
devons avoir un syst`me d’acc`s s´curis´ bas´ sur l’authentification et la gestion des autorisa-
e e e e e
tions :
Authentification
Mise en place d’un serveur d’authentification qui assure l’authentification unique, l’authen-
tification doit se faire ` travers un certificat SSL.
a
Autorisation
Chaque utilisateur aura un rˆle, la d´finition des permissions pour chaque rˆle doit ˆtre
o e o e
dynamique : on aura la possibilit´ de cr´er ou de modifier les rˆles en associant la combinaison
e e o
de permission ad´quate.
e
2.4.3 Performances
La performance des services offerts est critique, notamment pour l’importance du facteur
temps dans l’ERP qui vise un grand nombre d’utilisateurs.
2.5 Conclusion
`
A travers ce chapitre, nous avons d´taill´ nos acteurs. Nous avons d´taill´ les besoins fonction-
e e e e
nels en pr´sentant un diagramme de cas d’utilisation pour chaque module avec la sp´cification
e e
des besoins non-fonctionnels de la solution. Dans le prochain chapitre nous entamons la mise
en place de l’environnement op’erationnel.
23
36. CHAPITRE 3
´
PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE
24
37. ´
CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE
3.1 Introduction
Dans ce chapitre nous exposons nos besoins techniques en d´tail. Nous pr´senterons les
e e
diff´rentes technologies utilis´es pour construire notre architecture op´rationnelle. Nous ex-
e e e
pliquons l’int´rˆt de chaque choix effectu´.
ee e
3.2 Sp´cification des besoins techniques
e
Notre solution se compose de deux aspects fonctionnels principaux :
Un portail (Liferay) qui satisfait les besoins suivants :
– Un espace collaboratif complet, incluant des forums, des blogs personnels, des wikis...
– Un syst`me de gestion d’autorisation avec des espaces publics et des espaces priv´s
e e
– Gestion de profiling (acc`s personnalis´ selon les utilisateurs).
e e
– Syst`me de workFlow pour la gestion des requˆtes complexes.
e e
– Un r´seau social interne.
e
Un ECM (Alfresco) pour r´aliser la gestion ´lectronique des documents :
e e
– Stockage et archivage des documents.
– Impel´mtation des workFlows personnalis´s pour les documents.
e e
– Gestion des droits d’acc`s pour chaque document.
e
Pour pouvoir int´grer convenablement les deux parties de l’ERP cit´s ci-dessus (portail et
e e
ECM), nous utiliserons une solution Single Sign One (SSO), la solution adopt´e pour serveur
e
d’authentification est le serveur CAS.
Dans notre cas, la centralisation des utilisateurs est indispensable pour la coh´rence de traite-
e
ment de l’ERP. Les groupes d’utilisateurs devrons ˆtre les mˆmes dans le portail et l’ECM. En
e e
cons´quence, on utilisera un annuaire Lightweight Directory Access Protocol (LDAP). OpenL-
e
dap est la solution choisie pour notre projet.
25
38. ´
CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE
3.3 Liferay
Liferay Portal est le leader mondial des solutions open source de portail d’entreprise, utilisant
les derni`res technologies Java et Web 2.0.
e
Dans notre projet, Liferay offre un espace
collaboratif : un ensemble des composants
r´utilisables et configurables tel que Forums,
e
Blogs, Wikis, composants de sondages, com-
posants pour g´rer les ´v´nements[1]...
e e e
Il offre un panneau d’administration com-
plet, ce panneau nous permet de g´rer les utilisateurs, les workflows, les rˆles, les sites...
e o
Toute les publications (article, commentaire, contenu...) dans Liferay peut suivre un workflow
de validation personnalis´. Liferay supporte le moteur du workflow Kaleo.
e
Liferay est con¸u pour d´ployer des portlets qui font partie de Application Programming
c e
Interface (API) Portlet (JSR-168). Liferay est ´galement compatible avec la seconde impl´mentation
e e
de l’API Portlet JSR-286 qui est disponible depuis la version 5 de Liferay.[3]
Le d´veloppement sp´cifique des modules dans notre solution, sera sous forme de portlets,
e e
chaque module est un projet a part. Nous devons respecter la sp´cification dans notre d´veloppement
` e e
pour que l’int´gration soit possible.
e
Liferay impl´mente un moteur de recherche interne puissant, ce moteur indexe les donn´es
e e
utilis´es par les portlets natifs avec la prise en compte des droits d’acc`s.
e e
26
39. ´
CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE
Figure 3.1 – Architecture de Liferay
Liferay nous fournit un autre type de projet qui s’appelle HOOK. Il est apparu dans la
version 6 de Liferay. Ce projet nous permet de personnaliser le noyau du Liferay selon notre
m´tier. Nous avons besoin de personnaliser des interfaces natives de Liferay avec la modification
e
de quelques controleurs et quelques services.
Liferay fournit un g´n´rateur de code service builder : Il permet a partir d’un fichier XML de
e e `
g´n´rer les entit´s de stockage ainsi que les services d’acc`s (CRUD) et configure l’indexation
e e e e
pour les rendre accessibles par le moteur de recherche. L’ensemble est int´gr´ comme une
e e
ressource dans la pile de gestion des droits classiques de Liferay.[4]
27
40. ´
CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE
La couche pr´sentation de Liferay utilise le moteur de templating Velocity. Avec Velocity,
e
la couche pr´sentation sera faiblement coupl´e avec les couches inf´rieures.
e e e
Ce concept facilite ´norm´ment la personnalisation des interfaces de Liferay.
e e
`
Liferay propose un nouveau type de projet qui s’intitule Theme. A l’aide de ce type de
projet, nous pouvons d´velopper un th`me en utilisant des fichiers VM (extension des fichiers
e e
reconnus par Velocity), des feuilles de styles (CSS), des images...
Ce projet sera d´ploy´ sur le serveur Liferay qui va ˆtre par la suite visible dans le panneau
e e e
d’administration de Liferay.
Pour pouvoir personnaliser les layouts des pages, Liferay fournit un projet qui s’appelle
Layout. Dans ce projet on peut d´couper nos pages selon notre besoin. Ce Layout peut ˆtre
e e
utilis´ plusieurs fois et dans plusieurs projets.
e
3.4 Alfresco
Alfresco est un syst`me de gestion de contenu (en anglais ECM pour Enterprise Content Man-
e
agement) cr´´ par Alfresco Software en 2005 et distribu´ sous licence libre.[2]
ee e
Dans notre projet, Alfresco nous fournit un
GED tr`s puissant. Il offre des workflows stan-
e
dards pour la gestion des documents.
Avec Activiti, nous pouvons d´velopper des
e
workflows personnalis´s, par exemple : un
e
workflow pour g´rer le cycle de vie d’un dossier d’inscription, un workflow pour la validation
e
des cours...
L’une des fonctionnalit´s d’Alfresco, est la gestion des r`gles de contenu (content rules).
e e
Les r`gles de contenu permettent d’ajouter de l’intelligence a vos r´pertoires, dossiers, espaces,
e ` e
d’une mani`re comparable aux filtres que vous pouvez d´finir pour votre messagerie email.
e e
28
41. ´
CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE
Nous avons besoin de ces r`gles pour bien organiser nos documents (Administratif, dossiers
e
d’inscription...).
Alfresco int`gre son propre moteur de recherche, il utilise Apache Lucene pour indexer les
e
documents. Ce moteur est tr`s param`trable, nous pouvons filtrer les recherches par date,
e e
dossier, espaces...
Figure 3.2 – Architecture d’Alfresco
Alfresco supporte plusieurs extensions, il a la possibilit´ de faire la convertion des documents.
e
Pour les documents bureautiques (PDF, DOC, Excel..), la conversion se fait avec Open Office.
Pour les fichiers medias, Alfresco utilise OpenGraph pour assurer la conversion d’un format a
`
un autre.
Alfresco impl´mente le protocole CIFS (Common Internet File System), ce protocole favorise
e
la collaboration sur internet. Dans notre projet, ce protocole nous offre la possibilit´ de travailler
e
29
42. ´
CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE
sur des r´pertoires virtuels sur le disque local, il facilite la manipulation des fichiers.
e
3.5 Partenariat entre Alfresco et Liferay
Liferay et Alfresco ont fait un partenariat afin d’offrir un portail entreprise et un ECM avec
une int´gration compl`te.
e e
Alfresco impl´mente le protocole Content Management Interoperability Services (CMIS), le
e
but de ce protocole est d’augmenter l’interop´rabilit´ entre les ECM et les applications externes.
e e
`
Il s’agit un ensemble des services webs REST. A travers ce protocole, nous pouvons effectuer
les mˆme op´rations possible par les interfaces webs d’Alfresco.
e e
Pour les clients JAVA, Alfresco fournit une API java, cet API facilite ´norm´ment le d´veloppement,
e e e
elle est bˆtie sur le protocole CMIS.
a
Liferay a int´gr´ les librairies clients pour pouvoir consommer ces services expos´s par Alfresco.
e e e
Pour voir les d´tails sur le partenariat voici un lien qui comporte une description claire sur
e
le fonctionnement et l’int´gration de Liferay et Alfresco :
e
http ://www.alfresco.com/products/integrations/liferay
3.6 Central authentification service (CAS)
CAS est un syst`me d’authentification unique : on s’authentifie sur un site Web, et on est alors
e
authentifi´ sur tous les sites Web qui utilisent le mˆme serveur CAS. Il ´vite de s’authentifier
e e e
a chaque fois qu’on acc`de a une application en mettant en place un syst`me de tickets.
` e ` e
L’int´gration du serveur CAS nous permet d’avoir un SSO entre Liferay et Alfresco, ce serveur
e
permet de naviguer en toute transparence entre les deux solutions.
L’authentification doit ˆtre s´curis´e par un certificat SSL pour que l’authentification soit
e e e
forte. Nous devons configurer Tomcat avec un certificat ´lectronique.
e
30
43. ´
CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE
CAS fournit des librairies clients afin de faciliter cette int´gration avec Liferay et Alfresco.
e
CAS fonctionne sous n’importe quel serveur d’application (Tomcat, JBOSS...). Il est d´velopp´
e e
avec des servlets et des pages JSP, nous pouvons modifier le th`me du CAS en modifiant
e
directement les pages JSP.
Figure 3.3 – Architecture de CAS
Dans son mode de fonctionnement, CAS utilise un m´canisme d’´change de tickets. Ces
e e
tickets sont enregistr´s dans les cookies, pour cela, le navigateur web doit accepter les cookies
e
si non, l’utilisateur devra se r´-authentifier a chaque appel au serveur CAS.
e `
31
44. ´
CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE
3.7 OpenLDAP
OpenLdap est un annuaire ´lectronique, il s’agit d’une base de donn´es sp´cialis´e qui permet
e e e e
de partager des bases d’informations sur un r´seau. Ces bases peuvent contenir toute sorte
e
d’informations, comme des logins, des mots de passe, des adresses mails...
OpenLdap est une solution open source et gratuite.
Dans notre projet, OpenLdap m´morise les
e
cordonn´es des membres de Liferay et Al-
e
fresco, les utilisateurs seront regroup´s selon
e
leurs statuts (´tudiant, enseignant, personnel
e
administratif, administrateur).
Nous pouvons cr´er un arbre DIT pour
e
bien organiser les utilisateurs (´tudiant, en-
e
seignant, personnel administratif, administrateur).
Liferay importe les utilisateurs lors de son d´marrage. Dans la phase de configuration, nous
e
devons pr´ciser le mapping entre les attributs de l’annuaire LDAP et les attributs de Liferay.
e
Liferay nous offre une interface de configuration avec l’annuaire LDAP.
Les utilisateurs d’Alfresco sont import´s et enregistr´s dans la base de donn´es d’Alfresco.
e e e
La configuration et le mapping de l’annuaire se fait en modifiant les fichiers .properties.
Le serveur CAS utilise l’annuaire pour v´rifier et valider les cordonn´es des utilisateurs lors
e e
de l’authentification.
3.8 Conclusion
`
A travers ce chapitre, nous avons pr´sent´ notre besoin technique ainsi que les diff´rents
e e e
composants utilis´s. Nous avons pr´sent´ Liferay, Alfresco, OpenLdap et le serveur CAS. Nous
e e e
avons ´tudi´ la possibilit´ de l’int´gration entre eux. Dans le quatri`me chapitre, nous d´taillons
e e e e e e
nos architectures avec une conception de notre solution.
32
45. CHAPITRE 4
ARCHITECTURE ET CONCEPTION DE LA SOLUTION
33
46. CHAPITRE 4. ARCHITECTURE ET CONCEPTION DE LA SOLUTION
4.1 Introduction
Dans ce chapitre, nous exposons d’abord l’architecture op´rationnelle de la solution ainsi que
e
les architectures applicatives, avant d’entamer ensuite la phase de conception, nous pr´senterons
e
la conception de l’arbre DIT de l’annuaire LDAP, le mod`le d’acc`s aux donn´es, le pattern
e e e
IoC (Inversion Of Control) et les mod`les des donn´es.
e e
4.2 Architectures de la solution
Nous exposons d’abord l’architecture op´rationnelle cible de la solution ainsi que les archi-
e
tectures applicatives.
4.2.1 Architecture op´rationnelle
e
Au vu des sp´cifications fonctionnelles et des exigences techniques, nous proposons l’archi-
e
tecture cible suivante :
Architecture g´n´ral de l’ERP
e e
Nous allons pr´senter l’architecture op´rationnelle de notre ERP, notre architecture est
e e
r´partie en plusieurs serveurs. La figure 4.1 pr´sente l’architecture op´rationnelle.
e e e
Pour assurer le SSO, nous avons choisi la solution CAS (Central authentification Service),
CAS g`re les sessions de Liferay ainsi que pour Alfresco.
e
Tous les utilisateurs sont centralis´s dans un annuaire LDAP, ces utilisateurs sont import´s
e e
dans Lifaray et Alfresco, et le serveur CAS v´rifi´ les param`tres d’authentification.
e e e
La fonctionnalit´ de gestion des documents est d´l´gu´e au serveur Alfresco.
e ee e
34
47. CHAPITRE 4. ARCHITECTURE ET CONCEPTION DE LA SOLUTION
Figure 4.1 – Architecture g´n´ral de l’ERP
e e
La communication entre Liferay et Alfresco se fait a travers le protocole CMIS. Alfresco
`
impl´mente ce protocole et fournit une API qui est bˆtie sur CMIS pour mieux faciliter l’in-
e a
terop´rabilit´ d’Alfresco.
e e
Architecture d´taill´e de l’ERP
e e
Dans cette partie, nous d´taillons l’architecture op´rationnelle de l’ERP, nous expliquons les
e e
diff´rents composants de Liferay ainsi que ceux d’Alfresco.
e
35
48. CHAPITRE 4. ARCHITECTURE ET CONCEPTION DE LA SOLUTION
Figure 4.2 – Architecture d´taill´e de l’ERP
e e
Liferay impl´mente la sp´cification du Portlet (JSR-286). Liferay comporte nos modules qui
e e
sont d´velopp´s sous forme de Portlets et les Portlets natifs de Liferay (Forum, Wiki, Blog...).
e e
Alfresco prend en charge la gestion des documents (Stockage, ajout, suppression...), cycle
de vie des documents (Dossiers d’inscription, les r´clamations...), les workflows (les cours, les
e
demandes de services...) et la s´curit´ (gestion des droits d’acc`s pour les documents...).
e e e
On dispose de trois bases de donn´es MySql, une pour les donn´es de Liferay, la deuxi`me
e e e
pour Alfresco et la derni`re r´serv´e pour l’ERP.
e e e
36
49. CHAPITRE 4. ARCHITECTURE ET CONCEPTION DE LA SOLUTION
4.2.2 Architectures applicatives
Nous allons pr´senter les architectures applicatives de chaque module d´velopp´ ceci comporte
e e e
la sp´cification des rameworks utilis´s et leur diff´rentes interactions.
e e e
Module gestion de la biblioth`que
e
Dans l’architecture du module gestion de la biblioth`que, nous avons utilis´ plusieurs Frame-
e e
works, la figure ci-dessous montre l’int´gration de ces Frameworks.
e
Figure 4.3 – Architecture du module gestion de la biblioth`que
e
Dans le Portlet Gestion biblioth`que, nous avons organis´ les Frameworks comme suivant :
e e
-Pour impl´menter le pattern MVC (Mod`le, vue, Contrˆle), nous avons utilis´ JSF.
e e o e
-Primefaces s’occupe de la couche pr´sentation.
e
-Nous avons utilis´ Spring comme un Framework d’int´gration, Spring impl´mente le pattern
e e e
IoC (Inversion de contrˆle).[5]
o
37
