Ilovepdf Merged

République Algérienne Démocratique et Populaire
Ministère de L'Enseignement Supérieur et de la Recherche Scientifique

Université Larbi Ben M'hidi – Oum El Bouaghi
Faculté des Sciences Exactes et des Sciences de la Nature et de la Vie
Département de Mathématiques et d’Informatique
Pour l'obtention du diplôme de Master en Informatique

Option : Architectures Distribuées
Thème
Application web pour la gestion du

département de Mathématique et
d’Informatique
Présenté par :
Melle Zaidi Amel
Soutenu le 13/06/2018 devant le jury constitué de :

Dr. Bourouis Abd-Elhabib Université L'arbi ben M'hidi Président
Dr. Laboudi Zakaria Université L'arbi ben M'hidi Encadreur
Mme. Saighi Asma Université L'arbi ben M’hidi Examinatrice
Année universitaire : 2017– 2018

Remerciements
Louange à Allah, de me donner la force et la patience de survivre, ainsi que le

courage de surmonter toutes les difficultés pour atteindre la fin de mes études et
compléter ce modeste travail.
Ainsi j’adresse mes plus sincères remerciements et ma profonde reconnaissance à

Dr. Laboudi Zakaria mon directeur de mémoire de Master pour la pertinence de
ses remarques et sa patience pendant ce travail, sa manière de diriger qui fut pour
moi une grande source d’inspiration et de motivation, il a su m’encourager et me
permettre de travailler dans une ambiance scientifique exceptionnelle
J'exprime toute ma reconnaissance à Monsieur Dr. Bourouis Abd-Elhabib pour

avoir bien voulu accepter de présider le jury de ce mémoire.
Je tiens à remercier Mme. Saighi Asma d'avoir accepté d'évaluer mon mémoire.
Votre participation à mon jury de soutenance a été un grand honneur pour moi.
Enfin, Je remercie tous mes enseignants du début à la fin de mes études, Merci
pour toute l'équipe pédagogique de l'Université de Larbi Ben M’hidi OUM EL
BOUAGHI, et je remercie toutes les personnes qui m’ont aidée, de près ou de loin
pour la réalisation de ce travail en particulier
Dédicaces
Je dédie ce mémoire à :
Ma mère, qui a œuvré pour ma réussite, par son soutien, tous les sacrifices
consentis et ses précieux conseils, pour toute son assistance, reçois
à travers ce travail modeste, l'expression
de mon éternelle gratitude.
Mon père, qui peut être fier et trouver ici le résultat de longues années de sacrifices
et de privations pour m'aider à avancer dans la vie. Merci pour
les valeurs nobles, l'éducation et le soutient
permanent venu de toi.
Mes sœurs et mes frères, Je mentionne particulièrement Karima qui n'ont cessé
d'être pour moi des exemples de persévérance, de
courage et de générosité.
Mes amis, pour leurs encouragements permanents, et leur soutien moral.
Et à tous ceux qui ont contribué de près ou de loin pour que ce projet soit possible,
je vous dis merci.
TABLE DES MATIÈRES
Table des Matières .................................................................................. i
Table des figures ................................................................................... vi
Liste des tableaux .............................................................................. viii
Résumé ................................................................................................... 1
Introduction Générale ............................................................................ 2
Chapitre 1
1. Introduction ........................................................................................ 4
2. Le langage de modélisation UML ..................................................... 4
3. Historique d’UML ............................................................................. 4
4. Les diagrammes d’UML .................................................................... 5
4.1. Les diagrammes de structure (ou encore statique) ...................... 5
4.1.1. Le diagramme de classes ....................................................... 6
4.1.2. Le diagramme d’objets........................................................... 6
4.1.5. Le diagramme des paquets ..................................................... 7
4.2. Les diagrammes de comportement .............................................. 8
4.2.1. Le diagramme des cas d’utilisation ....................................... 8
4.2.2. Le diagramme d’états-transitions........................................... 8
4.2.3. Le diagramme d’activité ........................................................ 9
4.3. Les diagrammes d’interaction (ou dynamique) ........................... 9
4.3.1. Le diagramme de séquence .................................................... 9
4.3.2. Le diagramme de communication........................................ 10
4.3.3. Le diagramme global d’interaction ...................................... 11
4.3.4. Le diagramme de temps ....................................................... 11
5. Evaluation d’UML ........................................................................... 12
i
5.1. Les avantages du langage UML ................................................ 12
5.2. Les inconvénients du langage UML .......................................... 12
6. Conclusion ....................................................................................... 13
Chapitre 2
1. Introduction ...................................................................................... 15
2. Le système de gestion actuel ........................................................... 15
3. Propositions pour l’amélioration du système actuel ....................... 16
4. Gestion de notre projet .................................................................... 17
5. Analyse préliminaire des besoins .................................................... 18
5.1. Définition des acteurs et capture des besoins fonctionnels ....... 18
5.2. Les besoins non fonctionnels .................................................... 19
5.3. Diagramme des cas d’utilisation global…..…………………..20
5.4. Architecture générale du nouvel système…………..…………20
6. Analyse détaillé des besoins fonctionnels ....................................... 21
6.1. Le cas d’utilisation « Authentification » ................................... 22
6.2. Le cas d’utilisation « déconnexion» .......................................... 23
6.3. Le cas d’utilisation « gérer affectations matière-enseignant» ... 24
6.4. Le cas d’utilisation « importer données»................................... 25
6.5. Le cas d’utilisation « Exporter données» .................................. 27
6.6. Le cas d’utilisation «exporter Notes / Absences» ..................... 28
6.7. Le cas d’utilisation « Saisir notes» ............................................ 29
6.8. Le cas d’utilisation « Gérer absences» ...................................... 30
6.9. Le cas d’utilisation « consulter notes / absences» ..................... 31
7.Phase de conception……………………………………………….36
7.1. Diagramme de classes-entités .................................................... 32
7.2. Diagramme de classes-métiers .................................................. 33
ii
7.2.1. Gestion des sessions ......................................................... 33
7.2.2. Gestion des traitements assurés par l’administrateur ....... 35
7.2.3.Gestion des traitements assurés par le chef de spécialité .. 36
7.2.4. Gestion des traitements assurés par l’enseignant……… 37
7.2.5. Gestion des traitements assurés par l’étudiant…...….….39
8.Conclusion……………………………… …………………..…..41
Chapitre 3
1. Introduction ...................................................................................... 43
2. Outils, langages et technologies de développement ..................... 43
2.1. L’environnement de développement web Dreamweaver .......... 43
2.2. Le langage XML ........................................................................ 44
2.3. Le langage PHP.......................................................................... 44
2.4. Le langage JavaScript ................................................................ 45
2.5. Le pack WAMP ......................................................................... 46
2.6. Le langage CSS .......................................................................... 46
2.7. Le langage HTML ..................................................................... 46
2.8. La technique AJAX ................................................................... 47
2.9. La bibliothèque JQuery .............................................................. 48
3. Les fonctionnalités de l’application réalisée ................................ 48
3.1. La page d’accueil ....................................................................... 48
3.2. Les fonctionnalités exécutées en mode administrateur ............. 50
3.2.1. Importation des données ......................................................... 51
3.2.2. Exportation des données ......................................................... 51
3.2.3. Gestion des Affectations ......................................................... 52
3.2.4. Gestion des comptes-utilisateurs ............................................ 53
3.3. Les fonctionnalités exécutées par les chefs de spécialité .......... 53
iii
3.4. Les fonctionnalités exécutées par les enseignants ..................... 54
3.4.1. Gestion des notes .................................................................... 54
3.4.2. Gestion des absences .............................................................. 55
3.4. Les fonctionnalités exécutées par les étudiants ......................... 56
4. Phase de tests ................................................................................ 56
5. Evaluation de l’application réalisée .............................................. 58
5.1. Les points de force de l’application développée ....................... 58
5.2. Les points de faibless de l’application développée ................... 58
6. Conclusion .................................................................................... 58
Conclusion Géneral .......................................................................... 60
Référence .......................................................................................... 61
iv
TABLE DES FIGURES
Figure 1.1. Evolution historique d’UML............................................... 5
Figure.1.2. Exemple de diagramme de classes..................................... 6
Figure 1.3. Exemple de diagramme d’objets. ........................................ 7
Figure 1.4. Exemple de diagramme de paquet ...................................... 7
Figure 1.5. Exemple de diagramme de cas d’utilisation ....................... 8
Figure 1.6. Exemple de diagramme d’états-transitions. ........................ 8
Figure 1.7. Exemple de diagramme d’activité. ..................................... 9
Figure 1.8. Exemple de diagramme de séquences…………………
.10
Figure 1.9. Exemple de diagramme de communication. ..................... 10
Figure 1.10. Exemple de diagramme global d’interaction. ................. 11
Figure 1.11. Exemple de diagramme de temps ................................... 12
Figure 2.1. Architecture du système de gestion du département
actuel………………………………………………………………...16
Figure 2.2. Taches de notre projet de fin d’étude……………………17
Figure 2.3. Classes d’utilisateur de la future application. ................... 18
Figure 2.4. Diagramme des cas d’utilisation global ............................ 20
Figure 2.5. L’architecture globale de l’application à réaliser. ............ 21
Figure 2.6. Diagramme de séquence du cas d’utilisation «
authentification » ................................................................................. 23
Figure 2.7. Diagramme de séquence du cas d’utilisation «
déconnexion ». ..................................................................................... 24
Figure 2.8. Diagramme de séquence du cas d’utilisation « gérer
affectation ». ........................................................................................ 25
Figure 2.9. Diagramme de séquence du cas d’utilisation «importer
données ». ............................................................................................ 26
Figure 2.10. Diagramme de séquence du cas d’utilisation « exporter
données ». ............................................................................................ 27
Figure 2.11. Diagramme de séquence du cas d’utilisation « exporter
notes/absences »................................................................................... 28
v
notes»………………………………………………………………..29
absences»…………………………………………………………….30
Figure 2.14. Diagramme de séquence du cas d’utilisation « Consulter
données»……………………………………………..………………31
Figure 2.15. Diagramme de classes-entités….…………………....…33
Figure 2.16. Diagramme de classes pour la gestion des
sessions…............................................................................................34
Figure 2.17. Diagramme d’activité de l’opération
connester()…………………………………………………………...34
Figure 2.18. Diagramme de classes pour les traitements de
l’administrateur……………………………………………………...35
Figure 2.19. Diagramme d’activité de l’opération importer-données()
.............................................................................................................. 36
Figure 2.20. Diagramme de classes pour les traitements des chefs de
spécialité .............................................................................................. 37
Figure 2.21. Diagramme d’activité de l’opération exporter-données()
.............................................................................................................. 37
Figure 2.22. Diagramme de classes pour les traitements des
enseignants ........................................................................................... 38
Figure 2.23. Diagramme d’activité de l’opération gérer-absences() .. 39
Figure 2.24. Diagramme de classes pour les traitements des étudiants
.............................................................................................................. 40
Figure 2.25. Diagramme d’activité de l’opération consulter-données()
.............................................................................................................. 40
vi
LISTE DES TABLEAUX
Table 2.1. Liste des classes d’acteurs avec leurs rôles…………….19
Table 3.1. Table des test………….. ………………………………57
Table 3.2. Table des justificatifs pour les tests non réalisés……….57
vii
Résumé
Résumé
L’objectif de ce travail de mémoire de Master est inclus dans le cadre de développement de
notre département (département de mathématique de d’informatique) sur le plan
d’informatisation des tâches pédagogiques et de gestion. En effet, en constant l’existence de
certaines insuffisances au niveau des outils informatiques actuels de gestion, nous proposons
une tentative pour l’amélioration de ce manque. Ainsi nous essayons à travers ce projet
d’utiliser les technologies du web pour l’informatisation de la saisie et le suivi des notes et des
absences des étudiants, ce qui n’était pas possible dans le cas du système actuel par les
administratifs, les enseignants et les étudiants. En effet, il suffit de se connecter puis saisir ou
consulter ses notes et ses absences sans qu’il soit obligé de se présenter au niveau de secrétariat
où les applications tournent uniquement en local. Nous pensons donc que les mécanismes de
migration des données entre le local et le distant (web) qu’on propose seront très efficaces pour
garantir la souplesse dans l’exploitation des outils existants.
Mots clés
Application web, application Internet Riche, architecture client/serveur, Modélisation UML.
1
Introduction Générale
Introduction Générale
L’évolution des nouvelles technologies numériques (ordinateurs, Smartphones,

tablettes) ont apporté des changements importants dans notre comportement quotidien. Elles ne
cessent d’apporter des simplifications dans l’exécution de nos tâches de la vie de tous les jours,
notamment, les tâches fastidieuses, ennuyeuses ou contraignantes.
Le travail administratif de notre service scolarité est souvent répétitif et dans la majorité
des cas très contraignant, son allègement et son amélioration ne sera que bénéfique. Dans ce
cadre, l’informatique et les nouvelles technologies nous apporteront des solutions à ces
difficultés. C’est pourquoi, nous avons pensé mettre à la disposition du personnel et des
étudiants une application Web qui va permettre d’une part au personnel de faciliter et de
simplifier ses activités et aux étudiants d’accéder à leurs résultats pédagogiques sans contraintes
ni perte de temps : il suffira de se connecter puis s’identifier à la base des notes des étudiants
pour avoir accès à tous ses résultats de l’année.
Pratiquement, la réalisation d’un tel outil doit forcément passer par des phases du génie
logiciel afin de convaincre la complexité de développement. Ainsi, nous allons s’appuyer sur
quelques diagrammes du langage de modélisation UML.
Ce travail est structuré de la manière suivante :
 Un premier chapitre est consacré à la présentation du langage de modélisation UML :
