1. Recherche ScientiďŹque 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 ScientiďŹque 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 aďŹection
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 eďŹet 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 aďŹn de pouvoir recenser les
e e
donn´es et les placer sur un tableau de bord ´lectronique. Ceci oďŹre 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 proďŹter 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 ďŹn dâ´tude, pour pouvoir mettre en oeuvre toutes les possibilit´s oďŹertes par les
e e
ERP dâentreprise et ´voluer du simple site web vers un ERP oďŹrant 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 diďŹÂ´rents choix ´labor´s.
e e e e
La sp´ciďŹcation et lâanalyse des besoins seront pr´sent´es dans le troisi`me chapitre intitul´
e e e e e
Analyse et sp´ciďŹcation 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 oďŹrira un
e e
aper¸u des patrons de conception utilis´s. Cet aper¸u m`nera a la conception des diďŹÂ´rentes
c e c e ` e
fonctionnalit´s oďŹertes.
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 aďŹn de leur permettre de b´n´ďŹcier
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´ciďŹcations dâune fa¸on
e e ` e e c
concise et eďŹcace.
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 ďŹn 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 eďŹectu´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, ďŹli`res, niveaux. La d´ďŹnition
e e
des modules et des mati`res doit Ëtre faite par le personnel administratif.
e e
Chaque enseignant peut d´ďŹnir 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´ďŹnir 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´ďŹnir 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 authentiďŹÂ´, 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âidentiďŹer 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
diďŹÂ´rents messages entre les utilisateurs et ce syst`me et dâ´laborer le cahier de charges. La
e e e
ďŹgure montre les diďŹÂ´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 ďŹgure, 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´ďŹnit 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 enďŹn a la validation des diďŹÂ´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 uniďŹe 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´ďŹnition 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. EnďŹn, 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 ďŹgure 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 ďŹni 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
EnďŹn, nous avons pr´sent´ la m´thodologie adopt´e. Dans le chapitre suivant, nous allons
e e e e
sp´ciďŹer 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 diďŹÂ´rentes ´tapes suivies pour r´aliser lâanalyse et
e e e e
sp´ciďŹcation des besoins en se r´f´rant au processus uniďŹÂ´ 2TUP. Nous commen¸ons par lâi-
e ee e c
dentiďŹcation 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 diďŹusant des messages et des annonces
e
pour ses ´tudiants. Il aura ´galement b´n´ďŹci´ des services sp´ciďŹques 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 (certiďŹcats 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´ciďŹcations 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
IdentiďŹcation de la liste des cas dâutilisation
Dans la table ci-dessous, nous allons pr´senter les diďŹÂ´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´ďŹnition des rËles
e o
Module Gestion G´r´e par le panneau
ee
et des permissions Administrateur
biblioth`que
e de conďŹguration 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 modiďŹer 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
NotiďŹer 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 ďŹgure 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
IdentiďŹcation de la liste des cas dâutilisation
Dans la table ci-dessous, nous allons pr´senter les diďŹÂ´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 modiďŹer cycle
Re¸us : Liste des ďŹli`res,
c e
Personnel formulaire
Gestion des Fili`res
e ´
administratif Emis : Ajouter, supprimer
ou modiďŹer ďŹli`re
e
Re¸us : Liste des niveaux,
c
Personnel formulaire
Gestion des niveaux ´
administratif Emis : Ajouter, supprimer
ou modiďŹer niveau
Re¸us : Liste des modules,
c
Personnel formulaire
Gestion des modules ´
administratif Emis : Ajouter, supprimer
ou modiďŹer module
Re¸us : Liste des mati`res,
c e
Personnel formulaire
Gestion des mati`res
e ´
administratif Emis : Ajouter, supprimer
ou modiďŹer mati`re
e
Re¸us : Liste des groupes,
c
Personnel formulaire
Gestion des groupes ´
administratif Emis : Ajouter, supprimer
ou modiďŹer 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 ďŹgure 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
IdentiďŹcation de la liste des cas dâutilisation
Dans la table ci-dessous, nous allons pr´senter les diďŹÂ´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 ďŹgure 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
IdentiďŹcation de la liste des cas dâutilisation
Dans la table ci-dessous, nous allons pr´senter les diďŹÂ´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´ďŹnir les types
e Personnel ´
Emis : Ajouter un
de services administratif
nouveau type de service
Re¸us : Formulaire
c
D´ďŹnir 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 ďŹgure 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´ciďŹcations non-fonctionnelles
e
2.4.1 Extensibilit´
e
Lâextensibilit´ lâune des sp´ciďŹcations important dâun ERP. Notre architecture doit supporter
e e
les extensions de nouvelles fonctionnalit´s sans pour autant la modiďŹer ´norm´ment. Notre code
e e e
devra Ëtre ferm´ a la modiďŹcation 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âauthentiďŹcation et la gestion des autorisa-
e e e e e
tions :
AuthentiďŹcation
Mise en place dâun serveur dâauthentiďŹcation qui assure lâauthentiďŹcation unique, lâauthen-
tiďŹcation doit se faire ` travers un certiďŹcat SSL.
a
Autorisation
Chaque utilisateur aura un rËle, la d´ďŹnition des permissions pour chaque rËle doit Ëtre
o e o e
dynamique : on aura la possibilit´ de cr´er ou de modiďŹer les rËles en associant la combinaison
e e o
de permission ad´quate.
e
2.4.3 Performances
La performance des services oďŹerts 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´ciďŹcation
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
diďŹÂ´rentes technologies utilis´es pour construire notre architecture op´rationnelle. Nous ex-
e e e
pliquons lâint´rËt de chaque choix eďŹectu´.
ee e
3.2 Sp´ciďŹcation 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 proďŹling (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âauthentiďŹcation 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 oďŹre un espace
collaboratif : un ensemble des composants
r´utilisables et conďŹgurables tel que Forums,
e
Blogs, Wikis, composants de sondages, com-
posants pour g´rer les ´v´nements[1]...
e e e
Il oďŹre un panneau dâadministration com-
plet, ce panneau nous permet de g´rer les utilisateurs, les workďŹows, les rËles, les sites...
e o
Toute les publications (article, commentaire, contenu...) dans Liferay peut suivre un workďŹow
de validation personnalis´. Liferay supporte le moteur du workďŹow 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´ciďŹque des modules dans notre solution, sera sous forme de portlets,
e e
chaque module est un projet a part. Nous devons respecter la sp´ciďŹcation 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 modiďŹcation
e
de quelques controleurs et quelques services.
Liferay fournit un g´n´rateur de code service builder : Il permet a partir dâun ďŹchier XML de
e e `
g´n´rer les entit´s de stockage ainsi que les services dâacc`s (CRUD) et conďŹgure 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 ďŹchiers VM (extension des ďŹchiers
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 oďŹre des workďŹows stan-
e
dards pour la gestion des documents.
Avec Activiti, nous pouvons d´velopper des
e
workďŹows personnalis´s, par exemple : un
e
workďŹow pour g´rer le cycle de vie dâun dossier dâinscription, un workďŹow 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 ďŹltres que vous pouvez d´ďŹnir 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 ďŹltrer 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 OďŹce.
Pour les ďŹchiers 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 oďŹre 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 ďŹchiers.
e
3.5 Partenariat entre Alfresco et Liferay
Liferay et Alfresco ont fait un partenariat aďŹn dâoďŹrir 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 eďŹectuer
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 authentiďŹcation service (CAS)
CAS est un syst`me dâauthentiďŹcation unique : on sâauthentiďŹe sur un site Web, et on est alors
e
authentiďŹÂ´ sur tous les sites Web qui utilisent le mËme serveur CAS. Il ´vite de sâauthentiďŹer
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âauthentiďŹcation doit Ëtre s´curis´e par un certiďŹcat SSL pour que lâauthentiďŹcation soit
e e e
forte. Nous devons conďŹgurer Tomcat avec un certiďŹcat ´lectronique.
e
30
43. ´
CHAPITRE 3. PRESENTATION DE LâENVIRONNEMENT TECHNOLOGIQUE
CAS fournit des librairies clients aďŹn 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 modiďŹer le th`me du CAS en modiďŹant
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´-authentiďŹer 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 conďŹguration, nous
e
devons pr´ciser le mapping entre les attributs de lâannuaire LDAP et les attributs de Liferay.
e
Liferay nous oďŹre une interface de conďŹguration 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 conďŹguration et le mapping de lâannuaire se fait en modiďŹant les ďŹchiers .properties.
Le serveur CAS utilise lâannuaire pour v´riďŹer et valider les cordonn´es des utilisateurs lors
e e
de lâauthentiďŹcation.
3.8 Conclusion
`
A travers ce chapitre, nous avons pr´sent´ notre besoin technique ainsi que les diďŹÂ´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´ciďŹcations 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 ďŹgure 4.1 pr´sente lâarchitecture op´rationnelle.
e e e
Pour assurer le SSO, nous avons choisi la solution CAS (Central authentiďŹcation 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´riďŹÂ´ les param`tres dâauthentiďŹcation.
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
diďŹÂ´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´ciďŹcation 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 workďŹows (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´ciďŹcation des rameworks utilis´s et leur diďŹÂ´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 ďŹgure 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