ERP Universitaire

6 041 vues

Publié le

Publié dans : Technologie
0 commentaire
4 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
6 041
Sur SlideShare
0
Issues des intégrations
0
Intégrations
138
Actions
Partages
0
Téléchargements
266
Commentaires
0
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

ERP Universitaire

  1. 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 :ITIPartResponsable entreprise : Monsieur Allaeddinne BahriResponsable INSAT : Madame Saloua Ben yahia Ann´e Universitaire : 2012/2013 e
  2. 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. 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. 4. REMERCIMENT Je voudrais avant tout adresser mes sinc`res remerciements aux personnes qui m’ont eapport´ 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
  5. 5. ` TABLE DES MATIERES Introduction g´n´rale e e 11 Pr´sentation du projet e 3 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Pr´sentation d’organisme d’acceuil . . . . . . . . . . . . . . . . . . . . . . . . . e 4 1.2.1 Web agency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.2 Mobile agency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.3 Nearshoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.4 Int´grateur Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . e 5 1.3 Pr´sentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 5 1.3.1 Description du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.2 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.3 Enjeux et avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3.4 Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4 M´thodologie adopt´e : 2TUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . e e 8 1.4.1 Pr´sentation de la m´thodologie 2TUP . . . . . . . . . . . . . . . . . . . e e 8 1.4.2 Application du 2TUP dans notre projet . . . . . . . . . . . . . . . . . . 10 1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Analyse et sp´cification des besoins e 12 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 IV
  6. 6. `TABLE DES MATIERES 2.2 Les acteurs du syst`me . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 e 2.2.1 Administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 ´ 2.2.2 Etudiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.3 Enseignant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.4 Personnel administratif . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.5 Public (visiteur) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3 Sp´cifications fonctionnelles d´taill´es . . . . . . . . . . . . . . . . . . . . . . . . 14 e e e 2.3.1 Module gestion de la biblioth`que e . . . . . . . . . . . . . . . . . . . . . 14 2.3.2 Module gestion des inscriptions et des formations . . . . . . . . . . . . . 16 2.3.3 Module gestion des notes et des r´sultats . . . . . . . . . . . . . . . . . . 18 e 2.3.4 Module gestion des services administratifs et des r´clamations . . . . . . 20 e 2.4 Sp´cifications non-fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 e 2.4.1 Extensibilit´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 e 2.4.2 S´curit´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 e e 2.4.3 Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Pr´sentation de l’environnement technologique e 24 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2 Sp´cification des besoins techniques . . . . . . . . . . . . . . . . . . . . . . . . . 25 e 3.3 Liferay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.4 Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5 Partenariat entre Alfresco et Liferay . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.6 Central authentification service (CAS) . . . . . . . . . . . . . . . . . . . . . . . 30 3.7 OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 Architecture et conception de la solution 33 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2 Architectures de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2.1 Architecture op´rationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 34 e V
  7. 7. `TABLE DES MATIERES 4.2.2 Architectures applicatives . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.3.1 Conception de l’arbre DIT de l’annuaire LDAP . . . . . . . . . . . . . . 40 4.3.2 Conception du mod`le d’acc`s aux donn´es . . . . . . . . . . . . . . . . . 41 e e e 4.3.3 Conception du mod`le d’int´gration des couches (IoC) . . . . . . . . . . 42 e e 4.3.4 Conception des mod`les des donn´es . . . . . . . . . . . . . . . . . . . . 43 e e 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 Impl´mentation et test de la solution e 49 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.2.1 Environnement mat´riel . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 e 5.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.3 Test de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.3.1 Conformit´ aux besoins fonctionnels e . . . . . . . . . . . . . . . . . . . . 51 5.3.2 Conformit´ aux besoins non-fonctionnels . . . . . . . . . . . . . . . . . . 58 e 5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Concluison G´nerale e 63BIBLIOGRAPHIE 65Webographie 66Glossaire 67A Int´gration Liferay, Alfresco, CAS, LDAP e 68 A.1 Etape 1 : Installation et configuration du Liferay avec eclipse . . . . . . . . . . . 69 A.2 Etape 2 : Installation du OpenLdap . . . . . . . . . . . . . . . . . . . . . . . . . 71 A.3 Etape 3 : Installation et configuration du serveur CAS avec OpenLDAP . . . . . 72 A.4 Etape 4 : Activation de l’HTTPS et la configuration d’un certificat SSL sur un serveur Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 A.5 Etape 5 : Configuration Liferay avec LDAP . . . . . . . . . . . . . . . . . . . . 76 VI
  8. 8. `TABLE DES MATIERES A.6 Etape 6 : Configuration Liferay avec CAS . . . . . . . . . . . . . . . . . . . . . 76 A.7 Etape 7 : Installation d’Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 A.8 Etape 8 : Configuration Alfresco avec LDAP . . . . . . . . . . . . . . . . . . . . 79 A.9 Etape 9 : Configuration Alfresco avec CAS . . . . . . . . . . . . . . . . . . . . . 81 VII
  9. 9. TABLE DES FIGURES 1.1 Cycle du d´veloppement par la m´thodologie 2TUP. . . . . . . . . . . . . . . . . e e 9 1.2 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1 Module Gestion biblioth`que : Diagramme de cas d’utilisation . . . . . . . . . . 16 e 2.2 Module Gestion des inscriptions et des formations : Diagramme de cas d’utilisation 18 2.3 Module Gestion des notes et des r´sultats : Diagramme de cas d’utilisation . . . 20 e 2.4 Module Gestion des services et r´clamations : Diagramme de cas d’utilisation . . 22 e 3.1 Architecture de Liferay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2 Architecture d’Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3 Architecture de CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.1 Architecture g´n´ral de l’ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 e e 4.2 Architecture d´taill´e de l’ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 e e 4.3 Architecture du module gestion de la biblioth`que . . . . . . . . . . . . . . . . . 37 e 4.4 Architecture du module gestion des inscriptions et des formations . . . . . . . . 38 4.5 Architecture du module gestion des notes et des r´sultats . . . . . . . . . . . . . 39 e 4.6 Architecture du module gestion des services et des formations . . . . . . . . . . 40 4.7 L’arbre DIT de l’annuaire LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.8 Mod´lisation du Data Access Object . . . . . . . . . . . . . . . . . . . . . . . . 42 e 4.9 Mod´lisation du pattern IoC avec Spring . . . . . . . . . . . . . . . . . . . . . . 43 e4.10 Diagramme de classes : Gestion biblioth`que . . . . . . . . . . . . . . . . . . . . 44 e VIII
  10. 10. TABLE DES FIGURES 4.11 Diagramme de classes : Gestion des formations et des inscriptions . . . . . . . . 45 4.12 Diagramme de classes : Gestion des notes et des r´sultats . . . . . . . . . . . . . 46 e 4.13 Diagramme de classes : Gestion des services et des r´clamations . . . . . . . . . 47 e 5.1 Ajout d’un ouvrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.2 acquisition d’un ouvrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.3 R´server un ouvrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 e 5.4 Gestion des cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.5 Gestion des mati`res . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 e 5.6 Saisie des notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.7 Relev´ de notes g´n´r´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 e e ee 5.8 Demander un service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.9 Traiter les demandes de services . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.10 Interface du serveur CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.11 Gestion d’autorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.12 La configuration de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.13 La variation de charge (chargement des ouvrages de la base de donn´es) e . . . . 61 5.14 La variation de charge (g´n´ration des relev´s de notes) . . . . . . . . . . . . . . 61 e e e A.1 Configuration du Liferay avec Mysql . . . . . . . . . . . . . . . . . . . . . . . . 69 A.2 Installation du Plugin Liferay dans Eclipse . . . . . . . . . . . . . . . . . . . . . 70 A.3 Configuration du SDK Liferay avec Eclipse . . . . . . . . . . . . . . . . . . . . . 70 A.4 Configuration du serveur Liferay (sous Tomcat) avec Eclipse . . . . . . . . . . . 71 A.5 Installation de OpenLdap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 A.6 tester le fonctionnement du serveur CAS . . . . . . . . . . . . . . . . . . . . . . 73 A.7 Configuration du serveur CAS avec OpenLdap . . . . . . . . . . . . . . . . . . 74 A.8 D´finir le domaine de recherche et le param`tre d’authentification . . . . . . . . 74 e e A.9 D´finir et param´trer un certificat ´lectronique . . . . . . . . . . . . . . . . . . . 75 e e e A.10 Activer le HTTPS dans le serveur tomcat . . . . . . . . . . . . . . . . . . . . . 75 A.11 Configurer Liferay avec OpenLdap . . . . . . . . . . . . . . . . . . . . . . . . . 76 A.12 Configurer Liferay avec le serveur CAS . . . . . . . . . . . . . . . . . . . . . . . 77 A.13 Configurer Alfresco avec le MySql . . . . . . . . . . . . . . . . . . . . . . . . . 78 IX
  11. 11. TABLE DES FIGURES A.14 D´finition des ports d’Alfresco e . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 A.15 Configurer Alfresco avec OpenLdap . . . . . . . . . . . . . . . . . . . . . . . . . 80 A.16 Interface d’Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 A.17 Configuration d’Alfresco avec le serveur CAS . . . . . . . . . . . . . . . . . . . . 81 X
  12. 12. LISTE DES TABLEAUX2.1 Module gestion biblioth`que : messages ´mis et re¸us . . . . . . . . . . . . . . . 15 e e c2.2 Module gestion des inscriptions et des formations : messages ´mis et re¸us e c . . . 172.3 Module gestion des notes et des r´sultats : messages ´mis et re¸us . . . . . . . . 19 e e c2.4 Module services administratifs et r´clamations : messages ´mis et re¸us . . . . . 21 e e c5.1 Description de l’environnement logiciel utilis´ . . . . . . . . . . . . . . . . . . . 51 e XI
  13. 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 sarelation 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. Cecie `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 eobjectif principal est de centraliser l’acc`s au syst`me d’information afin de pouvoir recenser les e edonn´es et les placer sur un tableau de bord ´lectronique. Ceci offre un suivi permanent des indi- e ecateurs de performances. Dans ce sens l’ERP est l’un des points clefs du syst`me d’information ed’entreprise actuel. Il agit en tant que concentrateur d’informations. C’est un excellent moyenpour profiter des m´thodes de travail tel que le travail en ´quipe, le partage des ressources, e el’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 eun projet de fin d’´tude, pour pouvoir mettre en oeuvre toutes les possibilit´s offertes par les e eERP d’entreprise et ´voluer du simple site web vers un ERP offrant plus de services et plus de epossibilit´s a ses adh´rents. e ` e 1
  14. 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 esitaire. Il a pour but de situer le contexte du projet, de d´crire son sujet, les m´thodes et outils e eutilis´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 ` el’organisme d’accueil, ainsi que la mise en contexte du projet. Nous expliquerons aussi dansce 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 eprojet. Le chapitre suivant s’intitule Pr´sentation de l’environnement technologique, dans ce echapitre, 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 eAnalyse et sp´cification des besoins dans lequel nous ´tudierons en d´tails les besoins e e efonctionnels et non fonctionnels ainsi que la mod´lisation de ces besoins par le recours aux ediagrammes de cas d’utilisation. Le quatri`me chapitre intitul´ Architecture et conception de la solution sera d´di´ ` e e e eala pr´sentation de l’architecture op´rationnelle et les architectures applicatives et offrira un e eaper¸u des patrons de conception utilis´s. Cet aper¸u m`nera a la conception des diff´rentes c e c e ` efonctionnalit´s offertes. e Le cinqui`me chapitre intitul´ Mise en oeuvre et int´gration pr´sentera les ´tapes de la e e e e er´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 er´sultats atteints et nous exposerons les perspectives ´ventuelles du pr´sent projet. e e e 2
  15. 15. CHAPITRE 1 ´ PRESENTATION DU PROJET 3
  16. 16. ´CHAPITRE 1. PRESENTATION DU PROJET1.1 Introduction Dans ce chapitre, nous aborderons tout d’abord l’environnement du stage en pr´sentant el’entreprise d’accueil connue sous le nom de ITIPart. Puis, nous pr´senterons le cahier de echarges du projet ainsi que ses enjeux et ses avantages. Nous clˆturons ce chapitre par la odescription de la m´thodologie adopt´e pour la r´alisation de l’ERP. e e e1.2 Pr´sentation d’organisme d’acceuil e ITIpart est une soci´t´ d’ing´nierie infor- ee ematique sp´cialis´e dans le d´veloppement et e e ela mise en place des solutions globales au-tour des syst`mes d’information d’entreprise. eElle est sp´cialis´e dans le d´veloppement et e e ela mise en place des solutions globales autourdes 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 ed´veloppement et leur propose de les accompagner dans leur challenges Business dans le cadre ed’une ´troite collaboration et d’une relation de partenariat autour de ses valeurs fondamentales : eTransparence, Engagement et Qualit´. e1.2.1 Web agency ITIPart propose a ses clients de concevoir et r´aliser leurs site Internet professionnels, E- ` ecommerce, r´seau social r´pondant aux normes et standards du web et en parfaite ad´quation e e eavec les activit´s et les cibles du client. e1.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. 17. ´CHAPITRE 1. PRESENTATION DU PROJETde fa¸on beaucoup plus sereine. ITIPart d´veloppe des applications mobiles sous Android, c eIPhome, 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 ` ecomp´tences a la pointe des nouvelles technologies (JEE, .net. Web 2.0, etc) avec une int´gration e ` esur mesure de l’environnement du client (plate-forme, s´curit´, PAQ, etc). e e1.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 epleinement et toute s´curit´ de meilleures solutions de l’open source autour de la GED, CRM... e e1.3 Pr´sentation du projet e Nous envisageons dans ce qui suit la pr´sentation du projet du stage pour bien le comprendre eet 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 cconcise et efficace.1.3.1 Description du projet Ce projet s’intitule Conception de l’architecture et d´veloppement des modules ed’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. eCe travail rentre dans le cadre de mon projet de fin d’´tudes qui vient conclure notre formation ed’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. 18. ´CHAPITRE 1. PRESENTATION DU PROJET1.3.2 Cahier des charges Il s’agit de r´aliser un ERP universitaire modulaire, cet ERP doit couvrir tous les services et eles 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 eou domaine. La consultation peut d´voiler la liste des ouvrages qui seront disponibles dans les etrois 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 esyst`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 eainsi que les annulations des r´servations effectu´es dans le cas o` l’adh´rent n’empruntent pas e e u el’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 ede 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 edes 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 evalid´s selon un WorkFlow. e 6
  19. 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 el’enseignant dans le syst`me de notation utilis´ par l’Ecole. Ce module permettra d’acc´l´rer e e eela 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 eg´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- ement avec la r´clamation. e Le responsable administratif doit pouvoir traiter les r´clamations pr´sent´es par l’enseignant e e eou 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 etrait´e. e Lorsque le responsable administratif re¸oit la r´clamation, il peut changer son ´tat en ac- c e ecus´ de r´ception, en cours, rejet´e, non soluble ou termin´e selon l’´tat d’avance- e e e e ement du traitement de la r´clamation. L’´tat d’avancement reste accessible a l’initiateur de la e e `r´clamation. e1.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 eindustriels. -Num´risation des documents de l’universit´ : G´rer, organiser et d´finir les droits d’acc`s e e e e eaux documents ´lectroniques (Document Management System). e -Faciliter la recherche de l’information : Ce service permet au public de chercher par unou plusieurs mots cl´. Lorsque ce module est utilis´ par un membre authentifi´, la recherche e e edoit se faire dans toutes les pages accessibles par ce membre. 7
  20. 20. ´CHAPITRE 1. PRESENTATION DU PROJET1.3.4 Objectif L’objectif de ce projet est d’avoir une version bˆta qui couvre la majorit´ des fonctionnalit´s e e ed’un ERP universitaire. Nous devons avoir des modules coh´rents au niveau des fonctionnalit´s e eet une vision claire sur le r´sultat attendu. e1.4 M´thodologie adopt´e : 2TUP e e1.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 eune 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. Cesdeux 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 etechnique, la branche technique peut ˆtre trait´e puis r´int´gr´e dans le projet facilement. De e e e e emˆme si une nouvelle fonctionnalit´ se pr´sente, seule la branche fonctionnelle va ˆtre trait´e e e e e esans toucher ` l’autre branche. a Principe : Ce processus commence par une ´tude pr´liminaire qui permet d’identifier les acteurs du e esyst`me a mettre en oeuvre qui est consid´r´ comme une boˆ noir tout en pr´sentant les e ` ee ıte ediff´rents messages entre les utilisateurs et ce syst`me et d’´laborer le cahier de charges. La e e efigure montre les diff´rentes ´tapes de processus 2TUP. e e 8
  21. 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 em´tier des utilisateurs. Cette ´tape ´limine le risque d’avoir un syst`me inadapt´ aux besoins e e e e edes utilisateurs. L’analyse qui consiste a ´tudier les besoins fonctionnels de mani`re ` obtenir une id´e de `e e a ece 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 edimensionnement et de conception du syst`me. Les outils s´lectionn´s ainsi que les contraintes e e ed’int´gration avec l’existant (pr´-requis d’architecture technique). e e 9
  22. 22. ´CHAPITRE 1. PRESENTATION DU PROJETL’´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 etionnels. 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 ed’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 eunitaires 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 eindustriel par excellence de la mod´lisation objet. Cela est d’autant plus probant quand on eprend connaissance qu’UML unifie a la fois les notations et les concepts orient´s objets. ` e1.4.2 Application du 2TUP dans notre projet Dans notre projet, nous avons commenc´ par la d´finition des besoins fonctionnels, nous e eavons d´coup´ l’ERP en dix modules. e e Ce PFE comporte quatre modules avec la mise en place de l’environnement. Nous avonspr´cis´ l’architecture op´rationnelle ainsi que les architectures fonctionnelles. Par la suite, nous e e enous sommes focalis´s sur la conception de la base de donn´es de L’ERP. Puis, nous avons e ecommenc´ le d´veloppement des modules, chacun a part. Enfin, nous avons r´serv´ quatre e e ` e esemaines pour la r´daction du rapport. e 10
  23. 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 aGantt : 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 ed´cembre 2012. Nous avons commenc´ par une ´tude pour capturer les besoins fonctionnels et e e enon-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 enotre travail et nous avons con¸u et d´velopp´ notre ERP. Au dernier mois, nous avons r´dig´ c e e e ele 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 eEnfin, nous avons pr´sent´ la m´thodologie adopt´e. Dans le chapitre suivant, nous allons e e e esp´cifier nos besoins en d´tail. e e 11
  24. 24. CHAPITRE 2 ´ ANALYSE ET SPECIFICATION DES BESOINS 12
  25. 25. ´CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS2.1 Introduction Dans ce chapitre, nous pr´sentons les diff´rentes ´tapes suivies pour r´aliser l’analyse et e e e esp´cification des besoins en se r´f´rant au processus unifi´ 2TUP. Nous commen¸ons par l’i- e ee e cdentification des acteurs principaux. Puis, nous allons analyser les besoins fonctionnels pourchaque 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- ement 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 efonctions principales sont la gestion des acc`s, la gestion des droits des utilisateurs du syst`me e eet la mise a jour du contenu des portlets du portail si n´cessaire. ` e2.2.2 ´ Etudiant Chaque ´tudiant aura un espace priv´ et un espace public, dans lequel il pourra consulter e eles informations et les services autoris´s par l’administrateur (notes, emploi du temps, Bib- elioth`que...). Il pourra utiliser l’espace collaboratif de l’ERP tel que les blogs, les forums, les ewikis...2.2.3 Enseignant L’enseignant pourra g´rer son espace dans le portail en diffusant des messages et des annonces epour ses ´tudiants. Il aura ´galement b´n´fici´ des services sp´cifiques comme les services de la e e e e e ebiblioth`que, le passage d’une r´clamation, la saisie des notes en ligne... e e 13
  26. 26. ´CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS2.2.4 Personnel administratif Ce sont les responsables de la gestion et de l’´mission des documents administratifs inh´rents e eaux besoins des ´tudiants (certificats de r´ussite, de pr´sence, etc...), la gestion des ouvrages, e e edes 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 e2.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 eY. Elle formalise et d´taille les cas d’utilisation et les associe aux acteurs appropri´s. e e2.3.1 Module gestion de la biblioth`que eIdentification 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 egestion de la biblioth`que avec les messages re¸us et ´mis : e c e 14
  27. 27. ´CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINSCas d’utilisation Sous cas d’utilisation Acteurs Messages re¸us/´mis c e D´finition des rˆles e oModule Gestion G´r´e par le panneau ee et des permissions Administrateurbiblioth`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. 28. ´CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINSDescription du cas d’utilisationNous 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 e2.3.2 Module gestion des inscriptions et des formationsIdentification 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 egestion des inscriptions et des formations avec les messages re¸us et ´mis : c e 16
  29. 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 cDescription du cas d’utilisationNous pr´sentons dans la figure 2.2 le cas d’utilisation du module gestion des inscriptions et des eformations : 17
  30. 30. ´CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINSFigure 2.2 – Module Gestion des inscriptions et des formations : Diagramme de cas d’utilisa-tion2.3.3 Module gestion des notes et des r´sultats eIdentification 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 egestion des notes et des r´sultats avec les messages re¸us et ´mis : e c e 18
  31. 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 cDescription du cas d’utilisationNous pr´sentons dans la figure 2.3 le cas d’utilisation du module gestion des notes et des er´sultats : e 19
  32. 32. ´CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS Figure 2.3 – Module Gestion des notes et des r´sultats : Diagramme de cas d’utilisation e2.3.4 Module gestion des services administratifs et des r´clamations eIdentification 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 eservices administratifs et r´clamations avec les massages re¸us et ´mis : e c e 20
  33. 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 cDescription du cas d’utilisationNous pr´sentons dans la figure 2.4 le cas d’utilisation du module services administratifs et er´clamations : e 21
  34. 34. ´CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS Figure 2.4 – Module Gestion des services et r´clamations : Diagramme de cas d’utilisation e2.4 Sp´cifications non-fonctionnelles e2.4.1 Extensibilit´ e L’extensibilit´ l’une des sp´cifications important d’un ERP. Notre architecture doit supporter e eles extensions de nouvelles fonctionnalit´s sans pour autant la modifier ´norm´ment. Notre code e e edevra ˆtre ferm´ a la modification et ouvert a l’extension. e e` ` 22
  35. 35. ´CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS2.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 edevons avoir un syst`me d’acc`s s´curis´ bas´ sur l’authentification et la gestion des autorisa- e e e e etions : 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 edynamique : on aura la possibilit´ de cr´er ou de modifier les rˆles en associant la combinaison e e ode permission ad´quate. e2.4.3 Performances La performance des services offerts est critique, notamment pour l’importance du facteurtemps 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 enels en pr´sentant un diagramme de cas d’utilisation pour chaque module avec la sp´cification e edes besoins non-fonctionnels de la solution. Dans le prochain chapitre nous entamons la miseen place de l’environnement op’erationnel. 23
  36. 36. CHAPITRE 3 ´PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE 24
  37. 37. ´CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE3.1 Introduction Dans ce chapitre nous exposons nos besoins techniques en d´tail. Nous pr´senterons les e ediff´rentes technologies utilis´es pour construire notre architecture op´rationnelle. Nous ex- e e epliquons l’int´rˆt de chaque choix effectu´. ee e3.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 eECM), nous utiliserons une solution Single Sign One (SSO), la solution adopt´e pour serveur ed’authentification est le serveur CAS. Dans notre cas, la centralisation des utilisateurs est indispensable pour la coh´rence de traite- ement de l’ERP. Les groupes d’utilisateurs devrons ˆtre les mˆmes dans le portail et l’ECM. En e econs´quence, on utilisera un annuaire Lightweight Directory Access Protocol (LDAP). OpenL- edap est la solution choisie pour notre projet. 25
  38. 38. ´CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE3.3 Liferay Liferay Portal est le leader mondial des solutions open source de portail d’entreprise, utilisantles derni`res technologies Java et Web 2.0. e Dans notre projet, Liferay offre un espacecollaboratif : un ensemble des composantsr´utilisables et configurables tel que Forums, eBlogs, 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 workflowde 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 eInterface (API) Portlet (JSR-168). Liferay est ´galement compatible avec la seconde impl´mentation e ede 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 echaque module est un projet a part. Nous devons respecter la sp´cification dans notre d´veloppement ` e epour que l’int´gration soit possible. e Liferay impl´mente un moteur de recherche interne puissant, ce moteur indexe les donn´es e eutilis´es par les portlets natifs avec la prise en compte des droits d’acc`s. e e 26
  39. 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 laversion 6 de Liferay. Ce projet nous permet de personnaliser le noyau du Liferay selon notrem´tier. Nous avons besoin de personnaliser des interfaces natives de Liferay avec la modification ede 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 epour les rendre accessibles par le moteur de recherche. L’ensemble est int´gr´ comme une e eressource dans la pile de gestion des droits classiques de Liferay.[4] 27
  40. 40. ´CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE La couche pr´sentation de Liferay utilise le moteur de templating Velocity. Avec Velocity, ela couche pr´sentation sera faiblement coupl´e avec les couches inf´rieures. e e eCe 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 deprojet, nous pouvons d´velopper un th`me en utilisant des fichiers VM (extension des fichiers e ereconnus 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 ed’administration de Liferay. Pour pouvoir personnaliser les layouts des pages, Liferay fournit un projet qui s’appelleLayout. Dans ce projet on peut d´couper nos pages selon notre besoin. Ce Layout peut ˆtre e eutilis´ plusieurs fois et dans plusieurs projets. e3.4 Alfresco Alfresco est un syst`me de gestion de contenu (en anglais ECM pour Enterprise Content Man- eagement) cr´´ par Alfresco Software en 2005 et distribu´ sous licence libre.[2] ee e Dans notre projet, Alfresco nous fournit unGED tr`s puissant. Il offre des workflows stan- edards pour la gestion des documents. Avec Activiti, nous pouvons d´velopper des eworkflows personnalis´s, par exemple : un eworkflow pour g´rer le cycle de vie d’un dossier d’inscription, un workflow pour la validation edes cours... L’une des fonctionnalit´s d’Alfresco, est la gestion des r`gles de contenu (content rules). e eLes r`gles de contenu permettent d’ajouter de l’intelligence a vos r´pertoires, dossiers, espaces, e ` ed’une mani`re comparable aux filtres que vous pouvez d´finir pour votre messagerie email. e e 28
  41. 41. ´CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUENous avons besoin de ces r`gles pour bien organiser nos documents (Administratif, dossiers ed’inscription...). Alfresco int`gre son propre moteur de recherche, il utilise Apache Lucene pour indexer les edocuments. Ce moteur est tr`s param`trable, nous pouvons filtrer les recherches par date, e edossier, espaces... Figure 3.2 – Architecture d’Alfresco Alfresco supporte plusieurs extensions, il a la possibilit´ de faire la convertion des documents. ePour 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 ela collaboration sur internet. Dans notre projet, ce protocole nous offre la possibilit´ de travailler e 29
  42. 42. ´CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUEsur des r´pertoires virtuels sur le disque local, il facilite la manipulation des fichiers. e3.5 Partenariat entre Alfresco et Liferay Liferay et Alfresco ont fait un partenariat afin d’offrir un portail entreprise et un ECM avecune int´gration compl`te. e e Alfresco impl´mente le protocole Content Management Interoperability Services (CMIS), le ebut 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 effectuerles 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 eelle est bˆtie sur le protocole CMIS. aLiferay 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 ele fonctionnement et l’int´gration de Liferay et Alfresco : ehttp ://www.alfresco.com/products/integrations/liferay3.6 Central authentification service (CAS) CAS est un syst`me d’authentification unique : on s’authentifie sur un site Web, et on est alors eauthentifi´ sur tous les sites Web qui utilisent le mˆme serveur CAS. Il ´vite de s’authentifier e e ea 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 epermet 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 eforte. Nous devons configurer Tomcat avec un certificat ´lectronique. e 30
  43. 43. ´CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE CAS fournit des librairies clients afin de faciliter cette int´gration avec Liferay et Alfresco. eCAS fonctionne sous n’importe quel serveur d’application (Tomcat, JBOSS...). Il est d´velopp´ e eavec des servlets et des pages JSP, nous pouvons modifier le th`me du CAS en modifiant edirectement 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 etickets sont enregistr´s dans les cookies, pour cela, le navigateur web doit accepter les cookies esi non, l’utilisateur devra se r´-authentifier a chaque appel au serveur CAS. e ` 31
  44. 44. ´CHAPITRE 3. PRESENTATION DE L’ENVIRONNEMENT TECHNOLOGIQUE3.7 OpenLDAP OpenLdap est un annuaire ´lectronique, il s’agit d’une base de donn´es sp´cialis´e qui permet e e e ede partager des bases d’informations sur un r´seau. Ces bases peuvent contenir toute sorte ed’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 ecordonn´es des membres de Liferay et Al- efresco, les utilisateurs seront regroup´s selon eleurs statuts (´tudiant, enseignant, personnel eadministratif, administrateur).Nous pouvons cr´er un arbre DIT pour ebien organiser les utilisateurs (´tudiant, en- eseignant, personnel administratif, administrateur). Liferay importe les utilisateurs lors de son d´marrage. Dans la phase de configuration, nous edevons pr´ciser le mapping entre les attributs de l’annuaire LDAP et les attributs de Liferay. eLiferay 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 eLa 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 ede l’authentification.3.8 Conclusion ` A travers ce chapitre, nous avons pr´sent´ notre besoin technique ainsi que les diff´rents e e ecomposants utilis´s. Nous avons pr´sent´ Liferay, Alfresco, OpenLdap et le serveur CAS. Nous e e eavons ´tudi´ la possibilit´ de l’int´gration entre eux. Dans le quatri`me chapitre, nous d´taillons e e e e e enos architectures avec une conception de notre solution. 32
  45. 45. CHAPITRE 4 ARCHITECTURE ET CONCEPTION DE LA SOLUTION 33
  46. 46. CHAPITRE 4. ARCHITECTURE ET CONCEPTION DE LA SOLUTION4.1 Introduction Dans ce chapitre, nous exposons d’abord l’architecture op´rationnelle de la solution ainsi que eles architectures applicatives, avant d’entamer ensuite la phase de conception, nous pr´senterons ela conception de l’arbre DIT de l’annuaire LDAP, le mod`le d’acc`s aux donn´es, le pattern e e eIoC (Inversion Of Control) et les mod`les des donn´es. e e4.2 Architectures de la solution Nous exposons d’abord l’architecture op´rationnelle cible de la solution ainsi que les archi- etectures applicatives.4.2.1 Architecture op´rationnelle e Au vu des sp´cifications fonctionnelles et des exigences techniques, nous proposons l’archi- etecture 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 er´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 edans 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. 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 aterop´rabilit´ d’Alfresco. e eArchitecture 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 ediff´rents composants de Liferay ainsi que ceux d’Alfresco. e 35

×