son formalisme et ses principaux diagrammes en particulier ceux utilisés dans le cadre
de notre étude.
 Le deuxième chapitre est réservé à la présentation du langage de modélisation UML :
son formalisme, ses principaux diagrammes en particulier ceux utilisés dans le cadre
de notre étude.
 Le chapitre trois est consacré dans sa première partie à la présentation des principaux
langages, technologies et outils utilisés. Dans la deuxième partie, nous décrivons et
détaillons les principales fonctionnalités du système et nous présentons les détails de
l’implémentation de notre réalisation.
 Pour terminer, nous avons suggéré des perspectives d’évolution de ce travail.
2
CHAPITRE 1 Le langage de modélisation UML
1. Introduction
Historiquement, il y a eu plusieurs évolutions successives en programmation, d’où

l’apparition des paradigmes de programmation. En effet, le paradigme de programmation
orientée-objets est devenu l’un des styles de programmation les plus répandus. Il consiste à
modéliser un ensemble d’entités du monde réel (concrètes) en un ensemble d’entités
informatiques (abstraites) sous une représentation sans préoccuper de l’implémentation. Cela
garantit que la définition des problèmes soit à haut niveau d’abstraction loin de rentrer dans
les détails d’implémentation. C’est dans ce contexte que le langage de modélisation connu
sous l’acronyme d’UML est apparu puis s’est développé pour qu’il atteigne un intérêt
croissant dans différents domaines.
Dans ce chapitre, nous présenterons brièvement le formalisme d’UML qui sera utilisé pour la
modélisation de notre application dans le chapitre suivant. Nous donnons donc, sa définition,
son historique, ses formalismes et enfin quelques éléments de ses avantages et ses
inconvénients.
2. Le langage de modélisation UML
UML ou « langage de modélisation unifié » est un langage de modélisation graphique à base

de pictogrammes (i.e. représentation graphique schématique). Il est apparu dans le monde du
génie logiciel, dans le cadre de la conception orientée-objets. Il permet de représenter de
manière graphique les besoins des utilisateurs en utilisant un ensemble de diagrammes ainsi
que les éléments du logiciel à développer en décrivant son fonctionnement. UML est né de la
fusion des trois méthodes ayant influencé la modélisation en objets au cours des années 90 :
OMT (Object Modeling Technique), Booch et OOSE (Object Oriented Software
Engineering). A présent, UML est devenu un standard défini par l’Object Management Group
(OMG) et de très nombreuses entreprises de renom l’ont adopté et participent toujours à son
développement [1].
3. Historique d’UML
L’un des problèmes posés par les premières méthodes structurées et fonctionnelles
comme Merise fut la difficulté de migration vers le paradigme de programmation orientée-
objets. Pour surmonter ces difficultés, de nombreux chercheurs commencèrent au début des
4
années 90 à penser d’inventer de nouvelles méthodes qui soient universellement acceptées

sachant que plus de cinquante méthodes d’analyses et de conception objet existaient déjà pour
le même objectif, parmi lesquelles nous citons, BOOCH de Grady Booch, OMT de James
Rumbaugh et enfin OOSE d’Ivar Jacobson.
En 1994, le langage unifié UML est apparu comme un langage de modélisation orientée-
objets, suite à une fusion de quelques unes des méthodes existantes. La version 1 d’UML a été
publiée en 1997, après la réunion des acteurs principales des méthodes précédentes en 1996
pour qu’ils se mettent d’accord sur un langage de modélisation en espérant qu’il devienne une
référence. Cette norme n’a cessé d’évoluer en ajoutant de nouveaux formalismes jusqu’à la
sortie de la norme 2.2 en 2009, puis la version UML 2.4.1 en 2011 et plus récemment la
version officielle déclarée par l’OMG UML 2.5.1 (voir Figure 1.1) [2].
Figure 1.1. Evolution historique d’UML.
4. Les diagrammes d’UML
Depuis la version 2.3 d’UML, on retrouve quatorze (14) diagrammes qui se complètent lors
de la modélisation d’un projet tout au long de son cycle de vie. Ces diagrammes sont classés
5
selon trois catégories : les diagrammes structurels, les diagrammes comportementaux et les
diagrammes d’interaction. Dans ce qui suit, nous allons présenter brièvement quelques uns de
ces diagrammes. Il est à noter que les informations contenues dans cette section ont été prise
depuis les références [1, 2, 3, 4].
4.1. Les diagrammes de structure (ou encore statiques)
Il s’agit de la plus large catégorie ; elle renferme sept (07) diagrammes au total : Le
diagramme de classes, le diagramme d’objets, le diagramme des paquets, le diagramme de
composants, le diagramme de déploiement, le diagramme de structure composite et enfin le
diagramme de profils. Nous n’allons présenter que les trois premiers diagrammes.
4.1.1. Le diagramme de classes
Le diagramme de classes montre la structure interne en fournissant une représentation

