RÉPUBLIQUE DU BÉNIN
¤¤¤¤¤¤¤¤¤¤
UNIVERSITÉ D’ABOMEY - CALAVI
¤¤¤¤¤¤¤¤¤¤
ECOLE POLYTECHNIQUE D’ABOMEY-CALAVI
¤¤¤¤¤¤¤¤¤¤¤¤¤
DEPARTEMENT DE GENIE INFORMATIQUE ET TELECOMMUNICATIONS (GIT)
Option : Réseaux Informatiques et Internet (RII)
MÉMOIRE DE FIN DE FORMATION
EN VUE DE L’OBTENTION DU
DIPLÔME D’INGENIEUR DE CONCEPTION
Réalisé et soutenu par : Fréjus Léonel Oyédélé ADJE Le lundi 26 décembre 2016 devant le jury composé de :
Président : Dr. SOGBOHOSSOU Médésu Enseignant à l’EPAC
Membres : Dr. EDOH Thierry Oscar Enseignant UATM/Allemagne (Maître de mémoire)
M. ANAGO Didier Enseignant à l’EPAC
M. KONNON Appolinaire Ingénieur Réseaux et Systèmes
Année Académique : 2015 – 2016
9ème Promotion
CONCEPTION ET DEVELOPPEMENT D’UNE PLATEFORME WEB DE GESTION DE DOSSIER D’ETUDIANT : Cas de l’Ecole
Polytechnique d’Abomey-Calavi
SOMMAIRE
SOMMAIRE ... i
DEDICACES ... iii
REMERCIEMENTS ... iv
LISTE DES SIGLES ET ABREVIATIONS ... vi
LISTE DES TABLEAUX ... x
LISTE DES FIGURES ... xii
RESUME... xiv
ABSTRACT ... xv
INTRODUCTION GENERALE ... 1
PARTIE I SYNTHESE BIBLIOGRAPHIQUE ... 5
Chapitre 1 : Le dossier académique de l’étudiant ... 6
Chapitre 2 : Quelques systèmes de gestion des données académiques de l’étudiant ... 9
PARTIE II MATERIELS ET METHODES ... 17
Chapitre 3 : Méthodologie de conception ... 18
Chapitre 4 : Architecture du système ... 31
Chapitre 5 : Détermination des outils et technologies de développement ... 60
PARTIE III RESULTATS ... 65
Chapitre 6 : Implémentation et tests ... 66
CONCLUSION ET PERSPECTIVES ... 77
RÉFÉRENCES BIBLIOGRAPHIQUES ... 79
ANNEXES ... 82
ANNEXE A | Laravel5.0 : Architecture MVC et Programmation Orientée Objet (POO) ... 83
ANNEXE B | Les Protocoles de communication ... 84
ANNEXE C | Présentation du projet dans PhpStorm ... 91
ENGLISH VERSION ... 99 TABLE DES MATIÈRES ... 113
DEDICACES
Je dédie ce travail,
A toi Seigneur pour tout ce que tu as fait pour moi tout au long de ma vie. Merci de m’avoir mené jusqu’ici car sans toi je n’y serais pas arrivé. Gloire à Dieu pour l’éternité.
A mon père Abioyé ADJE et ma mère Bernadette CHABI pour leurs nombreuses marques d’affection, leurs sacrifices, et leurs précieux conseils qui m’ont permis de réussir tout au long de mes études ; à mon frère Thierry ; à mes sœurs Edwige, Urielle et Loéticia ; à mes amis pour leurs soutiens et à Samson ASSOGBA.
Que le Saint Père leur procure la réussite, une bonne santé, une longue et heureuse vie.
Fréjus Léonel O. ADJE
REMERCIEMENTS
Je m'en voudrais de commencer ce rapport sans présenter mes sincères remerciements à tous ceux qui, de près ou de loin, ont contribué à l'élaboration de ce document. Je pense particulièrement :
Au Professeur Mohamed SOUMANOU, Directeur de l'École Polytechnique d'Abomey-Calavi (EPAC) et à son adjoint le Professeur Clément AHOUANNOU ;
Au Docteur Léopold DJOGBE, Chef du département de Génie Informatique et Télécommunications (GIT) de l'EPAC ;
À mon maître de mémoire, le Docteur Thierry Oscar EDOH, qui a accepté m'encadrer pour le présent travail ainsi que pour ses précieux apports, sa disponibilité et ses conseils judicieux ;
Au Professeur Marc Kokou ASSOGBA, Directeur du Laboratoire d'Electrotechnique de Télécommunications et d'informatique Appliquée pour m'avoir accueilli dans son laboratoire pour mon stage ;
Au Docteur Michel DOSSOU, pour son soutien, son aide et ses conseils ;
Aux Ingénieurs Alahassa BIDOSSESSI, Cédric AMONLE et aux Messieurs Salimane Adjao MOUSTAPHA, Emmanuel Marie PODANHO, pour tous leurs conseils, apports, disponibilités et soutiens ;
À tous les enseignants du département de GIT pour la qualité de leurs enseignements ;
À tout le personnel de TEKXL, pour leur accueil chaleureux pendant toute la durée de mon stage et pour leur aide ;
Aux aînés pour leur aides et conseils ;
À toute ma famille pour leur soutien indéfectible ;
À tous mes camarades de la 9ème promotion du Secteur Industriel de l'EPAC en particulier Laurenda, Aubrey, Bebert, Éric, Dichoso,
Sébastiano, Prosper, Brunel, Rodolphe, Francine et Rodrigue, pour tous les bons moments passés ensemble ;
À tous les membres du CERADEI-GIT (Cercle d'Echange, de Réflexion et d'Action des Élèves Ingénieurs en Génie Informatique et Télécommunications) au sein duquel j'ai eu l'honneur de travailler en tant que Secrétaire Général puis Président du Bureau Exécutif ;
À mes amis et à tous ceux que je ne pourrais citer ici.
F
G
LISTE DES SIGLES ET ABREVIATIONS
AJAX Asynchronous JAvascript and Xml
AMUE Agence de Modernisation des Universités et Etablissements APOGEE Application POur la Gestion des Etudiants et des
Enseignements
ASP.Net Active Server Pages distributed with .NET framework
CMS Content Management System CRUD Create Read Update Delete CSS Cascading Style Sheet CV Curriculum Vitae
EDI Environnement de Développement Intégré EPAC Ecole Polytechnique d’Abomey-Calavi EPFL Ecole Polytechnique Fédérale de Lausanne
FTP File Transfer Protocol
GSM Global System for Mobile Communications A
C
E
H
I
J
L
M
HTML HyperText Markup Language HTTP HyperText Transfer Protocol
ICMP Internet Control Message Protocol IDE Integrated Development Environment IETF Internet Engineering Task Force IGMP Internet Group Management Protocol IHM Interface Homme-Machine
IP Internet Protocol
JSON JavaScript Object Notation JSP JavaServer Pages
LAN Local Area Network
MVC Modèle-Vue-Contrôleur (Model-View-Controller)
O
P
R
S
T
ORM Object Relational Mapping
PC Personal Computer
PGI Progiciel de Gestion Intégré PHP Hypertext Preprocessor
POO Programmation Orienté Objet
RAID Redundant Arrays of Inexpensive Disks
Sass Syntactically Awesome Style Sheets SGBD Système de Gestion de Base de Données SI Système d’Information
SMTP Simple Mail Transfer Protocol SQL Structured Query Language SSL Secure Socket Layer
TCP Transmission Control Protocol
Telnet Terminal network – Teletype network
TIC Technologies de l’Information et de la Communication TLS Transport Layer Security
U
W
X
UAC Université d’Abomey-Calavi UDP User Datagram Protocol UML Unified Modeling Language
UMTS Universal Mobile Telecommunication System URL Uniform Resource Locator
UTS University of Technology Sydney
WWW World Wide Web
XML EXtensible Markup Language
LISTE DES TABLEAUX
Tableau 1 : Les acteurs du système et leurs rôles ... 35
Tableau 2 : Authentification de tous les utilisateurs ... 39
Tableau 3 : Gérer les rôles ... 40
Tableau 4 : Gérer les droits/permissions ... 40
Tableau 5 : Gérer les affections de permissions ... 40
Tableau 6 : Créer un compte d’utilisateur ... 41
Tableau 7 : Modifier les informations d’un compte ... 42
Tableau 8 : Activer/Désactiver un compte ... 42
Tableau 9 : Afficher le profil d’un utilisateur ... 42
Tableau 10 : Gérer les thématiques (sujets de discussion) ... 43
Tableau 11 : Gérer les commentaires... 44
Tableau 12 : Créer et supprimer une université ... 45
Tableau 13 : Modifier les informations d’une université ... 45
Tableau 14 : Créer et supprimer une entité ... 45
Tableau 15 : Modifier les informations d’une entité ... 46
Tableau 16 : Gérer les requêtes administratives ... 46
Tableau 17 : Gérer les catégories de requêtes ... 46
Tableau 18 : Gérer les départements ... 47
Tableau 19 : Mise à jour d’un chef de département ... 47
Tableau 20 : Gérer les options ... 47
Tableau 21 : Gérer les modules de cours ... 49
Tableau 22 : Assigner un cours à un enseignant ... 50
Tableau 23 : Gérer les notes des étudiants – Partie 1 ... 50
Tableau 24 : Gérer les notes des étudiants – Partie 2 ... 50
Tableau 25 : Gérer les projets académiques ... 51
Tableau 26 : Gérer les catégories de projets académiques ... 51
Tableau 27 : Gérer les calendriers académiques ... 51
Tableau 28 : Gérer les notifications ... 52
Tableau 29 : Gérer les modèles de notifications ... 52
Tableau 30 : Gérer l’historique ... 52
Tableau 31 : Gérer des médias ... 53
Table : Actors of our system and theirs roles ... 103
LISTE DES FIGURES
Figure 2.1 : Couverture fonctionnelle du logiciel IS-Academia (Source : [3]).. 12
Figure 3.1 : Schéma de la méthode du Cycle en V ... 18
Figure 3.2 : Architecture « Client-serveur » ... 28
Figure 3.3 : Architecture « 4-tiers » ... 29
Figure 4.1 : Diagramme global des cas d’utilisation de système ... 37
Figure 4.2 : Diagramme de cas d’utilisation du paquetage « Gestion des rôles et permission » ... 39
Figure 4.3 : Diagramme de cas d’utilisation du paquetage « Gestion des comptes utilisateurs » ... 41
Figure 4.4 : Diagramme de cas d’utilisation du paquetage « Gestion de forums » ... 43
Figure 4.5 : Diagramme de cas d’utilisation du paquetage « Gestion des entités universitaires » ... 44
Figure 4.6 : Diagramme de cas d’utilisation du paquetage « Gestion des unités d’enseignements » ... 48
Figure 4.7 : Diagramme de cas d’utilisation du paquetage « Gestion des projets académiques » ... 49
Figure 4.8 : Diagramme de séquence du scénario « S’authentifier » ... 55
Figure 4.9 : Diagramme de séquence du scénario « Valider un compte étudiant » ... 56
Figure 4.10 : Diagramme de séquence du scénario « Modifier les informations d’un département » ... 57
Figure 4.11 : Diagramme de séquence du scénario « Ajouter une pièce au dossier académique » ... 57
Figure 4.12 : Diagramme de classes ... 59
Figure 6.1 : Page de connexion de la plateforme ... 67
Figure 6.2 : Page de validation d’un compte étudiant ... 68
Figure 6.3 : Page d’accueil du module de gestion des utilisateurs ... 69
Figure 6.4 : Profil de l’étudiant ... 69
Figure 6.5 : Page d’accueil du module de gestion des dossiers académiques ... 70
Figure 6.6 : Interface d’authentification de PHPMyAdmin ... 72
Figure B-1 : Transfert de données à travers la pile de protocoles d‘Internet (Source : [11]) ... 84
Figure B-2 : Relations entre l’architecture du système et les couches de protocoles ... 85
Figure C-1 : Architecture du projet Laravel dans PhpStorm ... 92
Figure C-2 : Contenu du dossier « app » ... 93
Figure C-3 : Contenu du dossier « config » ... 95
Figure C-4 : Contenu du dossier « database » ... 95
Figure C-5 : Contenu du dossier « public » ... 96
Figure C-6 : Contenu du dossier « resources » ... 97
Figure C-7 : Contenu du fichier « .env » ... 98
Figure 1 : Adopted architecture ... 102
Figure 2 : Global use cases diagram ... 105
Figure 3 : Sequence diagram of the authentication scenario ... 106
Figure 4 : Class diagram ... 107
Figure 5 : Authentification page ... 109
Figure 6 : User profile ... 110
Figure 7 : Home of Users management module ... 110
Figure 8 : Home Page of academic record module ... 111
RESUME
Le parcours estudiantin d’un étudiant est souvent documenté dans le dossier académique de l’étudiant. L’Université d’Abomey-Calavi dispose pour chaque étudiant d’un dossier académique. Ce dernier est l’un des outils indispensables dans la gestion des données académiques des étudiants en milieu universitaire, en ce sens qu’il permet de suivre et de contrôler les informations de son cursus. Une mise à jour régulière du dossier est indispensable pour assurer l’authenticité des données du dossier ainsi que sa distribution et son accessibilité.
Dans le cadre de notre projet de mémoire, nous avons mis en place une plateforme de gestion de dossiers académiques des étudiants de l’Ecole Polytechnique d’Abomey-Calavi. Grâce aux fonctionnalités de notre plateforme web, nous avons pu automatiser la gestion de ces dossiers ce qui permet de disposer des dossiers distribués, à jour et accessibles à tous. Parmi les modules qu’elle intègre, notre plateforme dispose d’une part d’un module de gestion des utilisateurs, et d’autre part d’un module de gestion des informations académiques permettant la mise à jour régulière des dossiers.
Mots-clés : Conception, plateforme web, dossier d’étudiant, dossier académique, dossier universitaire.
ABSTRACT
The student's background is often documented in an academic record of student. The University of Abomey-Calavi has this academic record for each student. This transcript is one of the indispensable tools in managing of student’s academic data in university environment. This record helps enormously in processing student's academic data in order to monitor and control the courses of study details. Regular updating of the record is essential to ensure the authenticity of the transcript's data as well as its distribution and accessibility.
In our dissertation, we developed a platform for management of student academic records of Polytechnic of Abomey-Calavi. The functionalities of our web platform allow us to automate the management of student records, enabling us to have up-to-date distributed transcripts and accessible to all. Among the modules it integrates, our platform has two main modules : first, a users management module, and second a processing of academic data module thus allowing the regular updating of student records.
Keywords : Design, platform, web application, academic transcript, academic record, student record.
INTRODUCTION GENERALE
INTRODUCTION GENERALE
Face aux nombreux défis auxquels sont confrontées les universités (gestion administrative et financière, suivi des cursus des étudiants, promotion des meilleurs étudiants, etc.), il est important de souligner le rôle qu’occupe les technologies de l’information et de la communication (TIC) dans la recherche de solutions informatiques adéquates. En effet, l’utilisation de dossier académique – ensemble d’informations relatives à un étudiant ainsi que l’historique du cursus universitaire de ce dernier – dans les universités est un élément primordial dans le suivi d’un étudiant et la gestion administrative et financière de son dossier. Ce dossier qui, dans la majorité des pays en Afrique, se présente communément sous le format « papier » pose un certain nombre des problèmes dont la non- distribution, l’absence de mise à jour effective, la perte de certains dossiers, etc.
Afin de palier un tant soit peu à certains de ces problèmes, nous utiliserons les services de l’Internet (le World Wide Web, le transfert de fichiers, …) pour mettre sur pied une plateforme web de gestion des données académiques des étudiants d’une université dans le but de disposer d’un dossier d’étudiant consultable en ligne.
Par cette étude, nous commencerons d’abord par présenter les différents éléments qui interviendront dans la conception et la réalisation de la plateforme.
Ensuite nous mettrons en place l’architecture générale de la plateforme puis nous passerons à l’implémentation du système.
CONTEXTE, JUSTIFICATION ET PROBLEMATIQUE
Dans le cadre du suivi et de la gestion des universités, ces dernières disposent des informations relatives à chacun de ses étudiants. Ces informations qui varient d’un étudiant à un autre ainsi que d’une université à un autre, sont dans
certains cas regroupées dans un dossier appelé dossier d’étudiant. Ces dossiers d’étudiants qui sont pour la majorité en format papier ne sont qu’accessible à un nombre restreint de personnes. Il faut aussi noter qu’hormis le problème d’archivage de ces dossiers, ces dernières manquent de mise à jour régulière dans le temps ce qui diminuent leur valeur et leur authenticité.
Face à ces différents problèmes auxquels il est nécessaire de trouver des solutions, il est indispensable de mettre à contribution les progrès de l’informatique. Ainsi, il s’agira de mettre en place un système de gestion des données académiques des étudiants dans nos universités afin de disposer d’un dossier académique par étudiant à jour et consultable en ligne.
OBJECTIFS
L’objectif principal qui nous amène à l’exploration de notre sujet est de mettre en place un système informatique permettant de gérer plus efficacement les données des étudiants afin de disposer d’un dossier d’étudiant consultable en ligne.
Plus précisément, il s’agira dans un premier temps de faire une brève étude de l’existant, suivi d’une analyse des données recueillies lors de l’étude, ensuite concevoir l’architecture complète du système informatif à mettre en place et enfin procéder à l’implémentation de la plateforme web.
STRUCTURE DU DOCUMENT
Le présent document expose l’ensemble des recherches et travaux effectués, ainsi que les résultats obtenus, dans le cadre de notre projet de mémoire qui s’intitule comme suit : « Conception et développement d’une plateforme web de gestion de dossier d’étudiant : Cas de l’Ecole Polytechnique d’Abomey- Calavi ». Cette section nous permet de passer en revue les différentes tâches effectuées dans le cadre de notre mémoire afin d’atteindre les objectifs que nous
INTRODUCTION GENERALE
nous sommes fixés. Le présent document comporte (05) cinq chapitres et est subdivisé en trois parties.
La première partie composée des deux premiers chapitres dont le premier chapitre nous permet d’avoir une vue d’ensemble sur le concept de dossier académique de l’étudiant. Nous faisons un bref exposé sur la notion de dossier académique de l’étudiant. Pour cela nous avons répondu aux questions comme
« Qu’est-ce que le dossier académique de l’étudiant ? », « De quoi est constitué le dossier académique d’un étudiant ? ». Dans le second chapitre, nous avons procédé à une étude de quelques systèmes de gestion de données académiques afin d’avoir une vue d’ensemble des différentes fonctionnalités nécessaires pour mettre en œuvre une plateforme de gestion de dossier d’étudiant pour l’Ecole Polytechnique d’Abomey-Calavi.
Les trois prochains chapitres de notre document constituent la deuxième partie.
A travers le troisième chapitre, nous avons présenté notre méthodologie de conception. Plus précisément, nous avons défini dans un premier temps la méthode pour la conception de notre solution, ensuite nous avons présenté les spécifications fonctionnelles des besoins pour le système à mettre en place et enfin nous avons fait part de l’architecture et du fonctionnement global de la solution proposée. La modélisation du système est présentée dans le quatrième chapitre.
Nous avons présenté les acteurs et rôles du système et une description détaillée de chacune des fonctionnalités du nouveau système, en précisant pour chacune d’elles un ensemble de caractéristiques afin de mieux appréhender le concept et de faciliter la mise en œuvre. Afin de mieux comprendre comment le système est modélisé, nous avons utilisé les diagrammes suivants :
Les diagrammes de cas d’utilisation : Ils permettent de recueillir, d'analyser et d'organiser les besoins, et de recenser les grandes fonctionnalités d'un système ;
Les diagrammes de séquences : Ce sont la représentation graphique des interactions entre les acteurs et le système selon un ordre chronologique dans la formulation Unified Modeling Language (UML) ;
Le diagramme de classes : C’est un schéma utilisé en génie logiciel pour présenter les classes et les interfaces des systèmes ainsi que les différentes relations entre celles-ci.
En dernier dans le cinquième chapitre, nous avons parlé des outils et technologies utilisés pour l’implémentation de notre système.
La dernière partie, c’est-à-dire la troisième partie que représente le dernier chapitre (chapitre 6), nous a permis de présenter les résultats de nos travaux. Ainsi, nous avons parlé de l’implémentation de la plateforme ainsi que de son ergonomie, de ses interfaces et surtout de l’aspect sécuritaire. De plus nous avons eu à mettre un accent particulier sur les limites du système et à présenter des tests effectués ainsi que des résultats obtenus.
Première Partie
PARTIE I SYNTHESE BIBLIOGRAPHIQUE
C hapitre 1
:Le dossier académique de l’étudiant
Dans le but de mieux cerner l’utilité des Systèmes d’Information des Ressources Humaines (SIRH), tout au long du présent chapitre nous avons exposé les généralités sur leur conception et leur architecture.
1.1. Notion de dossier académique de l’étudiant
Pour mieux comprendre l’importance du dossier académique de l’étudiant dans le processus de gestion des universités, une appréhension initiale de ce qu’est le dossier académique nécessaire.
Le terme « dossier académique de l’étudiant » représente de manière littérale un ensemble d’informations relevant du domaine académique (universitaire plus précisément) d’un étudiant.
Selon le site officiel de l’université de Monash [1], un dossier académique est une transcription formelle de l’historique académique à l’université. Il contient toutes les unités d’enseignants étudiées ainsi que le niveau d’évolution dans chacune d’elles. Il s’agit alors d’un ensemble d’informations recueillies permettant d’analyser et d’évaluer l’évolution d’un étudiant au sein d’une université. Il doit alors transcrire fidèlement l’historique académique de l’étudiant dans l’université dans laquelle ce dernier se trouve. On peut ainsi dire que le dossier académique de l’étudiant est un outil parmi tant d’autres qui permet aux universités de suivre et de contrôler le cursus universitaire d’un étudiant.
1.2. Contenu d’un dossier académique
Après avoir défini ce qu’est un dossier académique, nous présenterons dans cette section son contenu.
PARTIE I | Chapitre 1 : Le dossier académique de l’étudiant
En considérant les définitions précédentes d’un dossier académique, nous pouvons dire que le dossier académique se compose en générale d’un certain nombre d’éléments :
Les informations concernant l’identité de l’étudiant ;
Une liste complète et détaillée de toutes les formations suivies et validées.
Pour chacun d’elles et selon le système en place dans l’université nous pouvons avoir d’autres informations comme :
o Les offres de formation (Intitulé, numéro d’identification, crédits, etc.) ;
o Les crédits validés ou non pour tous cours ;
o Les notes et/ou moyennes de chaque cours ainsi que les observations faites par les encadreurs (enseignants) ;
o Les informations relatives à la période où ces cours ont été suivi (année académique, semestres) ;
o Les attestations, les diplômes, les prix (si possible) ainsi que les dates d’obtentions de ces derniers.
Les informations relatives aux projets et stages académiques effectués ;
etc.
Selon chaque université, il faut noter que le dossier académique d’un étudiant peut contenir plus ou moins d’informations ou d’éléments que ceux cités plus haut.
1.3. Différentes utilisations du dossier académique
Considérant que le dossier académique est un document qui suit le parcours de l’étudiant, ou lorsque la formation est complète, confirme la qualification finale de ce dernier, il peut être utilisé pour postuler à des emplois ou pour des demandes de soutien pour des bourses d’études [1]. Vu l’importance des informations qu’il renferme il s’avère indispensable lors de l’admission ou du transfert d’un étudiant d’une université à un autre. En effet, pour passer d’une université ou d’une entité
universitaire à une autre, plusieurs pièces ou/et informations relatives à l’étudiant ainsi qu’à son cursus lui sont demandées. Dans le cas de l’université d’Abomey- Calavi par exemple, nous pouvons distinguer entre autres :
Une fiche de préinscription renfermant des informations sur l’identité (nom, prénom, sexe, nationalité, …) de l’étudiant ainsi que sur son inscription (filière, Spécialité, statut, …) ;
Une copie officielle du (des) diplôme(s) requis pour la formation ;
Des documents officiels justifiants son identité (Acte de naissance, Certificat de nationalité, Carte d’identité nationale, etc.) ;
Etc.
Les éléments cités ci-dessus font partie intégrante du dossier académique d’un étudiant. Compte tenu des informations qu’il renferme, le dossier académique de l’étudiant est d’une importance capitale dans la gestion académique des étudiants d’une université.
PARTIE I | Chapitre 2 : Quelques systèmes de gestion de données académiques de l’étudiant
C hapitre 2
:Quelques systèmes de gestion des données académiques de l’étudiant
A travers ce chapitre, nous avons procédé à la présentation de trois systèmes de gestion de données académiques afin d’avoir une vue un peu globale des différentes fonctionnalités qui y sont implémentées. Les trois systèmes d’informations (SI) étudiés sont :
Cocktail-ScolariX : Application open source édité par le consortium Cocktail ;
IsAcademia : Système de gestion académique mis en œuvre parl’Ecole Polytechnique Fédérale de Lausanne (EPFL) en partenariat avec Equinoxe MIS development ;
APOGEE (Application pour l’organisation et la gestion des enseignements et des étudiants) : Progiciel de gestion intégrée (PGI) développé par l’Agence de mutualisation des universités et établissements (AMUE).
Cette étude des systèmes existant nous permet de cibler les fonctionnalités indispensables à mettre en place pour le système de gestion de dossiers académique de l’étudiant dans le cadre de notre projet.
2.1. Etude du module SCOLARIX du PGI Cocktail
Tout au long de cette section, nous avons présenté le module SCOLARIX du PGI Cocktail afin de déduire les différentes fonctionnalités de l’application, ses atouts ainsi que ses insuffisances dans le domaine dans lequel il s’inscrit.
2.1.1. Généralités
ScolariX est une application Open Source de gestion globale de la scolarité conçue pour tout type d’établissement d’enseignement supérieur et permettant de gérer les inscriptions administratives des étudiants d’un établissement. En constante évolution, ScolariX propose une architecture 3-tiers, Java, HTML et Ajax. Il s’adapte aux établissements possédant des caractéristiques territoriales des TOM, aux particularités des écoles d’ingénieurs et a été aussi déployé en Afrique francophone. ScolariX et ses modules offrent liberté, souplesse et autonomie dans le respect des normes et des procédures d’interopérabilité [2].
2.1.2. Fonctionnalités
Cocktail-ScolariX permet de disposer d’un Système d'Information d’un référentiel éprouvé, évolutif et Open Source capable de supporter tous les besoins du plus petit au plus grand des établissements, et ce grâce à l’ensemble de ces modules à savoir [2] :
Référentiel des formations
Gestion des droits et privilèges
Inscriptions, ré-inscriptions, pré-inscriptions avec paiement en ligne
Gestion des examens, des notes, résultats et bilans
Gestion des inscriptions pédagogiques en ligne
Gestion des groupes pédagogiques : Cours, TD, TP, Projets, ...
Trombinoscope étudiant
Gestion des emplois du temps pédagogique
Infocentre Scolarité
Gestion prévisionnelle des charges d'enseignement
Coût de la maquette, liquidation des heures complémentaires
Edition carte étudiant : solution partenaire
PARTIE I | Chapitre 2 : Quelques systèmes de gestion de données académiques de l’étudiant
Et en option nous avons :
Gestion et suivi des anciens
Affichage web de l'Offre de formation cdm-fr/xml
Gestion des admissions/candidatures en ligne
Business Intelligence
Gestion des prises de Rendez-vous 2.2. Etude du SI Is-Academia
Compte tenu du manque de documentations publiques sur ce système d’information, nous avons tiré la grande majorité des informations de cette section d’un document [3] de l’EPFL présentant la couverture fonctionnelle de IS- Academia.
2.2.1. Généralités
Dans le but de mieux gérer ses activités, l’EPFL en collaboration avec la structure « Equinoxe MIS development » a conçu un logiciel appelé IS-Academia.
IS-Academia est un système d’information complet permettant à tous les utilisateurs d’avoir accès, chaque fois que cela est souhaité, à l’ensemble des informations qui leur est nécessaire.
Pour couvrir tous les types d’enseignement présents dans une institution, IS- Academia est conçu comme un seul système d’information pour assurer aussi bien la gestion administrative que la gestion académique. Il est multi-écoles ; multi- langues ; adaptable à toutes les spécificités, qu’elles soient fonctionnelles ou visuelles. Il est accessible par Internet, utilisant indifféremment les environnements bureautiques MS-Office ou OpenOffice ; dédié à vos collaborateurs administratifs et à votre corps enseignant, mais également à vos étudiants ou prospects et enfin, il ne nécessite aucune installation particulière au niveau des postes de travail, autre qu’un navigateur Internet.
La figure 2.1 ci-dessous présente une vue d’ensemble de la couverture fonctionnelle du SI, sous la forme d’une structure d’Ecole et de ses différentes unités organisationnelles (en bleu).
Les piliers latéraux (en rouge), présentent les applications dites transversales. Ces applications sont utilisées ou accessibles par l’ensemble des autres modules.
Les principales fonctionnalités proposées aux étudiants sont représentées dans les blocs inférieurs (en bleu-gris).
Figure 2.1 : Couverture fonctionnelle du logiciel IS-Academia (Source : [3])
2.2.2. Fonctionnalités
Le système d’information de l’EPFL est composé d’un ensemble de fonctionnalités ou de modules qui lui permettent d’assurer efficacement son rôle.
PARTIE I | Chapitre 2 : Quelques systèmes de gestion de données académiques de l’étudiant
Les principaux modules et principes conceptuels de ce logiciel se distinguent comme suit :
La gestion des personnes
La gestion des inscriptions
La gestion de l’enseignement
La définition des cursus de formation
Les plans d’études et les inscriptions aux cours
Le contrôle des études
Les plans d’examen et le suivi des épreuves
La gestion de la charge des enseignants : Ce module permet de gérer l’allocation de la charge des enseignants :
o Attribution des matières enseignées aux enseignants ;
o Prise en compte des activités externes à l’enseignement (recherche, mandats, etc.) pour un suivi de la répartition du temps dû et une prise en compte dans une comptabilité analytique.
Les horaires des cours et les réservations ponctuelles
La gestion des horaires des examens : il s’agit des fonctionnalités suivantes :
o Gestion des horaires des examens en tenant compte de l’occupation des enseignants, des experts, des étudiants et des salles. Les occupations définies au travers des horaires des cours et des réservations ponctuelles sont prises en compte dans le calcul des collisions ;
o Gestion assistée des listes de passage aux épreuves orales par les délégués de classe ;
o Diffusion de l’horaire des examens par support papier et au travers du Web. Les horaires peuvent être produits pour un étudiant (en
fonction des inscriptions aux examens et des listes de passage aux oraux), par classe d’étudiant, par enseignant, par expert et par salle.
La facturation et le suivi financier
La gestion des contacts
La bourse aux stages : ce module gère toutes les étapes liées à la définition et au suivi des stages d’études.
L’envoi de courriels
L’extracteur de données : comme son nom l’indique, ce module permet de sélectionner une partie de la population de la base de données de IS- Academia et d’y appliquer une série de filtre afin d’affiner la sélection. Le résultat issu de l’extracteur constitue la donnée d’entrée pour un certain nombre de fonctionnalités telles que :
o Génération et envoi d’e-mail avec le module Emailing ; o Facturation en masse (création de lots de factures) ; o Impression de bulletins ;
o Inscriptions aux plans d’études et d’examens.
L’interface avec l’environnement statistique R : il s’agit d’une interface permettant la communication entre le logiciel R et IS-Academia.
Ce logiciel, grâce à son interface web et son portail sécurisé, peut être ouvert à l’ensemble des catégories de personnes directement ou indirectement concernées par la gestion académique de l’Ecole ; il s’agit :
Des futurs étudiants, des étudiants et des diplômés de l’école ;
Des enseignants ;
Des administrateurs des facultés, des sections et des filières d’enseignement ;
Des personnes en charge de la gestion centralisée des étudiants ;
De la direction des écoles et facultés ;
Des partenaires externes.
PARTIE I | Chapitre 2 : Quelques systèmes de gestion de données académiques de l’étudiant
2.3. Etude du PGI APOGEE
Cette section présente l’ensemble des informations que nous avons pu recueillies concernant le Progiciel de Gestion Intégré APOGEE, Application POur la Gestion des Etudiants et des Enseignements, et permettant d’avoir une vue d’ensemble des fonctionnalités du logiciel. Les documentations trouvées sur le logiciel n’étant disponibles que pour les utilisateurs de l’application, nous avons basé notre étude sur les données du document intitulé « Introduction à la consultation du dossier étudiant » [4], réalisé pour une formation sur comment utiliser le logiciel APOGEE.
APOGEE est un logiciel national élaboré par l'AMUE (Agence de Modernisation des Universités et Etablissements) qui est installé dans environ 90 universités ou établissements.
Son objectif principal est d'assurer la gestion du dossier étudiant qui va de l'inscription administrative jusqu'aux notes en passant par les stages et les thèses.
Le produit est constitué de domaines (ou modules) qui peuvent être mis en place progressivement selon les besoins de chaque établissement. Ses principaux domaines sont :
IA : Inscription Administrative – DE : Dossier Etudiant
Ces deux domaines permettent d'assurer les inscriptions administratives à l'Université. Les principaux traitements sont :
o Gestion du dossier administratif (Etat-Civil, historique, …) ; o Edition de la carte d'étudiant ;
o Calcul des droits universitaires ;
o Transmission des informations aux organismes extérieurs (MEN, Sécu, Mutuelles, etc.) ;
o Gestion des paiements et remboursements.
IP : Inscription pédagogique – SE : Structure des Enseignements – GRP : groupes
Ces 3 domaines permettent d'assurer une partie de la gestion pédagogique.
Les principaux traitements sont :
o Définition des éléments pédagogiques capitalisables ou non ; o Inscription pédagogique des étudiants (choix, options, etc.) ; o Constitution de groupes pour usage divers.
MCC : Modalités de contrôle des connaissances – RE : gestion des résultats et des notes
Ces 2 domaines permettent d'assurer la gestion des épreuves et le calcul des notes. Les principaux traitements sont :
o Définition des épreuves d'examen
o Définition des paramètres liés aux sessions
o Définition des règles de calcul de moyennes et des résultats.
o Edition des P.V. et relevés de notes.
EPR : Epreuves
Le planning des examens, la gestion des calendriers, les convocations des étudiants et des surveillants, les listes d’émargement et les PV d’examens sont gérés dans ce module.
Deuxième Partie
PARTIE II MATERIELS ET METHODES
C hapitre 3
:Méthodologie de conception
A travers ce chapitre, nous avons exposé la méthodologie qui nous a permis de mettre en œuvre notre plateforme. Le travail effectué dans cette section nous a permis d’organiser par ordre de priorité et d’exécution les différentes étapes de la conception de la plateforme de gestion de dossier d’étudiant. Après avoir exposé la méthodologie globale de conception adoptée et les besoins du système, nous avons présenté l’architecture globale choisie pour l’implémentation de notre plateforme.
3.1. Présentation de la méthodologie de conception adoptée
Dans l’optique d’atteindre l’objectif principal du présent travail, une méthodologie de conception appropriée a été adoptée et suivie : il s’agit de la méthode du Cycle en V (processus en cascade). Ce processus de développement d’applications est illustré par la figure 3.1.
Figure 3.1 : Schéma de la méthode du Cycle en V
Le Cycle en V est un paradigme du développement informatique, qui décrit les étapes essentielles du développement d’un logiciel, le cycle de vie du projet.
PARTIE II | Chapitre 3 : Méthodologie de conception
Il est représenté par un V dont la branche descendante contient toutes les étapes de la conception du projet, et la branche montante toutes les étapes de tests du projet. La pointe du V, quant à elle, représente la réalisation concrète du projet : le codage. Aussi les étapes de la branche montante doivent renvoyer de l’information sur les phases vis-à-vis lorsque des défauts sont détectés, afin d’améliorer le logiciel.
Chacune des étapes de cette méthode a été caractérisée par des activités précises menées en vue d’aboutir à notre plateforme finale :
L’analyse des besoins : au cours de cette étape, nous avons conduit des entretiens avec le registraire et le Directeur Adjoint de l’EPAC qui nous a permis d’avoir une idée des besoins réels des futurs utilisateurs de la plateforme ;
La spécification : à travers cette étape, nous avons procédé à une analyse fonctionnelle des besoins retenus pour le système à mettre en œuvre afin d’identifier et de valider les fonctionnalités essentielles pour la plateforme ;
La conception préliminaire et détaillée : cette étape a consisté à la modélisation1 des différentes fonctionnalités et interactions du notre plateforme ;
Le codage : au cours de cette étape, nous avons conçu, grâce aux outils de développement d’applications, la plateforme web pour la gestion de dossier d’étudiant ;
Les tests : ont permis de nous assurer que chaque module fonctionnel de la plate-forme répond aux spécifications fonctionnelles prédéfinies.
1 La modélisation de plate-forme est détaillée en profondeur dans le chapitre 4.
3.2. Définition des besoins du système
Après la présentation de la méthodologie de conception adoptée pour la mise en œuvre de notre plateforme, il est temps à présent de se focaliser sur une analyse des besoins de notre application de gestion de dossier d’étudiant. Il sera question de définir les besoins fonctionnels et non fonctionnels auxquels doit répondre la plateforme à mettre en œuvre.
3.2.1. Besoins fonctionnels du système
Les besoins fonctionnels expriment une action que doit effectuer le système en réponse à une demande [5]. Ils sont donc liés aux différentes tâches à réaliser et doivent être le plus transparent possible pour les utilisateurs.
Suite aux entretiens menés avec quelques membres de l’administration de l’EPAC et du rectorat annexe de l’UAC, nous sommes arrivés à identifier leurs principaux besoins en ce qui concerne la gestion des dossiers académique des étudiants. La liste suivante récapitule les différents points indispensables à prendre en compte afin de proposer une solution technique adéquate :
● Disposer d’un répertoire à jour des données académiques des étudiants ;
● Alléger la procédure d’obtention des pièces académiques à travers un système de traitement des requêtes administratives ;
● Mettre en place un module pour la gestion des offres de formations et des notes des étudiants au niveau de chaque département afin de disposer de données académiques pour assurer une mise à jour régulière des dossiers ;
● Suivre de façon continue, à travers les modules du système, les mouvements et modifications effectués sur les dossiers des étudiants afin d’assurer sa traçabilité ;
● Permettre, grâce aux configurations du système, l’accès au dossier d’étudiant à d’autres utilisateurs tels que les enseignants, les étudiants eux- mêmes (en lecture seule) ;
PARTIE II | Chapitre 3 : Méthodologie de conception
● Mettre en place un système de gestion des archives afin de résoudre le problème de perte (au fil des années) des documents académiques des étudiants ;
● Disposer d’un canal permettant l’échange et le partage d’informations au sein de l’université.
A ces points vient s’ajouter l’interopérabilité du système de gestion des dossiers académiques avec d’autres systèmes tiers tels que le système de gestion de la bibliothèque, le système de gestion des identités, etc.
3.2.2. Besoins non fonctionnels
Les besoins non fonctionnels sont des exigences qui ne concernent pas spécifiquement le comportement du système mais plutôt identifient des contraintes internes et externes du système. Ce sont des contraintes à prendre en compte lors de la mise en œuvre de la solution proposée à la problématique de base. Il en existe de différentes sortes [5] :
Les besoins d’utilisabilité
Il s’agit des aspects généraux de l’interface utilisateur. Ainsi on peut parler de l’apprenabilité, la flexibilité et la robustesse. L’apprenabilité, c’est la facilité avec laquelle l’utilisateur peut prendre en main le logiciel et découvrir ses fonctionnalités. La flexibilité consiste en la capacité du système à offrir des modes d’interactions multiples pour répondre aux besoins, préférences et expérience de l’utilisation et s’adapter au contexte (adaptabilité). La robustesse, quant à elle, est le niveau de satisfaction dans la réalisation des tâches permises par le système [6].
Les besoins de performance
Ces besoins décrivent les performances (possibilités optimales) d’exécutions du système, généralement en terme de temps de réponse.
Les besoins de disponibilités ou de fiabilité
Il s’agit des critères à prendre en compte afin de définir le niveau de disponibilité de l’application. Pour les applications critiques, l’expression de ces besoins est d’une importance capitale et doit alors être explicitement définie. Par exemple nous pouvons dire qu’une application web est disponible tous les jours de la semaine sauf les dimanches pour cause de maintenance du système.
Les besoins de sécurité
Les besoins de sécurité peuvent entre autres définir les niveaux d’accès possibles pour les utilisateurs du système et les systèmes externes. Ils permettent au client de spécifier si possible les différents moyens et méthodes sécuritaires (cryptographie, algorithmes ou systèmes divers) à utiliser pour l’application.
Les besoins matériels
Ces besoins définissent les configurations matérielles minimales nécessaires au fonctionnement du système.
Les besoins de déploiement
Il s’agit ici de la façon dont l’application sera livrée à l’utilisateur final.
L’application peut être sous forme d’un exécutable que l’on pourrait télécharger et installer ou directement accessible en ligne donc hébergée sur un serveur distant etc. Ces besoins décrivent la forme ou l’état sous lequel doit se présenter l’application finale (la solution).
Notre application doit nécessairement assurer un certain nombre de ces besoins : o L’extensibilité : l’application qui sera mise en place doit être
extensible, autrement dit doit permettre dans le futur d’ajouter ou de modifier certaines fonctionnalités.
o Les interfaces : l’application doit respecter les principes des Interfaces Homme-Machine (IHM) tels que l’ergonomie et la fiabilité [6].
PARTIE II | Chapitre 3 : Méthodologie de conception
o La convivialité : il faudra mettre un accent particulier sur la facilité dans l’utilisation même par des profanes.
o La performance : le temps d’exécution de toute requête doit être minimisé le plus possible afin d’assurer une certaine rapidité dans l’affichage des résultats des requêtes.
o La disponibilité : le système doit pouvoir être disponible tout le temps sauf pendant les heures de maintenances.
o La sécurité : la protection des informations personnelles étant un point important nous devons doter notre système de sécurité solide. Ainsi il sera mis en place un système de protection d’URL, et de gestion de rôles et de permissions, en plus du système de sécurité du réseau l’application sera disponible.
o L’environnement matériel : lors de la mise en production de notre application, nous aurons besoin de matériels tels qu’un serveur web (avec serveur de base de données intégré) remplissant les critères de l’environnement de développement, d’un espace de stockage ainsi que d’un réseaux intranet et une connexion internet fiable.
3.3. Solution d’amélioration du présent dossier
Suite aux besoins précédemment énoncés, nous avons analysé et proposé une solution basée sur les caractéristiques et les fonctionnalités générales des systèmes d’informations des établissements d’enseignements supérieurs et plus précisément celles des plateformes de gestion de dossier d’étudiant.
3.3.1. Vue globale
Pour une meilleure gestion des dossiers académiques des étudiants, nous proposons de mettre en place un système de gestion centralisé des informations des étudiants. Ainsi, toutes les données des étudiants seront stockées sur un serveur principal. Ce dernier aura pour objectif d’échanger ses données pour être
traitées, à travers un réseau de communication constitué de nombreux sites de niveaux inférieurs que représentent les universités et entités. Afin de permettre le traitement de ces données par les utilisateurs sur système, une plateforme web sera mise en place. Elle disposera de nombreuses fonctionnalités basées sur les besoins formulés précédemment afin d’améliorer la gestion académique d’une université tout en mettant à la disposition de tous une version numérique et à jour du dossier académique de l’étudiant.
3.3.2. Spécifications fonctionnelles des besoins
Notre projet consiste en la mise en œuvre d’une plateforme de gestion des dossiers académiques des étudiants qui aura pour objectif principal de les rendre plus accessibles. Cette plateforme permettra aux étudiants de consulter et de suivre leur dossier en temps réel partout où ils se trouvent et aux autorités d’automatiser certaines tâches en vue de la gestion académique et de l’archivage des données académiques des étudiants.
Une analyse fonctionnelle des besoins de notre système nous permet de dégager un certain nombre de fonctionnalités que nous avons pu regrouper en modules.
Le module de gestion des données académiques
Ce module constitue l'élément central de notre système car il permettra de traiter les données de l’étudiant afin d’assurer une mise à jour régulière des dossiers académiques et leur archivage. Pour cela nous allons implémenter les fonctionnalités telles que :
o la gestion des offres de formations et de notes ; o la gestion des projets académiques ;
o la gestion des médias (diplôme, attestation, bulletin, fiche de préinscription, ...) ;
PARTIE II | Chapitre 3 : Méthodologie de conception
o la gestion des données de la bibliothèque et d’autres services disponibles au sein de l’université.
L’ensemble de ces fonctionnalités interagissent entre elles pour permettre d’atteindre l’objectif visé par ce module.
Le module concernant la gestion d’entité
Le module de gestion d’entité est un ensemble de fonctionnalités permettant d’automatiser certaines tâches au sein d’une entité. Il s’agit des requêtes d’ordre académique dont les demandes de retrait de certains pièces académiques comme le bulletin, les attestations ainsi que des fonctionnalités permettant de gérer les départements et options. Les fonctionnalités regroupées dans ce module sont :
o la gestion d’une université à savoir la création d’un compte universitaire, la modification des informations de l’université, la suppression ou l’archivage des informations de l’université. Aussi nous pouvons noter l’affichage du profil d’une université ainsi que la liste de l’ensemble des universités de la plateforme.
o la gestion d’une entité : Il s’agit ici des mêmes fonctionnalités que la gestion d’une université. Dans certains cas (universités privées) les deux (gestion d’une université et d’une entité) module de gestion peuvent être confondus.
o la gestion des départements (filières) et options d’une universités (entités).
o la gestion des requêtes administratives au sein d’une université.
Le module de gestion des utilisateurs
Il s’agit ici d’un ensemble de fonctionnalités permettant de gérer les différentes actions propres aux utilisateurs de notre système. En effet, nous pouvons distinguer la gestion des comptes utilisateurs ainsi que la gestion de l’accès au système.
La gestion des comptes nous permet d’avoir des statistiques sur l’ensemble des utilisateurs du système. Nous pourrons ainsi gérer la création, l’activation d’un compte ainsi que le traitement des informations basiques du compte. Ainsi, nous pouvons énumérer les actions suivantes :
o la création d’un compte utilisateur (étudiant, enseignant, administrateur) ;
o la validation d’un compte étudiant ;
o la désactivation ou non de la visibilité d’un compte;
o la mise à jour des informations d’un compte (mot de passe, identifiant, email,...) ;
o la consultation du profil d’un utilisateur ;
o la recherche d’un utilisateur grâce à des outils de recherches ;
o l’affichage des statistiques (Nombre de comptes actifs, visibles, d’étudiants, etc.).
La gestion de l’accès à la plateforme permet de définir les différents niveaux d’accès du système. En effet, ce module permettra de créer des rôles pour les utilisateurs du système et de leurs donner des permissions. Ainsi chaque utilisateur pourra, selon les droits ou permissions de son rôle, accéder à certaines interfaces et bénéficier de certaines fonctionnalités
Le module de gestion des forums
Dans le souci de faciliter l’échange et le partage d’informations (résolution de problèmes, partage de connaissance, aide) entre les utilisateurs du système et plus particulièrement entre les étudiants de la plateforme, nous avons décidé de mettre en place un espace de discussion publique tel qu’un système de gestion de forums.
A tous ces modules vient s’ajouter d’autres fonctionnalités qui apportent un plus à notre plateforme et permettent d’accroître le niveau de convivialité et de performance du système. Il s’agit donc :
PARTIE II | Chapitre 3 : Méthodologie de conception
o d’un système de notifications afin de prévenir chaque utilisateur des dernières modifications ou activités sur la plateforme ;
o d’un module de gestion des historiques pour retracer les actions ou opérations successives réalisées au cours d’une session, ceci afin d’en assurer la traçabilité à toutes fins utiles.
Pour notre projet de mémoire actuel, la plateforme se limitera aux fonctionnalités permettant la gestion interne d’une entité. Les opérations concernant la gestion de plusieurs universités (ou d’entités) ainsi que les modules additionnels à savoir la gestion des notifications et de l’historique ne seront pas pris en compte.
3.3.3. Conception architecturale de notre solution
Afin de réussir la phase d’implémentation de notre solution, nous avons choisi une architecture de conception parmi les deux architectures suivantes :
● L’architecture “client-serveur”
● L’architecture “n-tiers”
L’architecture “client-serveur”, illustrée par la figure 3.2, fait appel à un mode de communication à travers un réseau entre plusieurs clients et serveurs. Les applications accèdent aux données à travers les réseaux sur des machines serveurs de données disposant d’un Système de Gestion des Bases de Données (SGBD).
Le dialogue entre le client et le serveur se résume à l’envoi de requêtes et aux données en réponses. On distingue donc deux parties :
1. Le client
2. Le serveur qui se contente de répondre aux requêtes du client.
Figure 3.2 : Architecture « Client-serveur »
Sur la base de l’architecture « client-serveur », l’architecture « 4-tiers », illustrée par la figure 3.3, permet de séparer la couche de présentation de la couche applicative (métier). On a ainsi :
1. La couche présentation ou encore interface utilisateur (PC client). Il s’agit de la partie de l’application visible, qui interagit avec les utilisateurs : on parle d’Interface Homme-Machine (IHM).
2. La couche applicative ou métier (Serveur d’application Web) correspond à la partie fonctionnelle de l’application. Elle implémente la “logique” et décrit les opérations que l’application opère sur les données en fonction des requêtes des utilisateurs, effectuées au travers de la couche présentation.
3. Cette couche fait partie intégrante du framework Laravel, présenté à la section 3.4, que nous avons utilisé. Il s’agit d’un composant web composé d’un créateur de requêtes SQL (Query Builder) et d’un ORM (Eloquent ORM). Cette couche est une passerelle entre le serveur d’application et le serveur de base de données. Son rôle consiste à générer des requêtes SQL selon la fonction appelée par le serveur d’application et d’établir une connexion avec le serveur de données. En réponse, elle lui renvoie les données récupérées du serveur de base de données.
PARTIE II | Chapitre 3 : Méthodologie de conception
4. La couche données (serveur de base de données) s’occupe de l’accès aux données, des données persistantes au sein d’un SGBD, propres au système ou gérées par un autre système.
Figure 3.3 : Architecture « 4-tiers »
L’architecture « 4-tiers » ci-dessus présentée, dérive de l’architecture « 3-tiers » et qualifie la distribution d’applications entre de multiples services et non la multiplication des niveaux de service : les trois niveaux d’abstractions d’une application sont toujours pris en compte.
L’architecture “client-serveur” oblige l’installation de l’application sur tous les postes clients. Ainsi les clients sont fortement sollicités et supportent donc tous les traitements applicatifs ; ce qui rend complexe et contraignant les mises à jour qui devront être régulières. Cependant, avec l’architecture « 4-tiers » l’installation de l’application se fera une seule fois, ce qui rendrait plus facile les mises à jour de notre solution. Les clients sont donc plus légers et la sécurité des données est améliorée en ce sens que les liens entre le client, l’application et les données sont supprimés. Ainsi, compte tenu de ses avantages nous avons donc opté pour l’architecture « 4-tiers » pour l’implémentation de notre solution.
3.3.4. Fonctionnement globale
Dans cette section, nous avons parlé du fonctionnement global de notre solution. Le fonctionnement de notre plateforme ressemble au fonctionnement de base des applications web.
Les utilisateurs se connectent au serveur d’application par le biais d’internet ou d’un réseau intranet. Notre solution fonctionne de manière que même à défaut d’une connexion internet, l’on puisse se connecter à notre serveur d’application afin que les différents services de notre système soient toujours accessibles.
L’application devra être déployée sur un serveur local (propre à l’entité universitaire) ce qui permettra à tout individu connecté à l’intranet (réseau local) et ayant les droits requis d’accéder à notre plateforme. Le serveur sur lequel sera déployé notre solution sera configuré de sorte qu’il puisse aussi être accessible depuis Internet.
L’échange entre les deux entités (client et application) se fait grâce à des requêtes HTTP que le client envoie. Ces requêtes sont reçues et traitées par notre serveur d’application qui à son tour envoie une réponse au client, auteur des requêtes. Par ailleurs, lors du traitement des requêtes du client, le serveur d’application transforme au besoin ces requêtes en requêtes SQL qui parviennent au serveur de données. Ce dernier les exécute et envoie les résultats au serveur d’application afin que celui-ci puisse transmettre une réponse au format adéquat (HTML, CSS, JavaScript, JSON, XML, etc.) pour le client. Il est aussi à noter qu’à chaque connexion à l’application, l’utilisateur doit toujours passer par un service d’authentification afin de déterminer si ce dernier dispose des droits requis pour accéder à la plateforme.
PARTIE II | Chapitre 4 : Architecture du système
Chapitre 4 : Architecture du système
Dans ce chapitre nous présentons la méthode de conception choisie ainsi que la modélisation de la plateforme réalisée à travers les diagrammes de cas d’utilisation, de séquence et de classe.
4.1. Méthode de conception
Plusieurs approches existent dans le cadre du développement des systèmes logiciels. Nous pouvons distinguer entre autre l’approche objet et celle fonctionnelle. Cette dernière consiste à définir les fonctions des composantes d’un système et leurs relations fonctionnelles. Plus précisément, elle permet une conception plus détaillée en partant d’un niveau haut vers les niveaux les plus bas.
Par ailleurs, l’approche objet est incontournable dans le cadre du développement de systèmes logiciels complexes, capables de suivre les évolutions incessantes des technologies et des besoins applicatifs. Cette démarche se fonde sur des langages de modélisation, qui permettent de s’affranchir des contraintes des langages d’implémentation [7]. Afin de visualiser le système et d’identifier les entités de notre système ainsi que les dépendances logiques entre elles, nous allons passer dans la section suivante à la modélisation des données de notre solution en utilisant l’approche objet.
Le langage choisi pour cette méthode est le langage UML. UML est devenu le langage standard de modélisation des systèmes d’informations. C’est un moyen d'exprimer des modèles objet en faisant abstraction de leur implémentation, c'est- à-dire que le modèle fourni par UML est valable pour n'importe quel langage de programmation. UML est un langage qui s'appuie sur un méta modèle, un modèle de plus haut niveau qui définit les éléments d'UML (les concepts utilisables) et leur sémantique (leur signification et leur mode d'utilisation).
Le méta modèle permet de se placer à un niveau d'abstraction supérieur car il est étudié pour être plus générique que le modèle qu'il permet de construire.Le méta-modèle d'UML en fait un langage formel possédant les caractéristiques suivantes :
Un langage sans ambigüités
Un langage universel pouvant servir de support pour tout langage orienté objet
Un moyen de définir la structure d'un programme
Une représentation visuelle permettant la communication entre les acteurs d'un même projet
Une notation graphique simple, compréhensible même par des non informaticiens
Le méta modèle permet de donner des bases solides et rigoureuses à ce langage graphique, dont les représentations graphiques ne sont là que pour véhiculer des concepts de réalisation.UML offre une manière élégante de représenter le système selon différentes vues complémentaires grâce aux diagrammes.
4.2. Modélisation du système
Le méta modèle UML fournit une panoplie d'outils permettant de représenter l'ensemble des éléments du monde objet (classes, objets, ...) ainsi que les liens qui les relient. Toutefois, étant donné qu'une seule représentation est trop subjective, UML fournit un moyen astucieux permettant de représenter diverses projections d'une même représentation grâce aux vues.
Une vue est constituée d'un ou plusieurs diagrammes. On distingue deux types de vues :
● Les vues statiques, c'est-à-dire représentant le système physiquement à travers certains diagrammes dont :
○ Les diagrammes d'objets
PARTIE II | Chapitre 4 : Architecture du système
○ Les diagrammes de classes
○ Les diagrammes de cas d'utilisation
○ Les diagrammes de composants
○ Les diagrammes de déploiement
● Les vues dynamiques, montrant le fonctionnement du système. Nous pouvons distinguer entre autres :
○ Les diagrammes de séquence
○ Les diagrammes de collaboration
○ Les diagrammes d'états-transitions
○ Les diagrammes d'activités
Pour le compte de notre projet, nous allons travailler avec :
Le diagramme des cas d’utilisation
Les diagrammes de séquences
Le diagramme des classes
Le logiciel Visual Paradigm (version 13.1) nous a permis de réaliser les différents diagrammes cités plus haut.
4.2.1. Les diagrammes de cas d’utilisations
Après analyse du cahier des charges, nous allons présenter de manière détaillée comment les exigences fonctionnelles seront implémentées, et donc permettre le développement de notre solution. Dans un premier temps nous allons identifier les acteurs qui interagissent avec le système, ensuite nous présenterons à travers des diagrammes les principaux cas d'utilisations du système et enfin nous exposerons les détails des fonctionnalités du système.
4.2.1.1. Acteurs du système
Cette section nous permettra d’identifier les différents acteurs du notre système. Par définition, un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement
avec le système étudié. Un acteur peut consulter et/ou modifier directement l’état du système, en émettant et/ou en recevant des messages susceptibles d’être porteurs de données [7].
Ainsi, pour le compte de notre application, nous pouvons distinguer les acteurs humains suivants :
L’étudiant
L’enseignant
Le chef de département : C’est le responsable du fonctionnement pédagogique et administratif du département.
L’administrateur (membre du personnel de l’université) : il s’agit d’un utilisateur possédant des droits ou permissions lui permettant de faire un certain nombre d’actions sur le système qu’un simple utilisateur ne pourrait faire.
Le super-utilisateur : c’est celui qui est à la charge de tout le système. Il dispose de tous les droits.
Outre ces acteurs humains, il faudra également prendre en compte les systèmes tiers qui sont connectés à notre plateforme. Il faut noter le système de gestion de la bibliothèque qui interagit avec la plateforme afin d’échanger des données en rapport avec l’identité des étudiants du système, le site internet de l’EPAC par lequel on peut se connecter directement à notre système lorsque certaines conditions sont remplies. Le tableau 1 présente les rôles des différents acteurs (utilisateurs) du système.