abstraite des objets du système qui vont interagir pour réaliser les cas d’utilisation. Ce
diagramme est considéré comme le plus important de la modélisation orientée-objets. La
figure 1.2 représente un exemple de diagramme de classes.
Figure.1.2. Exemple de diagramme de classes.
4.1.2. Le diagramme d’objets
Le diagramme d’objets permet de représenter les instances des classes : les objets. Il exprime
les relations qui existent entre les objets, mais aussi leurs états avant et après interactions, ce
6
qui permet d’exprimer des contextes d’exécution. Ce diagramme est moins général que le
diagramme de classes. La figure 1.3 montre un exemple de diagramme d’objets.
Figure 1.3. Exemple de diagramme d’objets.
4.1.5. Le diagramme des paquets
Les diagrammes de paquets permettent de regrouper des éléments UML tels que les classes,
les acteurs et les cas d’utilisation dans des unités de plus haut niveau. Ils servent à organiser
ces éléments selon leurs types, leurs fonctionnalités ou leurs architectures. Les paquets
peuvent être imbriqués dans d’autres paquets. Ces diagrammes sont le plus souvent
utilisés pour regrouper des classes. La figure 1.4 représente un exemple de diagramme de
paquets.
Figure 1.4. Exemple de diagramme de paquets.
7
4.2. Les diagrammes de comportement
Cette catégorie inclut trois diagrammes : le diagramme des cas d’utilisation, le diagramme
d’états-transitions et le diagramme d’activité.
4.2.1. Le diagramme des cas d’utilisation
Les diagrammes de cas d’utilisation permettent de recueillir et d’organiser les besoins

exprimés par les utilisateurs, et de définir les fonctionnalités du système en énumérant les
différents scénarios prévus. La figure 1.5 représente un exemple de diagramme de cas
d’utilisation.
Figure 1.5. Exemple de diagramme de cas d’utilisation.
4.2.2. Le diagramme d’états-transitions
Ce diagramme décrit le comportement interne d’un objet et la définition de tous les

changements d’états possibles associés, comme le montre la figure 1.6.
Figure 1.6. Exemple de diagramme d’états-transitions.
8
4.2.3. Le diagramme d’activité
Les diagrammes d’activité servent à modéliser la partie dynamique du modèle et

l’enchainement des activités du système ou des traitements déclenchés par les acteurs (voir
figure 1.7).
Figure 1.7. Exemple de diagramme d’activité.
4.3. Les diagrammes d’interaction (ou dynamique)
Cette catégorie contient quatre (04) diagrammes : le diagramme de séquence, le diagramme

de communication, le diagramme global d’interaction et enfin le diagramme de temps.
4.3.1. Le diagramme de séquence
Les diagrammes de séquences visualisent la coopération entre les différents objets. Les
principales informations contenues dans un diagramme de séquence sont les messages
échangés dans un ordre chronologique entre les objets. Le temps y est représenté de manière
claire. La figure 1.8 représente un exemple de diagramme de séquence.
9
Figure 1.8. Exemple de diagramme de séquences.
4.3.2. Le diagramme de communication

Les diagrammes de communication décrivent l’interaction entre les objets en mettant l’accent
sur les liaisons des données entre les différents participants à cette interaction. Ce diagramme
est basé sur une représentation des objets telle que chacun d’eux est lié graphiquement à ceux
avec lesquels il interagit. La figure 1.9 représente un exemple de diagramme de
communication.
Figure 1.9. Exemple de diagramme de communication.
10
4.3.3. Le diagramme global d’interaction
Ce diagramme donne une vue d’ensemble d’interactions en mélangeant des diagrammes

d’activités et des diagrammes de séquences. Il concentre sur les liaisons des données entre les
différents participants à l’interaction. La figure 1.10 représente un exemple de diagramme
global d’interaction.
Figure 1.10. Exemple de diagramme global d’interaction.
4.3.4. Le diagramme de temps
Les diagrammes de temps sont utilisés pour explorer le comportement des objets d’un
système dans une période de temps. Il s’agit d’une forme spéciale de diagramme de séquence
où les axes sont inversés pour que le temps s’écoule de la gauche vers la droite et les lignes de
vies sont affichées dans des compartiments séparés disposés horizontalement. La figure 1.11
montre un exemple de diagramme de temps.
11
Figure 1.11. Exemple de diagramme de temps
5. Evaluation d’UML
Comme tout outil de modélisation, UML présente des avantages et des inconvénients qu’on
peut résumer comme suit.
5.1. Les avantages du langage UML
Les avantages d’UML peuvent être résumés comme suit [3]:

- UML est un standard ; ainsi il présente un champ de recherche très actif qui a mené à
développer un nombre assez-grand nombre d’améliorations et d’outil.
- UML présente une simplicité ainsi que des facilités pour le codage, la réutilisation, la
compréhension et la maintenance.
- UML est un modèle proche de la réalité grâce à ses divers types de diagrammes.
- UML est générique dans le sens où il ne se limite pas au domaine du génie logiciel
mais en dépassant au delà de cela pour qu’il soit un langage de modélisation général.
5.2. Les inconvénients du langage UML
Les inconvénients d’UML peuvent se résumer en [3]:

- Les digrammes d’UML sont nombreux et même longs, ce qui nécessite plus temps
pour être familiarisé avec tous ses formalismes et donc pour aboutir une bonne
maîtrise.
12
- Le langage UML est lourd lors de sa mise en pratique vu le grand nombre de ses
diagrammes. En outre, il nécessite un apprentissage qui passe par une période
d’adaptation.
6. Conclusion
Ce chapitre nous a permis de faire une brève présentation du langage de modélisation UML.
Ainsi, nous avons introduit ses formalismes qui constituent ses points-clés. Clairement, nous
pouvons sentir sa richesse et sa puissance d’expression ; et cela justifie l’intérêt croissant
durant toutes ces années pour qu’il aboutisse un degré de maturité le rendant l’un des plus
puissants outils de modélisation. Par conséquent, nous allons l’adopter tout au long des phases
de développement de notre projet de fin d’étude.
13
Chapitre 2 Analyse des besoins & conception
1. Introduction
L’objectif de ce travail est de développer une application client-serveur pour assurer la gestion
de quelques tâches administratives de notre département (i.e. département de Mathématique et
d’Informatique) à savoir la gestion des notes et des absences des étudiants. Cela permet au
personnel (responsables, adjoints, enseignants et étudiants) de faciliter et de simplifier leurs
activités les plus fréquentes.
En fait, le développement de tout produit informatique doit passer par un processus du génie
logiciel afin de surmonter les difficultés et les complexités de réalisation. Généralement, nous
distinguons les étapes d’analyse des besoins, la conception, l’implémentation et enfin les tests.
Dans ce chapitre, nous allons nous occuper des deux premières phases. Pour ce faire, nous
commençons par une description des besoins fonctionnels essentiels de manière textuelle,
résumés dans un cahier des charges. Ensuite, nous allons transformer ces besoins en un
ensemble de diagrammes UML : le diagramme des cas d’utilisation, les diagrammes de
séquences, les diagrammes d’activité et le diagramme des classes. Nous terminerons ce
chapitre par une conclusion résumant cette partie.
2. Le système de gestion actuel
Le système de gestion du département actuel consiste en une application monoposte,

développée en langage Visuel Basic (VB) et manipulée par un seul agent. Elle permet de
gérer l’effectif des étudiants y compris leur répartition en sections et en groupes, les matières
enseignées et les notes d’examens et d’évaluation continue. Au début de chaque année
universitaire, l’agent saisit la liste des étudiants et les matières enseignées à chaque niveau
(tronc commun, licence et master). Vient ensuite l’affectation des étudiants aux différents
sections et groupes où il y aura une répartition de ceux-ci. Une fois saisies, ces informations
sont généralement peu changées sauf pour cas d’erreur de saisie ou de changement des
groupes. Au cours de l’année, les étudiants doivent passer des examens et des évaluations
continues en deux semestres. A la fin de chaque semestre, les enseignants ramènent les notes
des étudiants selon les différentes matières enseignées sous forme de PV (version en papier) à
l’agent pour saisie. Cela permet de faire les délibérations. La figure 2.1 illustre un récapitulatif
de l’architecture de du système existant.
15
Figure 2.1. Architecture du système de gestion du département actuel
Sans doute, le système actuel est utile mais aussi pas suffisant du fait que la délégation de
toutes ces tâches à un seul agent peut engendrer des limitations, parmi lesquelles nous citons :
- Augmenter les risques d’erreur.
- Influencer négativement le rendement à cause des tailles des tâches à accomplir.
- Produire des difficultés lors de la gestion des notes notamment la saisie et la correction
des données erronées.
En outre, le système actuel ne permet pas de gérer les absences des étudiants, qui est une
tâche très importante dans le parcours d’étudiants.
3. Propositions pour l’amélioration du système actuel
Pour surmonter les difficultés induites par l’utilisation du système de gestion actuel, nous
proposons un ensemble d’améliorations en l’enrichissant par des nouvelles fonctionnalités et
de nouveaux acteurs. En effet, en synthétisant le système actuel, nous avons constaté que la
source des difficultés est principalement liée à deux aspects :
- La gestion des notes qui se fait généralement dans des délais bien précis.
- La gestion des absences des étudiants qui n’est pas supportée.
Comme solution, nous proposons d’enrichir le système de gestion actuel par une application
web permettant de gérer la tâche de saisie et de consultation des notes et des absences des
étudiants de notre département. Sur le plan fonctionnel, l’application est divisée en quatre
grandes parties selon les types d’opérations offerts. La première partie est exécutée par un
administrateur qui doit d’abord importer les données depuis le système existant ; cette
opération est exécutée une seule fois (généralement au début de l’année universitaire). Une
fois l’importation des données faite, l’administrateur peut gérer les comptes des utilisateurs et
16
les affectations des matières aux enseignants. A la fin de chaque semestre, les données sont
exportées afin de les fournir à l’application de délibération au niveau du secrétariat du
département. La deuxième partie est réservée aux chefs de spécialités qui peuvent suivre l’état
des absences et des notes afin d’animer leurs CPs (comités pédagogiques) et la tâche de
délibération. La troisième partie concerne les enseignants qui peuvent saisir les notes et les
absences des étudiants selon les matières et les groupes enseignés. Les enseignants peuvent
également exporter les données saisies sous forme de fichiers imprimables pour des raisons de
traçabilité. La dernière partie concerne les étudiants qui peuvent consulter leurs notes et leurs
absences dans les différentes matières étudiées.
4. Gestion de notre projet
La gestion du projet est une démarche dont l’objectif est d’organiser pas à pas le bon
déroulement d’un projet donné. Dans des cas pareils, le diagramme de Gantt semble un choix
raisonnable vu sa popularité tenue de sa simplicité et sa puissance d’expression. Il s’agit d’un
outil d’ordonnancement et de gestion de projet qui permet de visualiser graphiquement
l’avancement des diverses tâches d’un projet dans le temps. La figure 2.2 montre les tâches de
notre projet ainsi que leurs dates de début et de fin, généré par l’outil informatique Gantt
Project [3].
Figure 2.2. Tâches de notre projet de fin d’étude.
17
5. Analyse préliminaire des besoins
Cette phase est consacrée à la compréhension du contexte du système. Par conséquent, il est
demandé de déterminer les fonctionnalités et les acteurs les plus pertinents, et donc les cas
d’utilisation initiaux.
5.1. Définition des acteurs et capture des besoins fonctionnels
Un acteur est une entité externe qui interagit directement avec le système étudié, en
échangeant de l'information (en entrée et en sortie). Dans le présent projet, quatre classes
d’acteurs principaux sont distinguées : l’administrateur, le chef de spécialité, l’enseignant et
l’étudiant. La Figure 2.3 illustre les différentes classes d’utilisateurs du futur système.
Figure 2.3. Classes d’utilisateur de la future application.
La table 2.1 montre les besoins fonctionnels de chaque acteur.
18
Acteur Besoin fonctionnel

Administrateur - Importation des données vers la BD.
- Exportation des données à partir de la BD.
- Gestion des affectations matière-enseignant.
- Gestion des comptes-utilisateurs.
Chef de spécialité - Exportation des notes des modules de sa spécialité.
- Exportation des notes des absences de sa spécialité.
Enseignant - Gestion des absences des groupes enseignés.
- Gestion des notes des groupes enseignés..
Etudiant - Consultation des notes.
- Consultation des absences.
Table 2.1. Liste des classes d’acteurs avec leurs rôles.
5.2. Les besoins non fonctionnels
Les besoins non fonctionnels concernent les contraintes à prendre en considération pour
mettre en place une solution adéquate à des architectures dynamiques. Nous devons ainsi
assurer les besoins suivants :
 L’extensibilité : cet aspect suppose que l’application permet d’ajouter des nouvelles
fonctionnalités, de modifier ou enlever des fonctionnalités existantes.
 La sécurité : l’application doit être sécurisée de sorte que ses données doivent rester
confidentielles et donc inaccessibles publiquement ce qui exige d’attribuer des noms
d’utilisateur et des mots de passe à des personnes physiques.
 La qualité des interfaces graphiques : l’application doit être gérée via une interface
graphique conçue selon les normes des IHM (interface homme-machine) telles que
l’ergonomie.
 La performance : l’application doit réagir au bout d’un temps précis quelle que la
soit la nature de l’action de l’utilisateur.
 La convivialité : l’application doit être simple et facile à manipuler quelque même par
des non experts.
19
5.3. Diagramme des cas d’utilisation global
Avec ce type de diagramme, il est possible de donner une vision globale sur les
fonctionnalités du système à modéliser ainsi que sur les acteurs participants. La figure 2.4
représente le diagramme des cas d’utilisation globale correspondant au cahier des charges.
Figure 2.4. Diagramme des cas d'utilisation global.
5.4. Architecture générale du nouvel système
Comme l’application développée est une application web, son architecture est du type
client/serveur, où le coté client consiste en un ensemble de pages web dynamiques alors que
le serveur est un serveur web dédié à traiter des requêtes HTTP provenant des clients tout en
interagissant avec une base de données. La figure 2.5 illustre l’architecture globale de notre
système.
20
Figure 2.5. L’architecture globale de l’application à réaliser.
Il s’agit donc d’une architecture trois tiers (1/3) qui se compose généralement des trois
couches suivantes :
 La couche de présentation des données : cette couche correspond à tout ce qui est
affichage et communication avec l’utilisateur dans le poste de travail.
 La couche de traitement métier des données : cette couche représente l’ensemble
des règles de gestion et la logique applicative.
 La couche d’accès aux données persistants : cette couche est dédiée à manipuler les
données que l’on veut stocker de manière permanente.
Nous constatons donc que, dans notre cas, la couche de présentation correspond au navigateur
web permettant d’afficher le contenu des pages web dynamiques, la couche de traitement
correspond aux scripts exécutés sur le serveur web et enfin la couche d’accès aux données
correspond à la BD contenant les différentes données du système.
6. Analyse détaillée des besoins fonctionnels : description textuelle des cas

d’utilisation
Dans cette section, nous allons entamer la phase d’analyse détaillée des besoins qui aura lieu
une fois l’étude de faisabilité du projet jugée positive. En effet, une fois le diagramme des cas
d’utilisation établi, nous procédons à une description textuelle de chaque cas d’utilisation pour
détailler sa façon de réalisation, dotée de diagrammes de séquence. Nous signalons que nous
allons suivre un modèle inspiré de celui qui est décrit dans les références [6, 7, 8, 9].
21
6.1. Le cas d’utilisation « Authentification »
Titre : Authentification
Résumé : Ce cas d’utilisation permet à toutes les classes d’utilisateur d’ouvrir une session de
travail.
Acteur : Administrateur / chef de spécialité / Enseignant / Etudiant.
Pré-condition : Connexion internet.
Scénario nominal
1. L’utilisateur demande au système de s’authentifier.
2. Le système demande de saisir le nom d’utilisateur et le mot de passe.
3. L’utilisateur saisit le nom d’utilisateur et le mot de passe puis valide l’action.
4. Le système vérifie les informations entrées (présence des informations obligatoires).
5. Le système lance une requête au serveur pour ouvrir la session de travail.
6. Le serveur vérifie le nom d’utilisateur et le mot de passe.
7. Le serveur ouvre la session de travail selon le rôle de l’utilisateur en affichant les
fonctionnalités correspondantes.
Les enchainements alternatifs
A1 : Le remplissage des champs n’est pas complété.
A1 démarre au point 4 du scénario nominal.
5. Le système détecte les champs qui ne sont pas complétés en affichant un message
informatif.
Le système reprend au point 2 du scénario nominal.
Les enchainements d’erreurs
E1 : « Le nom d’utilisateur » ou « le mot de passe » sont erronés.
E1 démarre au point 7 du scénario nominal.
8. Le système indique à l’utilisateur que son « nom d’utilisateur » ou son « mot de passe »
sont erronés.
Post condition : Session ouverte.
La figure 2.6 représente le diagramme de séquence correspondant à ce cas d’utilisation.
22
Figure 2.6. Diagramme de séquence du cas d’utilisation « authentification ».
6.2. Le cas d’utilisation « déconnexion »
Titre : déconnexion.
Résumé : Ce cas d’utilisation permet à toutes les classes d’utilisateur de fermer la session de
travail en cours.
Acteur : Administrateur / chef de spécialité / Enseignant / Etudiant
Scénario nominal
1. L’administrateur / Enseignant / Etudiant / demande au système de fermer sa session.
2. Le système lance une requête au serveur.
3. Le serveur reçoit la requête et la traite.
4. L’administrateur / Enseignant / Etudiant / abonné reçoit une notification indiquant que sa
session est fermée avec succès.
Post condition : Session fermée.
23
Figure 2.7. Diagramme de séquence du cas d’utilisation « déconnexion ».
6.3. Le cas d’utilisation « gérer affectations matière-enseignant »
Titre : gérer affectations.

Acteur : Administrateur.
Résumé : ce cas d’utilisation permet à l’administrateur d’effectuer des affectations des
matières aux enseignants.
Pré-condition : connexion internet
Scénario nominal
1. Après « authentification ».
2. L’administrateur demande au système d’affecter les matières aux enseignants.
3. Le système demande à l’administrateur de faire la saisie des données.
4. L’administrateur saisit les informations nécessaires pour effectuer l’affectation de telle
matière à tel enseignant.
5. Le système vérifie les informations entrées.
6. Le système envoie une requête au serveur pour enregistrer les données.
7. Le système affiche une notification à l’administrateur indiquant que l’opération a été
effectuée.
24
Les enchainements alternatifs

A1 : La saisie des données n’est pas complétée.
A1 démarre au point 5 du scénario nominal.
6. Le système détecte les champs qui ne sont pas complétés en affichant un message
informatif.
Le système retourne au point 3 du scénario nominal.
Post-condition : affectation effectuée.
La figure 2.8 représente le diagramme de séquence de ce cas d’utilisation.
Figure 2.8. Diagramme de séquence du cas d’utilisation « gérer affectation ».
6.4. Le cas d’utilisation « importer données »
Titre : importer données.

Résumé : ce cas d’utilisation permet à l’administrateur d’importer le contenu de la BD à
partir de fichiers externes.
Précondition : connexion à internet.
25
Scénario nominal
2. L’administrateur demande au système d’importer le contenu de la BD à partir des fichiers
externes.
3. Le système envoie une requête au serveur.
4. Le serveur traite la requête en transférant le contenu des fichiers vers la BD.
5. Le système affiche une notification indiquant que le fichier est importé avec succès.
Post-condition : Données importées.
La figure 2.9 représente le diagramme de séquence qui correspond à ce cas d’utilisation.
Figure 2.9. Diagramme de séquence du cas d’utilisation « importer données ».
26
6.5. Le cas d’utilisation « exporter données »
Titre : exporter données.

Acteur : Administrateur.
Résumé : ce cas d’utilisation permet à l’administrateur d’exporter le contenu de la BD vers
des fichiers externes pour diverses raisons (archivage des données, transfert des données vers
le système de délibération…etc.).
Pré condition : connexion internet.
Scénario nominal
2. L’administrateur demande au système d’exporter le contenu de la BD.
3. Le système envoie une requête au serveur pour qu’il la traite.
4. Le serveur reçoit et traite la requête en générant une liste de fichiers téléchargeables.
5. L’administrateur récupère les données en téléchargeant les fichiers générés.
Post-condition : données exportées sous forme de fichiers.
Figure 2.10. Diagramme de séquence du cas d’utilisation « exporter données ».
27
6.6. Le cas d’utilisation « exporter Notes / Absences »
Titre : exporter Notes / absences.

Acteur : Chef de spécialité.
Résumé : ce cas d’utilisation permet au chef de spécialité d’exporter les notes et les absences
des groupes de la spécialité dont il est responsable vers des fichiers externes pour diverses
raisons (CPs, délibération...etc.).
Pré condition : connexion internet.
Scénario nominal
7. Le chef de spécialité demande au système d’exporter les données.
9. Le serveur reçoit et traite la requête en générant une liste de fichiers (notes / absences)
téléchargeables.
10. Le chef de spécialité récupère les données en téléchargeant les fichiers générés.
Post-condition : notes / absences exportées sous forme de fichiers.
Figure 2.11. Diagramme de séquence du ca d’utilisation « exporter notes/absences »

28
6.7. Le cas d’utilisation « saisir notes »

Titre : saisir notes-étudiants.
Acteur : Enseignant.
Résumé : ce cas d’utilisation permet aux enseignants de faire la saisie les différentes notes
des étudiants de leurs groupes enseignés.
Scénario nominal
2. L’enseignant demande au système de faire la saisie des notes en spécifiant la matière et le
groupe d’étudiants concernés.
3. Le système affiche un formulaire pour la saisie des notes de chaque étudiant dans le groupe
sélectionné.
4. L’enseignant saisit les notes puis valide l’action.
5. Le système lance une requête au serveur.
6. Le serveur sauvegarde les notes dans la BD.
7. Le système envoie une notification indiquant que l’opération est faite
Post-condition : Notes enregistrées dans la BD.
Figure 2.12. Diagramme de séquence du cas d’utilisation « gérer notes ».

29
6.8. Le cas d’utilisation « Gérer absences »

Titre : Gérer absences.
Résumé : ce cas d’utilisation permet à un enseignant de gérer les absences de ses groupes
enseignés.
Scénario nominal
2. L’enseignant demande au système de gérer les absences en désignant la matière et le
groupe d’étudiants concernés.
3. Le système affiche un formulaire pour la gestion des absences de chaque étudiant dans le
groupe sélectionné.
4. L’enseignant modifie les absences puis valide l’action.
6. Le serveur sauvegarde les modifications effectuées dans la BD.
7. Le système envoie une notification à l’enseignant indiquant que les modifications
apportées sont enregistrées.
Post-condition : absences enregistrées dans la BD.
Figure 2.13. Diagramme de séquence du cas d’utilisation « gérer absences ».

30
6.9. Le cas d’utilisation « consulter notes / absences »
Titre : consulter l’historique des notes et des absences de l’année en cours.

Acteur : étudiant.
Résumé : ce cas d’utilisation permet aux étudiants de consulter leurs notes / absences.
Pré-condition : connexion à internet
Scénario nominal
1. Après authentifier.
2. Le serveur extrait la liste des notes et des absences de l’étudiant.
3. Le système affiche la liste des notes et des absences.
Post-condition : notes et absences affichées.
Figure 2.14. Diagramme de séquence du cas d’utilisation « consulter-données ».
31
7. Phase de conception
Dans cette phase, il est demandé d’élaborer les spécifications de l’architecture générale de
l’application en essayant de définir précisément chacun de ses constituants (informations
traitées, traitements effectués, résultats fournis, contraintes à respecter…etc.). On permet donc
de savoir comment le produit est structuré pour faire ce qu’il doit faire.
Ainsi, nous allons utiliser deux types de diagrammes UML : les diagrammes de classes et les
diagrammes d’activité. Pour les diagrammes de classes, deux types de diagrammes sont
utilisés : les diagrammes de classes-entités et les diagrammes de classes-métiers. Les premiers
décrivent les objets persistants qui seront stockés dans la BD et donc son schéma conceptuel.
Les deuxièmes permettent de décrire les opérations requises pour la réalisation des cas
d’utilisation. Ces diagrammes sont dotés des diagrammes d’activité associés afin d’approcher
des issues pratiques (phase d’implémentation). Il convient de noter que nous n’allons
représenter que quelques diagrammes d’activité à titre d’illustration.
7.1. Diagramme de classes-entités
La Figure 2.15 représente le diagramme de classes-entités que nous avons tiré à partir du
système de gestion actuel en ajoutant uniquement quelques classes.
32
Figure 2.15. Diagramme de classes-entités.
7.2. Diagramme de classes-métiers
Nous avons associé à chaque acteur une classe-métier permettant de réaliser ses cas
d’utilisation.
7.2.1. Gestion des sessions
Le diagramme de classes associé aux opérations de la gestion des sessions est représenté par
la Figure 2.16.
33
Figure 2.16. Diagramme de classes pour la gestion des sessions.

La Figure 2.17 illustre le diagramme d’activité décrivant le processus d’exécution de
l’opération ‘connecter ()’.
Figure 2.17. Diagramme d’activité de l’opération connecter().

34
7.2.2. Gestion des traitements assurés par l’administrateur
Le diagramme de classes associé aux opérations de la gestion des traitements effectués par
l’administrateur est représenté par la Figure 2.18.
Figure 2.18. Diagramme de classes pour les traitements de l’administrateur.

l’opération ‘importer-données ()’.
35
Figure 2.19. Diagramme d’activité de l’opération importer-données().
7.2.3. Gestion des traitements assurés par le chef de spécialité
Le diagramme de classes associé aux opérations de la gestion des traitements effectués par le
chef de spécialité est représenté par la Figure 2.20.
36
Figure 2.20. Diagramme de classes pour les traitements des chefs de spécialité.

l’opération ‘exporter-données()’.
Figure 2.21. Diagramme d’activité de l’opération exporter-données().

37
7.2.4. Gestion des traitements assurés par l’enseignant
l’enseignant est représenté par la Figure 2.22.
Figure 2.22. Diagramme de classes pour les traitements des enseignants.

l’opération ‘gérer-absences()’.
38
Figure 2.23. Diagramme d’activité de l’opération gérer-absences().
7.2.5. Gestion des traitements assurés par l’étudiant
l’étudiant est représenté par la Figure 2.24.
39
Figure 2.24. Diagramme de classes pour les traitements des étudiants.

l’opération ‘consulter-données()’.
Figure 2.25. Diagramme d’activité de l’opération consulter-données()
40
8. Conclusion
Dans ce chapitre, nous avons mis en avant les phases qui nous approchent à la phase
d’implémentation de l’application : la phase d’analyse des besoins et celle de conception.
Pour ce faire, nous avons exploité quelques digrammes du langage UML : le diagramme des
cas d’utilisation et les diagrammes de séquences pour la première phase, et, le diagramme de
classes et les diagrammes d’activité pour la deuxième phase. Reste les phases
d’implémentation et de tests que nous aborderons dans le chapitre qui suit.
41
Chapitre 3 Implémentation & test de l’application
1. Introduction
L’implémentation est en fait la phase du génie logiciel qui permet de passer de l’abstrait au
concret en produisant un programme exécutable. Pour ce faire, nous avons jugé utile de
présenter, même si, brièvement les différents langages et outils utilisés pendant la phase de
programmation tout en justifiant nos choix. Nous décrivons ensuite l’aspect fonctionnel de
l’application en illustrant par des figures qui schématisent ses différents écrans. Nous
discutons également la phase du génie logiciel des tests qui permet d’évaluer la qualité de
l’application développée. Enfin, nous terminerons par une évaluation objective du travail
réalisé dans le cadre de ce projet de fin d’étude.
2. Outils, langages et technologies de développement
Lors du développement de notre application, nous avons utilisé différents environnements,

langages, outils et techniques. Nous allons donc les énumérer en montrant le rôle de chacun
d’eux à la phase d’implémentation.
2.1. L’environnement de développement web Dreamweaver
Dreamwaver est un environnement professionnel pour le développement web proposé

Macromedia Inc, rachetée plus tard par Adobe Systems Inc. Il s’agit d’un éditeur destiné à la
conception et au codage lors du développement des sites web. Il présente des facilités de
codage en supportant différents langages de programmation Web tels que PHP, HTML,
XML…etc. Il est également possible d’afficher et de modifier directement le code source
(HTML, CSS, ou autre) des pages. La figure 3.1 représente le logo de l’environnement
Dreamweaver.
Figure 3.1. Logo de l’environnement Dreamweaver.
43
Nous avons utilisé la version CS6 qui nous a permis de :

- Créer des pages web dotées d’interfaces graphiques avec de simples méthodes pour la
manipulation du code HTML.
- Injecter des scripts en langage PHP au sein des pages Web afin d’ajouter l’aspect
dynamique à celles-ci en fonction des données enregistrées dans la BD.
- Ecriture différents scripts dans le coté client (JavaScript et CSS).
2.2. Le langage XML
XML (eXtensible Markup Language) est un langage informatique qui permet de décrire des
données à l’aide de balises et de règles que l’on peut personnaliser. Tout comme le langage
HTML, XML utilise des balises mais qui ne sont pas prédéfinies. Ce langage est très utilisé
lorsqu’il s’agit d’échanges de données entre machines, en particulier sa compatibilité avec les
applications web où les échanges de données puissent s’effectuer à travers le réseau Internet.
La figure 3.2 représente le logo du langage XML.
Figure 3.2. Logo du langage XML.
Nous l’avons utilisé pour formater les données provenant comme réponses à des requêtes
HTTP envoyées au serveur web dans le but de réécrire le code HTML des pages sans les
rafraichir. Nous l’avons aussi utilisé pour coder les données importées et exportées vers et
depuis la BD au niveau du serveur.
2.3. Le langage PHP
PHP est un langage de script open source conçu pour le développement d’applications web
dynamiques. Il peut être facilement intégré au sein des pages HTML grâce à une balise de
début et une autre de fin qui permettent au serveur web de passer en mode PHP. La partie
PHP correspond donc à la partie dynamique du document HTML finalement envoyé par le
serveur et que le navigateur transformera en page web. La figure 3.3 représente le logo du
langage PHP.
44
Figure 3.3. Logo du langage PHP.
En ce concerne notre application, nous avons utilisé ce langage pour :

- Ajouter l’aspect dynamique à certaines pages.
- Générer les documents XML provenant du navigateur suite à des requêtes envoyées au
serveur web.
2.4. Le langage JavaScript
JavaScript est un langage de programmation de scripts exécuté par les navigateurs web pour
rendre les pages interactives en apportant des fonctionnalités correspondantes à des besoins
spécifiques. Si ce langage est désactivé pour une quelconque raison, le contenu ou l’utilisation
de la page web peuvent s’en trouver restreints ou indisponibles. Généralement, ce langage
permet de contrôler les données saisies dans des formulaires HTML et d’interagir avec le
document HTML. La figure 3.4 représente le logo du langage JavaScript.
Figure 3.4. Logo du langage JavaScript.
Concernant notre application, nous l’avons utilisé pour :

- Contrôler les données des différents formulaires.
- Rendre les pages web plus interactives à travers les composants graphiques.
- Traiter le code XML généré comme réponse à des appels Ajax.
45
2.5. Le pack WAMP
WAMP (Windows, apache, MySQL, PHP dans la majorité des cas mais aussi parfois « Perl »
ou « Python »), permet de faire fonctionner localement (sans se connecter à un serveur
externe) des scripts PHP ; la figure 3.5 représente son logo. Wamp Server n’est pas en soi un
logiciel, mais un environnement comprenant deux serveurs (Apache et MySQL), un
interpréteur de script (PHP), ainsi que PHP MyAdmin pour l’administration Web des bases de
données MySQL. Les rôles de ses composants sont:
 Apache sert à répondre directement au client.
 Le langage de script PHP sert la logique (accès aux données stockées dans une
BD, génération du contenu HTML…etc.).
 MYSQL stocke toutes les données de l’application.
Figure 3.5. Logo du pack WAMP.
2.6. Le langage CSS
CSS, acronyme de cascading Style Sheets (feuille de style en cascade), est un langage dont
l’objectif est de paramétrer finement la mise en page et la mise en forme des éléments d’un
document HTML en permettant l’obtention d’interfaces plus flexibles. Nous l’avons
principalement utilisé pour des raisons purement ergonomiques afin d’assurer l’aspect
esthétique de l’application.
2.7. Le langage HTML
HTML (HyperText Markup Langage) est un langage informatique qui utilise une structure
formée avec des balises permettant la mise en forme du contenu des pages web. La figure 3.6
représente le logo du langage HTML.
46
Figure 3.6. Logo du langage HTML.
Nous l’avons utilisé pour présenter les éléments affichables des pages web qui constituent
notre application.
2.8. La technique AJAX
AJAX (asynchrones JavaScript and XML) est une méthode de développement web basée sur
l’utilisation d’un script JavaScript pour effectuer des requêtes HTTP à l’intérieur d’une page
web sans rechargement de celle-ci. L’avantage principal de cette méthode est la vitesse à
laquelle une application AJAX répond aux actions de l’utilisateur. Pratiquement, les
applications basées AJAX sont compatibles avec tous les navigateurs web courants : Google
Chrome, Mozila …etc. La figure 3.7 représente le logo de la technique AJAX.
Figure 3.7. Le logo de la technique AJAX.
Cette technique nous a permis d’effectuer des traitements sans rafraichir les pages web en
invoquant le serveur qui effectue des traitements puis en récupérant des données dont le
contenu est écrit en langage XML. Une fois arrivées, ces données sont ensuite traitées par des
fonctions codées en JavaScript afin de modifier le contenu des pages selon le besoin
47
2.9. La bibliothèque JQuery
JQuery est une bibliothèque JavaScript libre et multiplateformes créée pour faciliter l’écriture
des scripts coté client dans le code HTML des pages web. La première version est lancée en
janvier 2006 par John Resig. Il s’agit d’une bibliothèque très riche en termes de fonctions en
revanche d’une très haute facilité d’utilisation. La figure 3.8 représente le logo de la
bibliothèque JQuery.
Figure 3.8. Logo de la bibliothèque JQuery.
En ce qui concerne notre application, nous avons utilisé cette bibliothèque pour créer des
composants graphiques que le langage HTML ne peut les générer lui seul. Nous l’avons aussi
utilisée pour implémenter des fonctions utilisant la technique AJAX sans se soucier du
navigateur exécutant le code JavaScript (bibliothèque multiplateformes).
3. Les fonctionnalités de l’application réalisée
Les fonctionnalités de l’application réalisée sont divisées en quatre catégories qui concernent
l’administrateur, les chefs de spécialités, les enseignants et enfin les étudiants. Ces
fonctionnalités sont implémentées pour s’exécuter sur un navigateur web. La figure 3.9
représente l’arborescence ou l’hiérarchie du contenu des pages web selon les fonctionnalités
de chaque acteur.
48
Figure 3.9. Arborescence du contenu des pages web selon le type d’acteurs.
3.1. La page d’accueil
La page d’accueil est un point d’accès commun entre tous les utilisateurs (administrateur,
enseignants et étudiants), ce qui permet à chacun d’eux d’accéder son espace de travail tout
comme décrit dans la phase d’analyse des besoins. La figure 3.10 Illustre la page d’accueil de
notre application.
Figure 3.10. Page d’accueil de l’application réalisée.
Ensuite, les acteurs du système doivent procéder à une authentification afin d’ouvrir leurs
sessions de travail en sélectionnant chacun son rôle depuis la liste des rôles affichée au coté
gauche. Cette opération permet d’identifier l’utilisateur du site. Elle est donc exécutée par
49
l’administrateur, les enseignants et les étudiants en entrant le nom d’utilisateur et le mot de

passe pour déverrouiller les différentes fonctionnalités en changeant d’écran selon le type
d’utilisateur connecté. La figure 3.11 représente la page d’authentification.
Figure 3.11. Capture d’écran de l’opération d’authentification.
3.2. Les fonctionnalités exécutées par l’administrateur
L’administrateur principal de l’application peut exécuter ses fonctionnalités après s’être

authentifié.
3.2.1. Importation des données
L’importation des données se fait en cliquant sur le bouton "Importation". Le système

demande à l’administrateur de choisir un fichier source qui doit porter le même nom que l’une
des tables de la BD (voir figure 3.12). Une fois le fichier transféré, le serveur transfert son
contenu dans la table ayant le même non. A la fin de l’opération, le système affiche un
message indiquant qu’elle a été faite avec succès. Dans le cas contraire, le système affiche un
message indiquant l’échec de l’opération d’importation.
50
Figure 3.12. Capture d’écran de l’opération d’importation des données.
3.2.2. Exportation des données
L’exportation se fait en cliquant sur le bouton "Exportation". Le système lance une requête au
serveur qui transfert le contenu de chaque table dans la BD vers un fichier XML portant le
même nom. Une fois le transfert terminé, le système affiche une liste de fichiers
téléchargeables comme indiquée dans la figure 3.13. Dans le cas d’échec, le système affiche
un message d’erreur.
Figure 3.13. Capture d’écran de l’opération d’exportation des données.
51
3.2.3. Gestion des Affectations
Cette fonctionnalité permet à l’administrateur d’affecter les matières aux enseignants (charge
semestrielle). L’administrateur peut soit ajouter ou supprimer des séances selon le besoin. La
figure 3.14 représente l’écran permettant de réaliser cette opération.
Figure 3.14. Gestion des affectations matières-enseignants.
a. L’ajout d’une affectation
A partir de la zone des paramètres, l’administrateur saisit les informations nécessaires à la

création d’une séance (groupe, matière, nature de la séance…etc.), puis valide l’action en
cliquant sur le bouton "+" (voir figure 3.14). Une requête est envoyée au serveur qui
enregistre l’affectation ajoutée. A la fin, le système affiche un message de notification.
b. La suppression d’une affectation
La suppression d’une affectation se fait en sélectionnant une affectation depuis la liste de

recherche puis en validant l’action par un clique sur le bouton « - » (voir figure 3.14). Une
requête est envoyée au serveur qui annule l’affectation sélectionnée. A la fin, le système
affiche un message de notification.
52
3.2.4. Gestion des comptes-utilisateurs
Cette opération permet de modifier les noms d’utilisateurs, leurs mots de passe et l’état de
leurs comptes (actifs ou bloqués). L’administrateur peut utiliser un filtre de recherche par
mot-clé afin de minimiser la liste des utilisateurs affichés comme indiqué dans la figure 3.15.
Figure 3.15. Capture d’écran de la zone de recherche (filtre de recherche).
L’administrateur peut maintenant sélectionner un utilisateur depuis la liste de recherche puis

éditer son détail personnel pour une éventuelle modification en cliquant sur le bouton
« éditer ». Les nouvelles données seront saisies puis enregistrées en cliquant sur le bouton
« sauvegarder », où une requête est envoyée au serveur qui sauvegarde les changements
apportés dans la BD (voir figure 3.16). A la fin de l’opération, le système affiche un message
de notification.
Figure 3.16. Edition et modification d’un compte-enseignant.
53
3.3. Les fonctionnalités exécutées par les chefs de spécialités
Après l’authentification, un chef de spécialité peut importer les données (notes et absences),
comme indiqué dans la figure 3.17.
L’importation des notes / absences se fait en sélectionnant d’abord une matière et un groupe
depuis la liste des matières et des groupes de chaque spécialité, ce qui permet de charger les
notes et les absences des étudiants du groupe et de la matière sélectionnés. Le chef de
spécialité peut maintenant télécharger les données en cliquant sur le bouton « enregistrer »
(voir figure 3.17), où une requête est envoyée au serveur qui génère un fichier contenant les
données demandées.
Figure 3.17. Importation des données par le chef de spécialité
3.4. Les fonctionnalités exécutées par les enseignants
Tout comme l’administrateur, un enseignant peut exécuter ses fonctionnalités après s’être
authentifié. Le système charge alors la liste des matières enseignées par l’utilisateur connecté.
En changeant de matière, la liste des groupes changent également afin de permettre la gestion
des notes et des absences des étudiants.
3.4.1. Gestion des notes
La gestion des notes se fait en sélectionnant d’abord une matière et un groupe depuis la liste
des matières et des groupes enseignés, ce qui permet de charger les notes des étudiants du
54
groupe et de la matière sélectionnés. L’enseignant peut maintenant remplir la grille des notes
et ensuite enregistre ces données en cliquant sur le bouton « enregistrer » (voir figure 3.18),
où une requête est envoyée au serveur qui sauvegarde les changements apportés dans la BD.
A la fin, le système affiche un message de notification.
Figure 3.18. Saisie des notes.
3.4.2. Gestion des absences
Tout comme dans la gestion des notes, la gestion des absences se fait aussi en sélectionnant
d’abord une matière et un groupe depuis la liste des matières et des groupes enseignés. Le
système charge les absences des étudiants du groupe et de la matière sélectionnés dans le mois
en cours. L’enseignant peut maintenant remplir la grille des absences en créant, modifiant et
supprimant des colonnes ; une colonne ici représente les absences d’un groupe dans une date
précise (voir figure 3.18). La gestion des absences se fait donc colonne par colonne où à
chaque action, une requête est envoyée au serveur qui sauvegarde les changements apportés
dans la BD. A la fin, le système affiche un message de notification.
55
Figure 3.19. Saisie des absences.
3.5. Les fonctionnalités exécutées par les étudiants

Après s’être authentifié, un étudiant peut consulter ses données (notes et absences), comme
indiqué dans la figure 3.20.
Figure 3.20. Consultation des notes.
4. Phase de tests
Une fois l’implémentation de l’application terminée, le processus génie logiciel recommande
de procéder à une phase de tests qui permettent d’évaluer la qualité du logiciel développé.
56
Ainsi, nous considérons les tests suivants : tests unitaires, test d’intégration, tests fonctionnels,
tests de configuration, les tests de performances et enfin le test d’installation. La table 3.1
résume cet aspect.
Test Objectif Test réalisé ?

Test unitaire Tester individuellement les composants de
l’application. 
Test d’intégration Valider l’intégration des modules entre eux et
dans leur environnement définitif.

Test fonctionnel Vérifier la conformité de l’application
développée avec le cahier des charges. 
Test de configuration Tester la capacité de l’application à s’adapter
au renouvellement fréquent des machines.
Test de performances Valider la capacité des serveurs à supporter des
charges d’accès importantes.
Test d’installation Contrôler les aspects liés à la documentation et
à l’installation.
Table 3.1. Table des tests.
En consultant la table 3.1, on constate que certains tests n’ont pas été réalisés ; les
justifications de ce choix sont données dans la table 3.2.
Test Raison de sa non-réalisation

Test de configuration Nous n’avons pas suffisamment de temps pour mettre
l’application développée en marche pendant une période d’essai.
Test de performances Comme l’application n’a pas été testée sur un serveur distant réel
(comme celui de notre université où l’on planifie à l’héberger),
nous ne pouvons juger cet aspect.
Test d’installation Nous n’avons pas suffisamment de temps pour écrire la
documentation puis voir son adéquation avec l’installation
(pratiquement, ce projet a été commencé le moi d’avril).
Table 3.2. Table des justificatifs pour les tests non-réalisés.
57
5. Evaluation de l’application réalisée
A ce stade, nous nous demandons sur les éléments apportés en développant cette application.
Ainsi, nous allons énumérer les points de force et de faiblesse afin que notre jugement soit
objectif autant que possible.
5.1. Les points de force de l’application développée
Sans doute, l’application que nous avons réalisée est bénéfique dans le sens où elle permet de:
- Gérer les absences des étudiants de manière souple, ce qui n’était pas supporté par le
système actuel.
- Distribuer l’effort de saisie des notes et des absences entre plusieurs acteurs au lieu de
centraliser cette tâche (un seul agent qui fait tout).
- Dégager le service de scolarité de contacter les étudiants qui doivent directement
contacter les enseignants en cas d’erreurs de saisie ou de d’absences justifiées.
- Amélioration de la qualité de service à travers une interface graphique riche, simple à
utiliser et qui facilite la saisie tout en assurant l’interactivité avec l’utilisateur grâce à
la technique AJAX.
- Comme le classement des universités est essentiellement basé sur le nombre de clicks
dans leurs sites officiels, nous pensons que l’hébergement de notre application dans le
serveur de notre université pourrait améliorer significativement ce paramètre,
notamment si l’on réussit à la généraliser pour les autres départements.
5.2. Les points de faiblesse de l’application développée
Malgré les avantages cités, nous avons pu aussi constater les points négatifs suivants :
- La décentralisation de gestion – malgré son avantage – peut poser le risque de
l’incohérence des données. Effectivement, il se peut que l’un des enseignants ne fait
pas de saisie des données ; cela conduit à une BD incohérente (son contenu ne reflète
pas la réalité).
- Le déploiement de notre application dépend du serveur de l’université ; pratiquement,
ce dernier souffre souvent des problèmes techniques, ce qui influence directement le
fonctionnement du système.
6. Conclusion
Ce chapitre a été consacré à la phase d’implémentation de l’application en respectant la

modélisation établie dans le chapitre précédent, où nous avons présenté les différentes
techniques, outil et langages utilisés lors de sa réalisation tout en montrant le rôle de chacun
58
d’eux. Nous avons également procédé à une description textuelle des différentes
fonctionnalités du système réalisé, dotée d’un ensemble de figures illustratives. Enfin, nous
avons montré les tests réalisés sur l’application développée afin de nous assurer de sa qualité.
59
Conclusion Générale
Conclusion Générale
L’évolution et le progrès technologique ainsi que la puissance croissante du matériel offre

l’opportunité de développer des applications simples, de manipulation facile mais pouvant
améliorer considérablement notre quotidien. C’est ainsi que dans le cadre de notre projet de
fin d’étude, nous avons choisi le thème qui nous a permis de développer une application Web
pour d’une part se familiariser avec ce type d’applications et par la même occasion, offrir au
personnel et aux étudiants la possibilité de disposer du service qui va leur permettre de gérer
et de consulter les notes et les absences d’étudiants de l’année en cours.
L’utilisation du langage de modélisation UML et certains outils de développement nous ont
permis de surmonter certaines difficultés et d’obtenir à la fin une application simple et facile
à manipuler.
En perspective, nous pensons qu’il sera très pratique de compléter les fonctionnalités
inachevées telles que la possibilité d’automatiser le processus de gestion des fiches des veux
(projets de fin d’étude, choix des spécialités lors du passage d’un niveau d’étude à un autre,
demandes des matières à enseigner…etc.). Nous pensons également qu’il sera utile d’adapter
l’affichage du contenu des pages selon le dispositif sur lesquelles elles sont exécutées,
notamment pour les Smartphone et les tablettes qui sont devenus de plus en plus utilisées dans
la vie quotidienne.
60
Bibliographie et Webographie
[1] https://fr.wikipedia.org/wiki/UML_(informatique).
[2] https://www.omg.org/spec/UML/About-UML/
[3] https://laurent-piechocki.developpez.com/uml/tutoriel/lp/cours/
[4] Nadia Abdat et Latifa Mahdaoui, UML outil pour le génie logiciel. Edition pages
bleues internationales, ISBN : 978-9947-850-01-5 (2014).
[5] https://www.ganttproject.biz/
[6] Benoît Charroux, Aomar Osmani et, Yann Thierry-Mieg, UML2 pratique de la
modélisation. Edition Pearson, ISBN: 978-2744074660 (2010).
[7] Pierre Alain Muller et Nathalie Gaertner, Modélisation objet avec UML. Edition
Eyrollos, ISBN : 2-212-09122-2, 2ème édition (2000).
[8] Pascal Roques. UML 2 modéliser une application web. Edition Eyrolles, USBN
978-2-212-12389-0, 4ème édition (2008).
[9] Pascal Roques. UML 2 par la pratique : Etude de cas et exercices corrigés. Edition
Eyrolles, ISBN 978-2212675658, 8ème édition (2018).
61

Langue

Ilovepdf Merged

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ilovepdf Merged

Transféré par

Droits d'auteur :

Formats disponibles

République Algérienne Démocratique et Populaire

Ministère de L'Enseignement Supérieur et de la Recherche Scientifique

Pour l'obtention du diplôme de Master en Informatique

Application web pour la gestion du

Soutenu le 13/06/2018 devant le jury constitué de :

Année universitaire : 2017– 2018

Louange à Allah, de me donner la force et la patience de survivre, ainsi que le

Ainsi j’adresse mes plus sincères remerciements et ma profonde reconnaissance à

J'exprime toute ma reconnaissance à Monsieur Dr. Bourouis Abd-Elhabib pour

Mes amis, pour leurs encouragements permanents, et leur soutien moral.

Table 2.1. Liste des classes d’acteurs avec leurs rôles…………….19

Table 3.1. Table des test………….. ………………………………57

Application web, application Internet Riche, architecture client/serveur, Modélisation UML.

L’évolution des nouvelles technologies numériques (ordinateurs, Smartphones,

Historiquement, il y a eu plusieurs évolutions successives en programmation, d’où

2. Le langage de modélisation UML

UML ou « langage de modélisation unifié » est un langage de modélisation graphique à base

années 90 à penser d’inventer de nouvelles méthodes qui soient universellement acceptées

Figure 1.1. Evolution historique d’UML.

4. Les diagrammes d’UML

4.1. Les diagrammes de structure (ou encore statiques)

4.1.1. Le diagramme de classes

Le diagramme de classes montre la structure interne en fournissant une représentation

Figure.1.2. Exemple de diagramme de classes.

4.1.2. Le diagramme d’objets

Figure 1.3. Exemple de diagramme d’objets.

4.1.5. Le diagramme des paquets

Figure 1.4. Exemple de diagramme de paquets.

4.2. Les diagrammes de comportement

4.2.1. Le diagramme des cas d’utilisation

Les diagrammes de cas d’utilisation permettent de recueillir et d’organiser les besoins

Figure 1.5. Exemple de diagramme de cas d’utilisation.

4.2.2. Le diagramme d’états-transitions

Ce diagramme décrit le comportement interne d’un objet et la définition de tous les

Figure 1.6. Exemple de diagramme d’états-transitions.

4.2.3. Le diagramme d’activité

Les diagrammes d’activité servent à modéliser la partie dynamique du modèle et

Figure 1.7. Exemple de diagramme d’activité.

4.3. Les diagrammes d’interaction (ou dynamique)

Cette catégorie contient quatre (04) diagrammes : le diagramme de séquence, le diagramme

4.3.1. Le diagramme de séquence

Figure 1.8. Exemple de diagramme de séquences.

4.3.2. Le diagramme de communication

Figure 1.9. Exemple de diagramme de communication.

4.3.3. Le diagramme global d’interaction

Ce diagramme donne une vue d’ensemble d’interactions en mélangeant des diagrammes

Figure 1.10. Exemple de diagramme global d’interaction.

4.3.4. Le diagramme de temps

Figure 1.11. Exemple de diagramme de temps

5.1. Les avantages du langage UML

Les avantages d’UML peuvent être résumés comme suit [3]:

5.2. Les inconvénients du langage UML

Les inconvénients d’UML peuvent se résumer en [3]:

2. Le système de gestion actuel

Le système de gestion du département actuel consiste en une application monoposte,

Figure 2.1. Architecture du système de gestion du département actuel

3. Propositions pour l’amélioration du système actuel

4. Gestion de notre projet

Figure 2.2. Tâches de notre projet de fin d’étude.

5. Analyse préliminaire des besoins

5.1. Définition des acteurs et capture des besoins fonctionnels

Figure 2.3. Classes d’utilisateur de la future application.