République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université Abdelhamid Mehri Constantine 2
Faculté des Nouvelles Technologies de l’Information et la Communication
Département des Technologies des Logiciels et Systèmes d’Information
Projet de fin d’étude
pour l’obtention du diplôme de Licence en Informatique
Option : Génie Logiciel
SYSTÈME DE GESTION DES
ABSENCES
POUR UNIVERSITÉ INTELLIGENTE
Réalisé par :
Ouail Derghal
Aymen Belala
Dirigé par :
Dr. Zakaria Lakhdara
Remerciments
Nous tenons à remercier toutes les personnes qui ont contribué au
succès de ce projet et qui nous ont aidé lors de la rédaction de ce
mémoire.
Nous voudrions remercier dans un premier temps l’encadreur de ce
projet M. Zakaria Lakhdara, Professeur Adjoint à l’université
de Constantine 2, pour sa patience, sa disponibilité et ses conseils
pertinents, qui ont contribué à enrichir ce projet.
Nous remercions également l’équipe pédagogique de la faculté des
nouvelles technologies de l’information et de communication et les
résponsables de la formation Génie Logiciel, pour leurs efforts
durant les six semestres.
Nous tenons à témoigner toute notre reconnaissance à nos parents
et nos proches, pour leur soutien constant et leurs encouragements.
Merci
Table des matières
1 Introduction générale
1.1 Introduction générale . . . . . . . . . . . . . . .
1.2 Description du projet . . . . . . . . . . . . . . .
1.3 Problématique . . . . . . . . . . . . . . . . . .
1.4 Solution proposée . . . . . . . . . . . . . . . . .
1.5 Le génie logiciel . . . . . . . . . . . . . . . . . .
1.5.1 Les approches du génie logiciel . . . . .
1.6 Le langage de modélisation unifié - UML . . . .
1.6.1 Définition et historique . . . . . . . . .
1.6.2 L’importance de modélisation . . . . . .
1.6.3 Les usages d’UML . . . . . . . . . . . .
1.6.4 Les diagrammes d’UML . . . . . . . . .
1.7 Le processus unifié . . . . . . . . . . . . . . . .
1.7.1 Définition . . . . . . . . . . . . . . . . .
1.7.2 Les caractéristiques du processus unifié
1.7.3 L’objectif du processus unifié . . . . . .
1.7.4 L’architecture UP . . . . . . . . . . . .
1.8 Les activités du processus unifié . . . . . . . . .
1.8.1 Expression des besoins . . . . . . . . . .
1.8.2 Analyse . . . . . . . . . . . . . . . . . .
1.8.3 Conception . . . . . . . . . . . . . . . .
1.8.4 Implémentation . . . . . . . . . . . . . .
1.8.5 Test . . . . . . . . . . . . . . . . . . . .
1.9 Les phases du processus unifié . . . . . . . . . .
1.9.1 Analyse des besoins . . . . . . . . . . .
1.9.2 Élaboration . . . . . . . . . . . . . . . .
1.9.3 Construction . . . . . . . . . . . . . . .
1.9.4 Transition . . . . . . . . . . . . . . . . .
1.10 Conclusion . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
10
10
11
11
13
13
14
14
15
17
17
17
18
19
19
19
20
20
20
20
20
20
20
20
21
21
2 Analyse des besoins
2.1 Introduction . . . . . . . . . . . . . . . .
2.2 Expression des besoins . . . . . . . . . .
2.2.1 Cahier des charges . . . . . . . .
2.2.2 Identification des acteurs . . . .
2.2.3 Diagramme de contexte statique
2.2.4 Documentation des acteurs . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
22
22
24
25
26
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2.3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
28
29
29
29
33
41
49
3 Conception
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . .
3.2 Diagramme de classe conceptuel . . . . . . . . . .
3.2.1 Identification et documentation des classes
3.2.2 Diagramme de classes . . . . . . . . . . . .
3.3 Schéma et diagramme de la base de données : . . .
3.3.1 Schéma de la base de données . . . . . . . .
3.3.2 Diagramme de la base de données . . . . .
3.4 Scénario d’exécution . . . . . . . . . . . . . . . . .
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
50
50
50
50
64
66
66
68
70
77
4 Implémentation
4.1 Introduction . . . . . . . . . . . . . . . . . . . .
4.2 Environnement de développement . . . . . . . .
4.3 Base de données . . . . . . . . . . . . . . . . .
4.4 Application Web . . . . . . . . . . . . . . . . .
4.4.1 Language de programmation . . . . . .
4.4.2 La structure du projet . . . . . . . . . .
4.4.3 Captures de l’application Web . . . . .
4.5 Appareil de prise de présences . . . . . . . . . .
4.5.1 Raspberry PI . . . . . . . . . . . . . . .
4.5.2 La technologie de radio-identification . .
4.5.3 Conception de l’appareil . . . . . . . . .
4.5.4 Communication avec la base de données
4.6 Le projet API REST . . . . . . . . . . . . . . .
4.7 Le projet de l’appareil de prise de présences . .
4.8 Application mobile . . . . . . . . . . . . . . . .
4.8.1 Android . . . . . . . . . . . . . . . . . .
4.8.2 L’historique des versions d’Android . . .
4.8.3 Environnement de développement . . .
4.8.4 Communication avec la base de données
4.8.5 La structure du projet . . . . . . . . . .
4.8.6 Captures de l’application mobile . . . .
4.9 Conclusion . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
78
78
78
79
81
82
84
86
87
87
94
94
96
97
98
99
99
100
101
102
103
105
108
2.4
2.5
Identification des besoins . . . . . . . . . . .
2.3.1 Les besoins fonctionnels du projet . .
2.3.2 Les besoins non-fonctionnels du projet
Spécification des besoins . . . . . . . . . . . .
2.4.1 Identification des cas d’utilisation . . .
2.4.2 Diagrammes de cas d’utilisation . . .
2.4.3 Documentation des cas d’utilisation .
2.4.4 Diagrammes de séquence système . . .
Conclusion . . . . . . . . . . . . . . . . . . .
5 Conclusion générale
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
109
Table des figures
1.1
1.2
1.3
1.4
1.5
1.6
1.7
Les approches du génie logiciel. . . . . . . . .
StarUML version 3.1.1 . . . . . . . . . . . . .
Diagramme de classes du NodeJS v0.8.12 . .
Importance de la modélisation . . . . . . . .
Les usages du langage de modélisation unifié
Développement par itérations successives . . .
Le cycle de vie du processus unifié . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
12
13
14
15
18
19
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
Le diagramme de contexte statique. . . . . . . . . . . . . . . . . .
Diagramme de cas d’utilisation A1-Administrateur. . . . . . . . . .
Le diagramme de cas d’utilisation A2-Enseignant. . . . . . . . . .
Diagramme de cas d’utilisation A3-Responsable de formation. . . .
Diagramme de cas d’utilisation A4-Chef département. . . . . . . .
Diagramme de cas d’utilisation A5-Étudiant. . . . . . . . . . . . .
Diagramme de séquence système Consulter le relevé des absences. .
Diagramme de séquence système Consulter les statistiques. . . . . .
Diagramme de séquence système Faire l’appel. . . . . . . . . . . . .
Diagramme de séquence système Faire une réclamation. . . . . . .
Diagramme de séquence système Gérer les justifications (Accepter).
Diagramme de séquence système Justifier une absence. . . . . . . .
Diagramme de séquence système Ajouter un étudiant. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
30
31
31
32
32
42
43
44
45
46
47
48
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
Diagramme
Diagramme
Diagramme
Diagramme
Diagramme
Diagramme
Diagramme
Diagramme
Diagramme
4.1
4.2
4.3
4.4
4.5
4.6
Universal Database Manager . . .
Interaction avec la base de données
L’architecture client-serveur. . . . .
JetBrains IntellijIDEA . . . . . . .
Dépendances du projet Maven . .
Modèle . . . . . . . . . . . . . . . .
de classes . . . . . . . . . . . . . . . .
de la base de données . . . . . . . . . .
d’activité Ajouter un étudiant . . . . .
d’activité Consulter le relevé d’absence
d’activité Consulter les statistiques . .
d’activité Faire l’appel . . . . . . . . .
d’activité Faire une réclamation . . . .
d’activité Gérer les justifications . . .
d’activité Justifier une absence . . . .
.
.
.
.
.
.
.
.
.
.
.
.
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
65
69
70
71
72
73
74
75
76
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
80
80
81
82
83
84
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
4.25
4.26
4.27
Vue . . . . . . . . . . . . . . . . . . . . . . . . .
Contrôleur . . . . . . . . . . . . . . . . . . . . . .
Structure du projet de l’application Web . . . . .
Capture 1 de l’application Web . . . . . . . . . .
Raspberry PI Zero . . . . . . . . . . . . . . . . .
Dimensions de la Raspberry PI . . . . . . . . . .
Raspberry PI détaillée . . . . . . . . . . . . . . .
Connexion SSH à une Raspberry Pi . . . . . . .
General Purpose Input/Output interface (GPIO)
Module RFID-RC522 . . . . . . . . . . . . . . . .
Schéma de branchement . . . . . . . . . . . . . .
Données en format JSON . . . . . . . . . . . . .
Architecture de communication . . . . . . . . . .
Éditeur de code Vim . . . . . . . . . . . . . . . .
Architecture logicielle de l’Android . . . . . . . .
Android Studio version 4.0.1 . . . . . . . . . . .
Les dépendances de l’application mobile . . . . .
La structure du projet Android . . . . . . . . . .
Capture 1 de l’application mobile . . . . . . . . .
Capture 2 de l’application mobile . . . . . . . . .
Capture 3 de l’application mobile . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
85
85
86
87
89
90
93
93
94
95
96
97
99
101
102
103
104
105
106
107
Liste des tableaux
1.1
1.2
Les trois aspects d’un système d’information . . . . . . . . . . . . . . . . . . . . .
Regroupement des diagrammes par aspect . . . . . . . . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
15
17
La fiche descriptive de l’acteur administrateur . . . . . . . . . . . . . .
La fiche descriptive de l’acteur enseignant . . . . . . . . . . . . . . . .
La fiche descriptive de l’acteur responsable de formation . . . . . . . .
La fiche descriptive de l’acteur chef département . . . . . . . . . . . .
La fiche descriptive de l’acteur étudiant . . . . . . . . . . . . . . . . .
Fiche descriptive du cas d’utilisation Faire l’appel . . . . . . . . . .
Fiche descriptive du cas d’utilisation Faire une réclamation . . . .
Fiche descriptive du cas d’utilisation Justifier une absence . . . . .
Fiche descriptive du cas d’utilisation Ajouter un étudiant . . . . . .
Fiche descriptive du cas d’utilisation Consulter le relevé d’absence
étudiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.11 Fiche descriptive du cas d’utilisation Gérer les justifications . . . .
2.12 Fiche descriptive du cas d’utilisation Consulter les statistiques . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
pour un
. . . . . .
. . . . . .
. . . . . .
26
26
26
26
26
34
35
36
37
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
3.20
3.21
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
53
54
54
55
55
56
56
57
57
58
58
59
60
60
61
61
62
62
63
63
Les relations Class-to-Class . . . . . . . . . . . . . . .
Fiche descriptive de la classe Personne . . . . . . . . .
Fiche descriptive de la classe Administrateur . . . . .
Fiche descriptive de la classe Étudiant . . . . . . . . .
Fiche descriptive de la classe Enseignant . . . . . . . .
Fiche descriptive de la classe Chef département . . . .
Fiche descriptive de la classe Responsable de formation
Fiche descriptive de la classe Séance . . . . . . . . . .
Fiche descriptive de la classe Module . . . . . . . . . .
Fiche descriptive de la classe Groupe . . . . . . . . . .
Fiche descriptive de la classe Faculté . . . . . . . . . .
Fiche descriptive de la classe Spécialité . . . . . . . . .
Fiche descriptive de la classe Département . . . . . . .
Fiche descriptive de la classe Réclamation . . . . . . .
Fiche descriptive de la classe Justification . . . . . . .
Fiche descriptive de la classe Utilisateur Système . . .
Fiche descriptive de la classe Demande de suppression
Fiche descriptive de la classe Section . . . . . . . . . .
Fiche descriptive de la classe ActionÉtudiantSéance . .
Fiche descriptive de la classe Présence . . . . . . . . .
Fiche descriptive de la classe Absence . . . . . . . . .
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
39
40
3.22 Schéma de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Spécifications techniques de l’ordinateur 1 . . . . . . . .
Spécifications techniques de l’ordinateur 2 . . . . . . . .
Environnement de développement de l’application Web .
les versions de la Raspberry PI . . . . . . . . . . . . . .
Les méthodes HTTP . . . . . . . . . . . . . . . . . . . .
Les codes HTTP . . . . . . . . . . . . . . . . . . . . . .
Quelques versions d’Android . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
67
. 78
. 79
. 81
. 88
. 96
. 96
. 100
Chapitre 1
Introduction générale
1.1
Introduction générale
Les technologies de l’information et de la communication sont exploitées via différentes ressources techniques pour garantir une manipulation correcte et fiable des données, autrement
dit être capable de convertir, stocker, gérer, transmettre et communiquer des informations.
Les ressources techniques sont regroupées par les catégories suivantes :
• La microélectronique ;
• L’équipement informatique, comme les serveurs et les logiciels ;
• Les réseaux, les infrastructures et les systèmes de télécommunications ;
• Les terminaux de télécommunication.
Les services fournies par les Technologies de l’information et de la communication (TIC)s sont :
• Les services de transmission de données ;
• Les services informatiques ;
• Les services de communication ;
• Les services de commerce électronique.
Les NTICs sont largement exploitées dans plusieurs domaines, on peut citer par exemple le
vote et l’administration électronique dans le domaine de l’administration et la gouvernance,
les technologies de géolocalisation dans le domaine du transport, l’accessibilité numérique dans
le domaine des droits des personnes handicapées, dans l’éducation et l’enseignement par les
universités numériques qui est le sujet de ce projet.
1.2
Description du projet
La faculté des nouvelles technologies de l’information et de la communication est composée de
trois départements :
9
CHAPITRE 1. INTRODUCTION GÉNÉRALE
10
1. Le département MI qui gère les étudiants de la première et la deuxième année du tronc
commun.
2. Le département TLSI qui gère les étudiants des spécialités GL et SI.
3. Le département IFA qui gère les étudiants des spécialités SCI et TI.
Dans chaque département, les étudiants sont organisés en sections. Chaque section est composée de plusieurs groupes. Chaque groupe d’étudiants assiste à des séances de travaux dirigés (TD) et de travaux pratiques (TP) dont la présence est obligatoire. Dans ces séances, la
gestion des absences est effectuée manuellement par l’enseignant à travers une liste de présences.
Si l’étudiant est absent, il doit présenter une justification valable au niveau de l’administration
de son département.
A la fin du semestre, l’enseignant doit envoyer une liste des absences pour ses groupes à l’administration du département concerné afin d’établir la liste des étudiants exclus. Un étudiant
est dit exclus s’il a au maximum trois absences non justifiées ou cinq absences justifiées.
1.3
Problématique
Le tâche de prise des absences dans la faculté des nouvelles technologies de l’information et
de la communication est une tâche coûteuse en terme de temps car elle se fait d’une manière
manuelle à l’aide des listes imprimées et d’une feuille de présences.
Cette opération manuelle augmente le taux d’erreurs de la gestion des absences et des justifications et ne permet pas de maintenir la trace de ces information.
Comment peut-on trouver une solution aux limitations de la gestion des absences
manuelle à l’aide d’un système d’information ?
1.4
Solution proposée
La solution proposée est de concevoir et réaliser un système d’information pour gérer les absences d’une manière automatique dans la faculté des nouvelles technologies de l’information
et de la communication en utilisant les différentes ressources techniques afin de mettre en place
un système fiable qui répond aux besoins suivants :
• Permettre aux administrateurs du système la gestion des informations des étudiants, enseignants, modules et séances.
• Permettre aux chefs des départements la gestion différentes équipes pédagogiques.
• Permettre aux responsables de formations la consultation des statistiques.
• Permettre aux enseignants la gestion des absences et des justificatifs des étudiants.
• Permettre aux étudiants la consultation des relevés et la justification des absences.
CHAPITRE 1. INTRODUCTION GÉNÉRALE
1.5
11
Le génie logiciel
Le génie logiciel est la discipline qui s’intéresse aux procédures de développements des projets
logiciels dans le but de livrer un produit fiable qui répond aux besoins et exigences du client
tout en respectant les délais et les coûts.
Autrement dit, le GL se préoccupe des procédés de fabrication des logiciels.
• Le logiciel doit répondre aux besoins des utilisateurs ;
• Le logiciel doit être de qualité ;
• Les coûts doivent rester dans les limites prévues initialement ;
• Les délais de livraison ne doivent pas dépasser les délais prévues.
1.5.1
Les approches du génie logiciel
La discipline du génie logiciel comporte plusieurs activités et tâches, on peut citer les processus
de développement, la gestion des projets, la modélisation des besoins, la sécurité, la gestion des
risques ...etc
Les quatre approches essentielles du GL sont :
1. L’approche de l’Orienté Objet (OO) ;
2. La modélisation des besoins ;
3. L’étude des besoins ;
4. Le processus de développement.
Figure 1.1 : Les approches du génie logiciel.
CHAPITRE 1. INTRODUCTION GÉNÉRALE
12
L’approche orienté objet
L’orienté objet est un paradigme de programmation basé sur la notion d’objets. L’objet comporte les données dans la forme d’attributs et un comportement dans la forme de méthodes.
Ce modèle abstrait représente aussi la relation entre les objets (relation d’association, composition, héritage... etc). La plupart des langages de programmation modernes supporte ce paradigme, on peut citer Java, Python, JavaScript, PHP et autres.
La modélisation des besoins
La modélisation des besoins est une approche importante du génie logiciel, elle consiste à illustrer les besoins des utilisateurs à travers des diagrammes et des pictogrammes pour améliorer
la communication entre les membres de l’équipe de développement. Cette amélioration sert à
diminuer les erreurs et assurer la qualité du logiciel produit.
L’illustration des besoins se fait à la base des règles du modèle standard, en utilisant le Langage de modélisation unifié (Unified Modeling Language - UML) et à l’aide d’un outil
piloté par ordinateur faciliter la tâche de modélisation. Le logiciel de modélisation utilisé pour
réaliser les différents diagrammes de ce projet est StarUML.
Figure 1.2 : StarUML version 3.1.1
Processus de développement
Le processus de développement est une façon de définir les activités, les phases et la démarche
à suivre lors du développement du projet logiciel. Il est essentiel de suivre un processus de
développement afin de synchroniser les équipes de conception et de développement, éclaircir
les activités et les tâches de chaque membre de l’équipe, et de déterminer le but final du projet
(les délivrables).
L’étude des besoins
Cette approche consiste à étudier la faisabilité des besoins des utilisateurs.
CHAPITRE 1. INTRODUCTION GÉNÉRALE
1.6
1.6.1
13
Le langage de modélisation unifié - UML
Définition et historique
UML est un langage de modélisation utilisé dans le domaine du génie logiciel, il définie un
mécanisme standard de modélisation des systèmes d’information. Sa première apparition était
en 1994-1995.
En 1997, UML été adopté par l’OMG (Object Management Group) comme un standard de
modélisation des systèmes d’information.
En 2005, UML été publié par l’Organisation Internationale de Standardisation et adopté comme
un standard ISO.
L’utilisation d’un langage de modélisation par les concepteurs des systèmes d’information ne
facilite pas seulement la compréhension de la structure des futurs systèmes, mais aussi de comprendre des systèmes d’information existants.
La figure suivante représente la structure d’un système existant modélisé par un diagramme de
classes du langage de modélisation unifié.
Figure 1.3 : Diagramme de classes du NodeJS v0.8.12
CHAPITRE 1. INTRODUCTION GÉNÉRALE
1.6.2
14
L’importance de modélisation
La modélisation offre une illustration des besoins et exigences exprimés par les futur utilisateurs, cette illustration est le point de liaison entre l’analyse et l’implémentation du projet.
Figure 1.4 : Importance de la modélisation
1.6.3
Les usages d’UML
1. Visualisation : le but principal d’UML est de fournir une visualisation des besoins et
des différents aspects du futur système à travers des diagrammes.
2. Spécification : UML facilite la spécification des : acteurs, cas d’utilisation, classes, attributs et des opérations.
3. Construction : UML est aussi utilisé pour la construction des projets logiciels grâce à
la fonctionnalité de la génération du code pour différentes langages de programmation
(par exemple Java).UML permet de modifier le code sur les gabarits générés au lieu de
les définir de zéro.
4. Documentation : UML permet la documentation les différents diagrammes pour renforcer les spécifications du projet.
5. Maintenance : les modèles d’UML facilitent la compréhension des systèmes existants,
ça résulte une maintenue rapide et efficace de ces derniers.
CHAPITRE 1. INTRODUCTION GÉNÉRALE
15
Figure 1.5 : Les usages du langage de modélisation unifié
1.6.4
Les diagrammes d’UML
Chaque aspect du système d’information est modélisé par un ou plusieurs diagrammes du langage de modélisation unifié. La version 2.0 d’UML comporte 9 diagrammes.
Aspect
Statique
Dynamique
Fonctionnel
Description
Identifie les propriétés des objets et leurs liaisons avec les autres objets.
Définit le cycle de vie des objets en précisant : le comportement du système,
les différents états des objets et les événements qui déclenchent les changements d’états.
Précise les fonctionnalités liées aux objets.
Table 1.1 : Les trois aspects d’un système d’information
Diagramme de cas d’utilisation
Le digramme de cas d’utilisation modélise l’aspect fonctionnel du système d’information. Il
illustre les cas d’utilisation, les acteurs et leurs relations. C’est le diagramme principal du langage de modélisation unifié.
Diagramme de classes
Le diagramme de classes (DCL) représente les classes, ses définitions et les relations entre eux.
Chaque classe est représentée par un nom d’identification, des attributs qui comporte les données
de l’entité et des méthodes qui définissent le comportement de cette dernière. Le DCL modélise
l’architecture conceptuelle d’une vue statique .
CHAPITRE 1. INTRODUCTION GÉNÉRALE
16
Diagramme d’objets
Le diagramme d’objets (DO) permet d’éclaircir le diagramme de classes. Il représente les relations entre les objets dans la mémoire et facilite la détection de la redondance.
Diagramme d’activités
Le diagramme d’activités (DA) modélise l’enchaı̂nement normal de l’interaction de l’utilisateur
avec un cas d’utilisation, l’enchaı̂nement alternatif et les exceptions.
Diagramme de séquence
Le diagramme de séquence (DS) représente la succession chronologique des opérations invoquées
par un acteur. Il illustre les interactions entre les objets et les acteurs sur l’axe des temps.
Diagramme de composants
Le diagramme de composants (DCO) décrit l’architecture physique du système d’information
en terme de modules (ou composants) : fichiers sources, librairies, exécutables... etc. Il illustre
la mise en œuvre physique des modèles conceptuels avec l’environnement de développement.
Diagramme de déploiement
Le diagramme de déploiement (DD) modélise l’architecture du matériel et illustre les nœuds
hébergeant le système.
Diagramme de communication
Le diagramme de communication (DC) est une représentation simplifiée d’un diagramme de
séquence. Il illustre l’échange des messages entre les objets. Le diagramme de séquence et de
communication sont deux vue différentes mais logiquement équivalente d’un système d’information sur une même chronologie.
Diagramme d’états-transitions
Le diagramme d’états-transitions (DET) représente le cycle de vie des objets appartenant à
une même classe. La modélisation du cycle de vie des objets par un DET est essentielle pour
mettre en forme la dynamique du système d’information.
CHAPITRE 1. INTRODUCTION GÉNÉRALE
Aspect fonctionnel
• Diagramme de cas
d’utilisation
Aspect statique
17
Aspect dynamique
• Diagramme de classes
• Diagramme d’activité
• Diagramme d’objets
• Diagramme de
séquence
• Diagramme de composants
• Diagramme de
déploiement
• Diagramme de communication
• Diagramme de étatstransitions
Table 1.2 : Regroupement des diagrammes par aspect
1.7
1.7.1
Le processus unifié
Définition
Le processus unifié (UP) est un processus de développement des projets logiciels. Il est une
méthode générique, itérative et incrémentale formée de composants. UP possède des caractéristiques
partagées par les différentes variantes de ce dernier.
Les caractéristiques du processus de développement unifié sont :
1. Il est un processus itératif et incrémental ;
2. Il est centré sur l’architecture du système ;
3. Il se focalise sur les facteurs de risque les plus élevés ;
4. Il est piloté par les cas d’utilisation du langage de modélisation unifié.
1.7.2
Les caractéristiques du processus unifié
UP est itératif
L’itération est une répétition d’une séquence d’instructions à un nombre fixe ou tant qu’une
condition définie n’est pas vérifiée, pour but d’appliquer un traitement itératif sur des différentes
données.
Autrement dit, l’itération est une procédure qui exécute un groupe d’opérations de façon répétitive
afin d’accomplir une condition. Elle prend en compte un ou plusieurs cas d’utilisation et traite
en priorité les risques majeurs.
CHAPITRE 1. INTRODUCTION GÉNÉRALE
18
Figure 1.6 : Développement par itérations successives
UP est centré sur l’architecture
Le processus unifié est centré sur un modèle architectural basé sur des différentes vues ;
1. Une vue logique.
2. Une vue de composants.
3. Une vue de processus.
4. Une vue de déploiement.
UP est piloté par les cas d’utilisation
Le but principal d’un système d’information est de satisfaire les besoins du client, le processus
de développement est basé sur les cas d’utilisations qui spécifient les besoins.
Un cas d’utilisation permet d’illustrer un ou plusieurs besoins, l’ensemble des cas d’utilisation
décrivent les besoins fonctionnels du point de vue de l’utilisateur. Cet ensemble constitue le
modèle de cas d’utilisation.
UP focalise sur les risques majeurs
Le processus de développement unifié assure l’identification des facteurs de risque les plus
élevés qui sont de nature à bouleverser le plan, excéder le coût ou le délai du développement.
1.7.3
L’objectif du processus unifié
L’objectif principal du processus unifié est de maı̂triser la complexité des projets logiciel et de
répondre aux questions suivantes :
CHAPITRE 1. INTRODUCTION GÉNÉRALE
19
1. QUI participe au projet ?
2. QUOI , le produit résultant ?
3. QUAND le produit sera livré ?
4. COMMENT doit-il être réalisé ?
1.7.4
L’architecture UP
Le processus unifié est structuré selon une architecture bidirectionnelle représentées sur deux
axes :
1. L’axe horizontal : c’est l’axe des temps, il illustre le déroulement du cycle de vie du
processus de développement.
2. L’axe vertical : représente l’enchaı̂nement des activités.
Figure 1.7 : Le cycle de vie du processus unifié
1.8
1.8.1
Les activités du processus unifié
Expression des besoins
L’expression des besoins consiste à définir et recenser les besoins fonctionnels et non fonctionnels du client afin d’élaborer le modèle des cas d’utilisation qui sera traduit par l’équipe du
développement en fonctionnalités.
CHAPITRE 1. INTRODUCTION GÉNÉRALE
1.8.2
20
Analyse
Le modèle d’analyse assure une spécification détaillée du modèle de cas d’utilisation, il est écrit
dans le langage des développeurs afin de faciliter la compréhension des cas d’utilisation aussi
que la maintenance et la mise à jour du système.
L’analyse permet de définir une architecture primaire du futur système d’information. Les documents résultants de l’activité de conception seront la plateforme de la conception.
1.8.3
Conception
La conception permet d’acquérir une compréhension approfondie de l’architecture du système
d’information. Elle est le point de départ de l’étape d’implémentation : elle permet de la décomposer
en sous-systèmes et de l’abstraire.
1.8.4
Implémentation
L’implémentation est l’étape de construction des sous-systèmes transcrits dans l’étape de conception, l’équipe de développement traduit les spécifications et les besoins du client en fonctionnalités tout en respectant l’architecture générale conçue et mise en place durant les autres activités.
Cette étape consiste à construire le code source du système d’information pour le transformer
en livrable qui répond aux besoins du client et offre une solution au problème posé.
1.8.5
Test
Le test est une activité importante durant le cycle de vie du processus de développement, elle
permet la vérification des résultats de l’implémentation et la détection des erreurs pour une
intervention efficace.
Les tests doivent être planifiés pour chaque itération du processus et implémentés par des cas
de testes, les résultats de cette activité sont prise en considération dans les autres itérations.
1.9
1.9.1
Les phases du processus unifié
Analyse des besoins
Comme son nom l’indique, cette phase consiste à analyser les besoins principaux du point de
vue de l’utilisateur. Elle permet d’élaborer une architecture générale du système à base des
besoins, identifier les risques majeurs et mettre en place les délais et les coûts de réalisation du
système d’information.
1.9.2
Élaboration
La phase d’élaboration dépend des résultats de la phase d’analyse des besoins. Elle permet de
préciser les cas d’utilisation et de concevoir l’architecture du système d’information.
1.9.3
Construction
Dans cette phase, le produit sera construit à base des spécifications et des cas d’utilisations
définis par le client. C’est la mise en place du système à base de l’architecture conçue.
CHAPITRE 1. INTRODUCTION GÉNÉRALE
1.9.4
21
Transition
La phase de transition livre le produit logiciel en version bêta qui sera testée par les utilisateurs. Le but des testes est de détecter les défauts de conception et de construction.
Dans cette phase du processus de développement : une formation des utilisateurs et un service
d’assistances pour accompagner les clients sont nécessaire ainsi que la correction des anomalies
et les défauts détectés.
1.10
Conclusion
Dans ce chapitre intitulé : Introduction générale on a présenté une description du projet
et le problème posé afin de trouver une solution qui convient à ce dernier. On a aussi parlé du
langage de modélisation unifié qui offre un moyen de visualisation standard et qui sera utilisé
tout au long de ce projet. On a cité le processus unifié, ses activités et ses phases. La conception et le développement de ce projet seront réalisés à la base des phases et des activités du
processus unifié.
Chapitre 2
Analyse des besoins
2.1
Introduction
L’analyse des besoins est la première étape du processus de développement unifié, elle consiste
à spécifier les besoins fonctionnels et non-fonctionnels du client, identifier les différents acteurs
et illustrer l’aspect fonctionnel du système à base du langage de modélisation unifié.
2.2
2.2.1
Expression des besoins
Cahier des charges
Le cahier des charges (CDC) est une forme de contrat entre l’équipe de développement de
la solution et le client. Il décrit des besoins et les exigences du client et il sera utilisé comme
une référence pour réponde à ces derniers.
Il existe deux types de cahier des charges :
1. Un cahier des charges technique (CDCT) : il s’intéresse particulièrement aux exigences et contraintes techniques du produit.
2. Un cahier des charges fonctionnel (CDCF) : il s’intéresse que sur les besoins fonctionnels. Les exigences sont exprimées en terme de besoins et de services et non pas en
terme de solutions et de moyens de réalisation.
Les besoins des utilisateurs de ce projet sont exprimé par un cahier des charges technique.
Cahier des charges du projet
• Présentation et contexte du projet :
1. La description du projet est citée dans le chapitre 1 : Introduction générale.
2. Contexte du projet : une application mobile, un site Web et un appareil électronique.
3. Objectif du projet : automatiser la tâche de prise de présences et offrir une interface de gestion et de visualisation du système d’information.
22
CHAPITRE 2. ANALYSE DES BESOINS
23
• Besoins :
– Administrateur :
1.
2.
3.
4.
Ajout,
Ajout,
Ajout,
Ajout,
modification,
modification,
modification,
modification,
et
et
et
et
suppression
suppression
suppression
suppression
des
des
des
des
étudiants ;
enseignants ;
modules ;
séances.
Ces fonctionnalités doivent être accessibles via Internet à travers une page web.
– Chef département :
1.
2.
3.
4.
Affectation des séances aux enseignants ;
Gestion des justifications ;
Établissement de la liste des étudiants exclus ;
Consultation des statistiques.
Ces fonctionnalités doivent être accessibles via Internet à travers une page web.
– Responsable de formation :
1. Consultation des statistiques.
Cette fonctionnalité doit être accessibles via Internet à travers une page web.
– Enseignant :
1.
2.
3.
4.
5.
6.
7.
Modification et suppression du profil ;
Faire l’appel pour un groupe (en exploitant les nouvelles technologies) ;
Modification du relevé d’absences d’un étudiant ;
Enregistrement de la Justification d’une absence d’un étudiant ;
Consultation du relevé des absences d’un groupe ou d’un étudiant ;
Établissement de la liste des étudiants exclus ;
Consultation des statistiques pour les groupes.
Ces fonctionnalités doivent être accessibles via Internet á travers une application
mobile.
– Étudiant :
1. Consultation du relevé d’absences ;
2. Justification d’une absence.
Ces fonctionnalités doivent être accessibles via internet á travers une page web ou
application mobile.
• Contraintes :
– L’application Web doit être implémentée en JavaEE ;
– L’application mobile doit être native et développée en Java ;
– La base de données doit implémenter le modèle relationnel et interrogée par le
language SQL ;
– L’appareil électronique doit être construit à la base d’une Raspberry PI ;
– L’appareil électronique doit utiliser la technologie de la radio-identification.
CHAPITRE 2. ANALYSE DES BESOINS
24
• Résultats attendus :
– Développement du site Web
– Développement de l’application mobile
– Développement d’une Applicaition Programming Interface (API)
– Conception et réalisation de l’appareil électronique
– Conception et mise en service de la base de données
2.2.2
Identification des acteurs
Définition
Le but principal de la conception et la construction des systèmes d’information est de répondre
aux besoins des utilisateurs. L’acteur détermine la façon dont le système sera utilisé, il est
considéré comme le point de départ de la modélisation de l’architecture du système conçu.
Un acteur peut être :
• Un rôle joué par un utilisateur direct qui invoque une intéraction avec le système ;
• Un système externe qui interagit avec le system en cours de développement ;
• Un appareil externe qui interagit avec le système ;
• Le temps est considéré comme acteur quand il s’agit des éventements exécutes régulièrement
après un certain intervalle de temps.
Il faut bien noté que l’acteur est le rôle joué par l’utilisateur et n’est pas la personne qui joue
ce rôle.
Identification des acteurs
L’identification des acteurs est l’activité la plus importante durant l’analyse des besoins. Cette
activité peut durer tout au long du processus de développement.
Le point de départ de l’identification des acteurs est le cahier des charges qui exprime les exigences du client. Le CDC ne couvre pas tous les acteurs du qui interagissent avec le système.
L’identification des besoins et des classes peut révéler d’autres acteurs, aussi que la modélisation
des différents aspects du système.
On peut identifier les acteurs potentiels du système en posant les questions suivantes :
1. Qui sont les acteurs principaux du système ?
2. Qui sont les acteurs secondaires du système ?
3. Qui invoque les interactions avec le système ?
4. Quels sont les systèmes et appareils externes qui interagissent avec le système
sous-développement ?
CHAPITRE 2. ANALYSE DES BESOINS
25
La liste suivante représente les acteurs du système de gestion des absences de la faculté NTIC :
1. Administrateur
2. Responsable de formation
3. Chef département
4. Enseignant
5. Étudiant
2.2.3
Diagramme de contexte statique
Le diagramme de contexte statique identifie l’environnement extérieur du système en représentant
les interactions des acteurs avec ce dernier.
Figure 2.1 : Le diagramme de contexte statique.
CHAPITRE 2. ANALYSE DES BESOINS
2.2.4
Documentation des acteurs
Les fiches descriptives suivantes documentent les acteurs du futur système.
Acteur
Type
Description
A1-Administrateur
Acteur principal et concret.
L’acteur administrateur utilise le système principalement pour gérer les
comptes des autres utilisateurs : ajouter des nouveaux comptes, modifier et
supprimer des comptes existants. Afin de garantir ses fonctionnalités, l’administrateur doit être authentifié par l’application Web.
Table 2.1 : La fiche descriptive de l’acteur administrateur
Acteur
Type
Description
A2-Enseignant
Acteur principal et concret. Il généralise les deux acteurs A3-Responsable de
formation et A4-Chef département
L’acteur enseignant utilise le système pour gérer les absences et consulter
des statistiques des étudiants de ses groupes. Il doit être authentifié par
l’application mobile afin qu’il peut utiliser ses fonctionnalités.
Table 2.2 : La fiche descriptive de l’acteur enseignant
Acteur
Type
Description
A3-Responsable de formation
Acteur principal et concret. Il spécifie l’acteur A2-Enseignant.
Plus que les fonctionnalités de l’acteur enseignant, le responsable de formation peut consulter des statistiques de tous les étudiants de la formation. Il
doit être authentifié par l’application Web pour utiliser ses fonctionnalités.
Table 2.3 : La fiche descriptive de l’acteur responsable de formation
Acteur
Type
Description
A4-Chef département
Acteur principal et concret. Il spécifie l’acteur A2-Enseignant.
Plus que les fonctionnalités de l’acteur enseignant, le chef département peut
consulter des statistiques de tous les étudiants de la formation, affecter les
séances et gérer les justifications. Il doit être authentifié par l’application
Web pour utiliser ses fonctionnalités.
Table 2.4 : La fiche descriptive de l’acteur chef département
Acteur
Type
Description
A5-Étudiant
Acteur principal et concret.
L’acteur étudiant utilise le système pour consulter et justifier ses absences,
marquer ses présences et envoyer ses réclamations à l’administration. Il doit
être authentifié par l’application mobile afin qu’il peut utiliser ses fonctionnalités.
Table 2.5 : La fiche descriptive de l’acteur étudiant
26
CHAPITRE 2. ANALYSE DES BESOINS
2.3
27
Identification des besoins
Un besoin est une exigence spécifiée par le client ou l’équipe de développement et citée dans le
cahier des charges. Il existe deux types de besoins :
1. Un besoin fonctionnel (BF) est un besoin précisé par le client dans le cahier des
charges, ce besoin requis par le client n’est pas négociable et il s’appelle un besoin primaire.
2. Un besoin non-fonctionnel (BNF) est aussi une exigence du client, sauf que cette
dernière est soit optionnelle ou une contrainte liée à l’implémentation. Un BNF peut être
spécifié par le client et/ou par l’équipe de développement.
2.3.1
Les besoins fonctionnels du projet
• Le système doit être accessible par :
– L’étudiant à travers une application mobile.
– L’enseignant à travers une application mobile.
– Le chef département à travers une application Web.
– Le responsable de formation à travers une application Web.
– L’administrateur à travers une application Web.
Le système doit permettre :
• Á l’administrateur :
– D’ajouter, modifier et supprimer des étudiants ;
– De consulter la liste des étudiants ;
– D’ajouter, modifier ou supprimer des enseignants ;
– De consulter la liste des enseignants ;
– D’ajouter, modifier ou supprimer des modules ;
– De consulter la liste des modules ;
– D’ajouter, modifier ou supprimer des séances ;
– De consulter la liste des séances ;
– D’ajouter, modifier ou supprimer des administrateurs ;
– De consulter la liste des administrateur.
• Au chef département :
– D’affecter des séances au enseignants ;
– De gérer des justifications ;
– D’établir la liste des étudiants exclus ;
– De consulter des statistiques.
• Á l’étudiant :
CHAPITRE 2. ANALYSE DES BESOINS
– De consultation le relevé d’absence ;
– De justification une absence.
• Á l’enseignant :
– De modifier son profile ;
– De faire l’appel ;
– De modifier le relevé d’absence d’un étudiant ;
– D’enregistrer une justification ;
– De consulter le relevé d’absence d’un groupe ou un étudiant ;
– D’établir la liste des étudiants exclus ;
– De consultation des statistiques.
• Au responsable de formation :
– De consulter des statistiques.
2.3.2
Les besoins non-fonctionnels du projet
• Les utilisateurs du système doivent être authentifiés.
• L’application Web doit être implémentée en JavaEE.
• L’application mobile doit être native et développée en Java.
• La base de données doit implémenter le modèle relationnel et interrogée par le langage
SQL.
• L’appareil électronique doit être construit à la base d’une Raspberry PI.
• L’appareil électronique doit utiliser la technologie de la radio-identification.
28
CHAPITRE 2. ANALYSE DES BESOINS
2.4
2.4.1
29
Spécification des besoins
Identification des cas d’utilisation
Un cas d’utilisation est une série des interactions d’un acteur avec le système pour accomplir une tâche précise. Les cas d’utilisation décrivent ce que le système doit faire mais ils ne
spécifient pas comment le système fait l’interaction.
L’identification des cas d’utilisation est faite à la base du cahier des charges, des spécifications
et des besoins du client. La documentation et la modélisation des cas d’utilisation permet une
meilleure compréhension du système.
La liste suivante identifie 7 cas d’utilisation qui seront plus-tard documentés et modélisés par
les différents diagrammes d’UML :
1. Le cas d’utilisation Faire l’appel invoqué par l’acteur A2-Enseignant.
2. Le cas d’utilisation Faire une réclamation invoqué par l’acteur A5-Étudiant.
3. Le cas d’utilisation Justifier une absence invoqué par l’acteur A5-Étudiant.
4. Le cas d’utilisation Ajouter un étudiant invoqué par l’acteur A1-Administrateur.
5. Le cas d’utilisation Consulter le relevé d’absence invoqué par l’acteur A2-Enseignant.
6. Le cas d’utilisation Gérer les justifications invoqué par l’acteur A4-Chef département.
7. Le cas d’utilisation Consulter les statistiques invoqué par l’acteur A2-Enseignant.
2.4.2
Diagrammes de cas d’utilisation
Le Diagramme de cas d’utilisation (DCU) modélise les différents cas d’utilisation identifiés en
analysant le cahier des charges. Il illustre aussi les relations entre les acteurs et les cas d’utilisation. Un cas d’utilisation est représente par une ellipse.
Il existe 3 types de relations modélisées par le diagramme de cas d’utilisation :
1. La relation Acteur-Acteur : elle illustre la relation entre deux acteurs, cette relation est
modélisée par une flèche vide. Le sens de la flèche indique le type de relation :
• Une Généralisation.
• Une Spécification.
2. La relation Acteur-Cas d’utilisation : elle modélise la relation entre un acteur et un
cas d’utilisation par une ligne droite, la première extrémité de la ligne spécifie l’acteur
qui invoque le cas d’utilisation et la deuxième extrémité indique le cas d’utilisation invoqué.
3. La relation Cas d’utilisation-Cas d’utilisation : elle modélise la relation entre deux
cas d’utilisation par une flèche, cette modélisation indique le type de relation entre ces
derniers :
• Une relation d’inclusion : un cas d’utilisation doit être obligatoirement inclus dans
l’autre cas.
• Une relation d’extension : un cas d’utilisation peut étendre l’autre cas.
Les figures suivantes représente les diagrammes des cas d’utilisation regroupés par acteur.
CHAPITRE 2. ANALYSE DES BESOINS
Figure 2.2 : Diagramme de cas d’utilisation A1-Administrateur.
30
CHAPITRE 2. ANALYSE DES BESOINS
Figure 2.3 : Le diagramme de cas d’utilisation A2-Enseignant.
Figure 2.4 : Diagramme de cas d’utilisation A3-Responsable de formation.
31
CHAPITRE 2. ANALYSE DES BESOINS
Figure 2.5 : Diagramme de cas d’utilisation A4-Chef département.
Figure 2.6 : Diagramme de cas d’utilisation A5-Étudiant.
32
CHAPITRE 2. ANALYSE DES BESOINS
2.4.3
33
Documentation des cas d’utilisation
La documentation des acteurs est faite par des fiches descriptives qui contiennent les information suivantes :
• Le nom de cas d’utilisation ;
• L’acteur qui invoque le cas d’utilisation ;
• Les pré-conditions qui doivent être vérifiées pour que le cas d’utilisation réussit son
exécution ;
• Le scénario nominal qui indique les étapes de déroulement du cas d’utilisation dans les
conditions normales ;
• Le scénario alternatif qui indique le comportement du système dans les conditions
anormales ;
• Le scénario d’exception qui indique le comportement du système en cas d’interruption
du scénario normal ;
• Les post-conditions qui indiquent le résultat après l’exécution du cas d’utilisation.
Les tableaux suivants documentent les 7 cas d’utilisation cités dans la section d’Identification
des cas d’utilisation.
CHAPITRE 2. ANALYSE DES BESOINS
Nom de cas d’utilisation
Acteur
Objectifs
Faire l’appel
A2-Enseignant
• Permettre aux enseignants de marquer la présence
manuellement en cas de malfonctionnement du
système de prise de présences automatique.
Pré-conditions
• L’enseignant doit être authentifié.
Scénario nominal
1. L’enseignant accède à la page ”faire l’appel manuellement” ;
2. Le système affiche la liste des séances ;
3. L’enseignant choisit la séance ;
4. Le système affiche la liste des étudiants ;
5. L’enseignant fait l’appel et envoie la liste de
présence des étudiants au système ;
6. Le système enregistre le relevé de présences des
étudiants.
Scénario alternatif
Scénario d’exception
/
• E.1. L’enseignant choisit d’annuler l’opération,
l’enchaı̂nement démarre après l’étape 3.
Post-conditions
• Le système met à jour le relevé de présence des
étudiants du groupe sélectionné.
Table 2.6 : Fiche descriptive du cas d’utilisation Faire l’appel
34
CHAPITRE 2. ANALYSE DES BESOINS
Nom de cas d’utilisation
Acteur
Objectifs
35
Faire une réclamation
A5-Étudiant
• Permettre aux étudiants de transmettre une
réclamation à l’administration du département à
travers le système.
Pré-conditions
• L’étudiant doit être authentifié.
Scénario nominal
1. L’étudiant accède à la page ”Faire une
réclamation” ;
2. Le système affiche un formulaire à remplir avec les
détails de réclamation ;
3. L’étudiant remplit le formulaire et l’envoie ;
4. Le système enregistre la réclamation et affiche un
message de succès ;
5. Le système enregistre la réclamation.
Scénario alternatif
/
Scénario d’exception
• E.1. L’étudiant remplit le formulaire de
réclamation sans l’envoyer. L’enchaı̂nement
démarre après l’étape 2.
• E.2. L’étudiant choisit d’annuler l’opération, l’enchaı̂nement démarre après l’étape 3.
Post-conditions
• Le système met à jour la liste des réclamations.
Table 2.7 : Fiche descriptive du cas d’utilisation Faire une réclamation
CHAPITRE 2. ANALYSE DES BESOINS
Nom de cas d’utilisation
Acteur
Objectifs
36
Justifier une absence
A5-Étudiant
• Permettre aux étudiants de transmettre une justification d’absence à l’administration du département
à travers le système.
Pré-conditions
• L’étudiant doit être authentifié.
Scénario nominal
1. L’étudiant accède à la page pour justifier une absence ;
2. Le système affiche l’application de galerie ;
3. L’étudiant choisit la photo de la justification ;
4. L’étudiant envoie la justification ;
5. Le système affiche un message de succès ;
6. Le système enregistre la justification.
Scénario alternatif
/
Scénario d’exception
• E.1. L’étudiant choisit une photo de la justification sans l’envoyer. L’enchaı̂nement démarre après
l’étape 3.
• E.2. L’étudiant choisi d’annuler l’opération, l’enchaı̂nement démarre après l’étape 3.
Post-conditions
• Le système met à jour la liste des justifications.
Table 2.8 : Fiche descriptive du cas d’utilisation Justifier une absence
CHAPITRE 2. ANALYSE DES BESOINS
Nom de cas d’utilisation
Acteur
Objectifs
37
Ajouter un étudiant
A1-Administrateur
• Permettre aux administrateurs de créer des
comptes pour les étudiants.
Pré-conditions
• L’administrateur doit être authentifié.
Scénario nominal
1. L’administrateur accède à la page pour ajouter un
étudiant ;
2. Le système affiche un formulaire pour remplir les
informations de l’étudiant ;
3. L’administrateur remplit le formulaire et l’envoie ;
4. Le système vérifie les informations ;
5. Le système enregistre les informations et affiche un
message de succès.
Scénario alternatif
• 4.a. Les informations entrées par l’administrateur
ne sont pas valides.
–
a. Le système affiche un message d’erreur
et redirige l’administrateur vers l’étape 2.
Scénario d’exception
• E.1. L’administrateur choisit d’annuler l’opération,
l’enchaı̂nement démarre après l’étape 3.
Post-conditions
• Le système met à jour la liste des étudiants.
Table 2.9 : Fiche descriptive du cas d’utilisation Ajouter un étudiant
CHAPITRE 2. ANALYSE DES BESOINS
Nom de cas d’utilisation
Acteur
Objectifs
38
Consulter le relevé d’absence pour un étudiant
A2-Enseignant
• Permettre aux enseignants de consulter les absences de ses étudiants.
Pré-conditions
• L’enseignant doit être authentifié.
Scénario nominal
1. L’enseignant choisit de consulter le relevé des absences ;
2. Le système affiche la liste des modules. ;
3. L’enseignant choisit le module qui convient ;
4. Appel au cas d’utilisation Rechercher ;
5. L’enseignant choisit l’étudiant concerné par la
consultation des absences ;
6. Le système affiche le relevé de l’étudiant choisi.
Scénario alternatif
• 3.a. L’enseignant choisit un étudiant qui n’appartient pas a ses groupes.
–
a. Le système affiche un message d’erreur
et redirige l’enseignant vers l’étape 2.
Scénario d’exception
• E.1. L’enseignant ne sélectionne pas un étudiant
après la recherche, l’enchaı̂nement démarre après
l’étape 2.
Post-conditions
/
Table 2.10 : Fiche descriptive du cas d’utilisation Consulter le relevé d’absence pour un
étudiant
CHAPITRE 2. ANALYSE DES BESOINS
Nom de cas d’utilisation
Acteur
Objectifs
39
Gérer les justifications - Accepter
A4-Chef département
• Permettre au chef département de gérer les justifications.
Pré-conditions
• Le chef département doit être authentifié.
Scénario nominal
1. Le chef département accède à la page ”Gérer les
justifications”.
2. Le système affiche une liste des justifications.
3. Le chef département choisit une justification.
4. Le système affiche la justification.
5. Le chef département clique sur le bouton ”Accepter
la justification”.
6. Le système affiche un message de succès ”justification acceptée”.
Scénario alternatif
/
Scénario d’exception
• E.1. Le chef de département choisi d’annuler
l’opération, l’enchaı̂nement démarre après l’étape
3.
Post-conditions
• Le système met à jour le statut de la justification.
Table 2.11 : Fiche descriptive du cas d’utilisation Gérer les justifications
CHAPITRE 2. ANALYSE DES BESOINS
Nom de cas d’utilisation
Acteur
Objectifs
40
Consulter les statistiques
A2-Enseignant
• Permettre à l’enseignant de consulter les statistiques pour ses groupes.
Pré-conditions
• L’enseignant doit être authentifié.
Scénario nominal
1. L’enseignant choisit e consulter les statistiques ;
2. Le système affiche la liste des modules ;
3. L’enseignant choisit le moule qui convient ;
4. Le système affiche la liste de ses groupes.
5. L’enseignant choisit le groupe qui convient.
6. Le système affiche des statistiques sur le groupe
sélectionné.
Scénario alternatif
/
Scénario d’exception
• E.1. L’enseignant choisi d’annuler l’opération, l’enchaı̂nement démarre après l’étape 2.
Post-conditions
/
Table 2.12 : Fiche descriptive du cas d’utilisation Consulter les statistiques
CHAPITRE 2. ANALYSE DES BESOINS
2.4.4
41
Diagrammes de séquence système
Le diagramme de séquence système modélise les différentes interactions de l’utilisateur avec le
système. Les interactions sont le scénario nominal, alternatif et le scénario d’exception décrits
dans la fiche descriptive du cas d’utilisation.
Le diagramme de séquence système est modélisé sur l’axe des temps, le premier axe illustre
l’acteur qui invoque le cas d’utilisation et le deuxième axe illustre le système.
Chaque interaction est illustrée par une flèche, chaque flèche représente un message. Il existe
différents types de messages modélisés par le diagramme de séquence système :
• Message synchrone : représenté par une flèche pleine.
• Message asynchrone : représenté par une flèche.
• Self-message : représenté par une flèche pleine, le point de départ et le point d’arrivé
doivent être sur le même axe des temps.
Le scénario alternatif est représenté par un cadre alt, le scénario d’exception par un cadre
break et l’appel à un autre cas d’utilisation par un cadre ref .
Les figures suivantes représentent les diagrammes de séquence système des 7 cas d’utilisations
cités dans ce chapitre.
CHAPITRE 2. ANALYSE DES BESOINS
Figure 2.7 : Diagramme de séquence système Consulter le relevé des absences.
42
CHAPITRE 2. ANALYSE DES BESOINS
Figure 2.8 : Diagramme de séquence système Consulter les statistiques.
43
CHAPITRE 2. ANALYSE DES BESOINS
Figure 2.9 : Diagramme de séquence système Faire l’appel.
44
CHAPITRE 2. ANALYSE DES BESOINS
Figure 2.10 : Diagramme de séquence système Faire une réclamation.
45
CHAPITRE 2. ANALYSE DES BESOINS
Figure 2.11 : Diagramme de séquence système Gérer les justifications (Accepter).
46
CHAPITRE 2. ANALYSE DES BESOINS
Figure 2.12 : Diagramme de séquence système Justifier une absence.
47
CHAPITRE 2. ANALYSE DES BESOINS
Figure 2.13 : Diagramme de séquence système Ajouter un étudiant.
48
CHAPITRE 2. ANALYSE DES BESOINS
2.5
49
Conclusion
Dans ce chapitre, on a établit l’étude préliminaire du futur système de gestion des absences de
la faculté des nouvelles technologies de l’information et de la communication.
Un cahier des charges technique a été rédigé afin de spécifier les besoins des utilisateurs, à
partir duquel, une liste des fiches descriptives est élaborée afin d’identifier et documenter les
différents acteurs.
Après la documentation des acteurs, les cas d’utilisation ont été identifiés et documentés par
des fiches descriptives.
En dernier lieu, un échantillon des cas d’utilisation a été sélectionné pour modéliser l’aspect
fonctionnel (digrammes de cas d’utilisation) et dynamique (diagrammes de séquence) du futur
système.
Chapitre 3
Conception
3.1
Introduction
La conception est la deuxième partie du cycle de développement d’un logiciel, elle consiste à
fournir des documents qui décrivent l’aspect structurel du futur système. Autrement dit, la
tâche de conception aide à mieux comprendre l’architecture générale.
Pour décrire le plan structurel, le système doit être basé sur un paradigme de programmation.
L’approche qu’on va suivre dans ce projet est l’orientée objet, elle définit les différentes entités
sous forme de classes qui seront instanciés plus tard en objets, ces objets interagissent entre
eux afin de donner un comportement au système.
3.2
3.2.1
Diagramme de classe conceptuel
Identification et documentation des classes
La première étape de la conception est l’identification et la documentation des classes. Comme
son nom l’indique, cette étape identifie les différentes entités du système qui peuvent être des
classes puis les documenter afin de donner le maximum des informations aux réalisateurs du
projet.
Une classe est une abstraction des objets, elle décrit la structure interne des données manipulées par cette dernière via des attributs et elle définit le comportement des objets instanciée
de cette classe via des méthodes.
Une classe peut avoir des relations vers une ou plusieurs classes, les relations peuvent être de
type composition, agrégation, association, généralisation...
Le tableau suivant définit en bref les relations class-to-class utilisés dans la conception du projet :
50
CHAPITRE 3. CONCEPTION
Relation
Association
51
Définition
L’association entre deux classes est représentée par une
ligne droite, elle indique une connexion bidirectionnelle
entre ces derniers.
L’agrégation est une forme spéciale de l’association, elle
indique le lien de composition entre deux classes avec
une contrainte, si l’agrégeant est supprimé, l’agrégé ne
va pas disparaı̂tre du système. Elle est représentée par
une ligne droite qui se termine par un losange vide.
Même définition que l’agrégation, sauf que si on supprime l’agrégeant, l’agrégé doit forcément disparaı̂tre du
système. Elle est représentée par une ligne droite qui se
termine par un losange plein.
La généralisation (appelée aussi Héritage) est une relation entre deux classes. Elle consiste à héritier la structure et le comportement de la classe mère aux classes
filles. Elle est représentée par une ligne droite qui finit
par une flèche vide.
La dépendance est une association directe avec un sens
unique entre deux classes, elle indique que les objets de
la première classe dépendent des objets de la deuxième
classe. On trouve cette relation souvent entre les Classes
et les Énumérations. Elle est représentée par une ligne
discontinue qui se termine par une flèche.
Agrégation
Composition
Généralisation
Dépendance
Table 3.1 : Les relations Class-to-Class
Identification des classes
L’identification des classes se fait par l’analyse des documentations précédentes (fiches descriptives des acteurs et des cas d’utilisation), le cahier des charges et les scénarios d’exécutions afin
d’élaborer une liste des classes candidates (qui peuvent être des entités du système).
La liste suivante représente les classes candidates du futur système :
1. Administrateur
8. Groupe
2. Étudiant
9. Faculté
3. Enseignant
10. Département
4. Chef de département
5. Responsable de formation
11. Spécialités
6. Séance
12. Réclamation
7. Module
13. Justification
La liste des classes identifiées dans les documentations précédentes n’est pas une liste finale,
elle peut être étendue par des classes abstraites, des classes entité et/ou des énumérations tout
dépend des besoins des utilisateurs et de la vision du concepteur pour fournir un document
complet qui représente la structure du futur système.
CHAPITRE 3. CONCEPTION
Les classes suivantes complémente la liste des classes candidate :
14. Personne
15. UtilisateurSystème
16. DemandeSuppression
17. Section
18. ActionÉtudiantEnseignant
19. Présence
20. Absence
Et les énumérations suivantes :
21. EnumDépartements
22. EnumSpécialités
23. EnumÉtatsRéclamations
24. EnumÉtatsJustifications
25. EnumGrades
52
CHAPITRE 3. CONCEPTION
53
Documentation des classes
Après l’identification des classes qui représentent les entités du système, une documentation
doit être mise en place afin de donner des informations sur les différentes classes : ses attributs,
ses relations, son rôle dans le système et sa complexité.
La visibilité des attributs doit être spécifiée dans la documentation, un attribut public est accessible par les objets qui sont instanciés de tous les classes du système, un attribut private
est accessible uniquement par les objets instanciés de la même classe et un attribut protected
est accessible uniquement par les objets instanciés de la classe mère ou des classes dérivées.
Les méthodes aussi ont aussi un degré de visibilité, les mêmes règles de visibilités des attributs
sont appliquées sur les méthodes qui définissent le comportement du système.
La complexité des classes est mesurée par le nombre d’attributs, nombre de relations et le rôle
de la classe.
La documentation des classes est présentée par des fiches descriptives, les tableaux suivants
représentent les fiches descriptives des classes identifiées dans la liste ci-dessus.
Nom de la classe
Description
Relations
Attributs
Personne
C’est une classe abstraite des entités humaines du
système.
Elle est la classe mère des classes suivantes : UtilisateurSystème et Administrateur.
Cette classe comporte les attributs suivants :
1. Nom : public
2. Prénom : public
3. Date de naissance : public
4. Adresse : public
5. Numéro de téléphone : public
6. Sexe : public
Rôle
Complexité
Son rôle est de définir la structure des données et le
comportement en commun des entités humaines du
système
Facile
Table 3.2 : Fiche descriptive de la classe Personne
CHAPITRE 3. CONCEPTION
Nom de la classe
Description
Relations
54
Administrateur
Cette classe représente les détails de l’administrateur du
système.
Cette classe a :
• 4 relations d’association avec les classes : DemandeSuppression, UtilisateurSystème, Module et
Séance ;
• Elle est dérivée de la classe Personne.
Attributs
La classe Administrateur n’a aucun attribut de particulier, sauf les attributs qu’elle hérite de sa classe mère
Son rôle est de sauvegarder et manipuler les données de
l’administrateur du système et garantir ses fonctionnalités spécifiées dans le cahier des charges et décrites dans
le diagramme de cas d’utilisation.
Moyenne
Rôle
Complexité
Table 3.3 : Fiche descriptive de la classe Administrateur
Nom de la classe
Description
Relations
Étudiant
Cette classe représente les détails de l’utilisateur principal du système.
Cette classe a :
• Elle est dérivée de la classe UtilisateurSystème ;
• Une seule relation d’association avec la classe
Réclamation ;
• 3 relations d’agrégation avec les classes Groupe,
Absence et Présence, la classe Étudiant est
l’agrégeant de la classe Groupe, et l’agrégé des
classes Présence et Absence ;
• Une classe-association avec la relation d’association
Étudiant-Séance et Étudiant-Absence.
Attributs
Rôle
Complexité
Table 3.4 : Fiche descriptive de la classe Étudiant
CHAPITRE 3. CONCEPTION
Nom de la classe
Description
Relations
55
Enseignant
Cette classe représente les détails de l’enseignant.
Cette classe a :
• 3 relations d’association avec les classes : Module,
Justification et DemandeSuppression ;
• Une relation d’agrégation avec la classe
Département, la classe Enseignant est l’agrégeant ;
• Elle est dérivée de la classe UtilisateurSystème.
Attributs
La classe Enseignant a les attributs qu’elle hérite de sa
classe mère, en plus les attributs suivants :
1. Grade : public
Rôle
Son rôle est de sauvegarder et manipuler les données de
l’utilisateur principal du système (l’étudiant) et garantir ses fonctionnalités essentielles comme la justification
d’une absence, la consultation des relevés et de la liste
des exclus...
Difficile
Complexité
Table 3.5 : Fiche descriptive de la classe Enseignant
Nom de la classe
Description
Relations
Chef département
Cette classe représente les détails du chef de
département.
Cette classe a :
• 3 relations d’association avec les classes : Module,
Justification et DemandeSuppression ;
• Une relation d’agrégation avec la classe
Département, la classe Enseignant est l’agrégeant ;
• Elle est dérivée de la classe Enseignant.
Attributs
Rôle
Complexité
La classe Chef Département n’a aucun attribut de particulier, sauf les attributs qu’elle hérite de sa classe mère.
Son rôle est de sauvegarder et manipuler les données de
l’acteur : chef département et garantir les fonctionnalités
définies dans le cahier des charges.
Moyenne
Table 3.6 : Fiche descriptive de la classe Chef département
CHAPITRE 3. CONCEPTION
Nom de la classe
Description
Relations
56
Responsable de formation
Cette classe représente les détails du responsable de formation.
Cette classe a :
• Une seule relation d’association avec a classe
Spécialité ;
• Elle est dérivée de la classe Enseignant.
Attributs
Rôle
Complexité
La classe ResponsableFormation n’a aucun attribut de
particulier, sauf les attributs qu’elle hérite de sa classe
mère.
Son rôle est de sauvegarder et manipuler les données
de l’acteur : responsable de formation et de garantir les
fonctionnalités définies dans le cahier des charges.
Moyenne
Table 3.7 : Fiche descriptive de la classe Responsable de formation
Nom de la classe
Description
Relations
Séance
Cette classe représente l’entité Séance du système.
Cette classe a :
• 2 relations d’association avec les classes : Administrateur et Étudiant ;
• Une relation de composition avec la classe Module,
la classe Séance est l’agrégeant.
Attributs
La classe Enseignant a les attributs suivants :
1. Identifiant : private
2. IdentifiantPublique : public
3. Date : public
4. HeureDébut : public
5. HeureFin : public
Rôle
Complexité
Son rôle est de sauvegarder et manipuler les données de
l’entité Séance.
Facile
Table 3.8 : Fiche descriptive de la classe Séance
CHAPITRE 3. CONCEPTION
Nom de la classe
Description
Relations
57
Module
Cette classe représente l’entité Module du système.
Cette classe a :
• 2 relations d’association avec les classes : Administrateur et Enseignant ;
• Une relation de composition avec la classe Séance,
la classe Séance est l’agrégé.
Attributs
La classe Enseignant a les attributs suivants :
1. Identifiant : private
2. IdentifiantPublique : public
3. NomModule : public
4. NomAbrégéModule : public
Rôle
Complexité
Son rôle est de sauvegarder et manipuler les données de
l’entité Module.
Facile
Table 3.9 : Fiche descriptive de la classe Module
Nom de la classe
Description
Relations
Groupe
Cette classe représente l’entité Groupe du système.
Cette classe a :
• 2 relations d’agrégation avec les classes : Section
et Étudiant, la classe Groupe est l’agrégeant de la
classe Section et l’agrégé de la classe Étudiant ;
Attributs
La classe Groupe a les attributs suivants :
1. Identifiant : private
2. IdentifiantPublique : public
3. NomGroupe : public
Rôle
Complexité
Son rôle est de sauvegarder et manipuler les données de
l’entité Groupe.
Facile
Table 3.10 : Fiche descriptive de la classe Groupe
CHAPITRE 3. CONCEPTION
Nom de la classe
Description
Relations
Attributs
58
Faculté
Cette classe représente l’entité Faculté du système.
La classe Faculté a une seule relation d’agrégation avec
la classe Département, elle est l’agrégé de cette relation.
La classe Faculté a les attributs suivants :
1. Identifiant : private
2. IdentifiantPublique : public
3. NomFaculté : public
4. NomAbrégéFaculté : public
5. AdresseFaculté : public
6. NuméroTéléphoneFaculté : public
Rôle
Complexité
Son rôle est de sauvegarder et manipuler les données de
l’entité Faculté.
Facile
Table 3.11 : Fiche descriptive de la classe Faculté
Nom de la classe
Description
Relations
Spécialité
Cette classe représente l’entité Spécialité du système.
Cette classe a :
• 3 relations d’agrégation avec les classes
Département, Section et Enseignant la classe
Spécialité est l’agrégeant de la relation avec la
classe Département et l’agrégé de la relation avec
la classe Section et Enseignant ;
• Une relation de dépendance avec l’énumération
EnumSpécialités
Attributs
La classe Spécialité a les attributs suivants :
1. Identifiant : private
2. IdentifiantPublique : public
3. NomSéction : private
4. NomAbrégéSéction : public
Rôle
Complexité
Son rôle est de sauvegarder et manipuler les données de
l’entité Section.
Facile
Table 3.12 : Fiche descriptive de la classe Spécialité
CHAPITRE 3. CONCEPTION
Nom de la classe
Description
Relations
59
Département
Cette classe représente l’entité Département du système.
La classe Département a :
• 3 relations d’agrégation avec les classes : Faculté,
Spécialité et Enseignent. La classe Département
est l’agrégé de la classe Spécialité et Enseignant, et
l’agrégeant de la classe Faculté ;
• Une relation d’association avec la classe Chef
Département ;
• Une relation de dépendance avec l’énumération
EnumDépartements.
Attributs
La classe Département a les attributs suivants :
1. Identifiant : private
2. IdentifiantPublique : public
3. NomDépartement : public
4. NomAbrégéDépartement : public
5. AdresseDépartement : public
6. NuméroTéléphoneDépartement : public
Rôle
Complexité
Son rôle est de sauvegarder et manipuler les données de
l’entité Département.
Facile
Table 3.13 : Fiche descriptive de la classe Département
CHAPITRE 3. CONCEPTION
Nom de la classe
Description
Relations
60
Réclamation
Cette classe représente l’entité Réclamation du système.
Cette classe a :
• 2 relations d’association avec les classes Étudiant
et ChefDépartement ;
• Une relation de dépendance avec l’énumération
EnumÉtatsRéclamations.
Attributs
La classe Réclamation a les attributs suivants :
1. Identifiant : private
2. IdentifiantPublique : public
3. DescriptionRéclamation : public
4. ÉtatRéclamation : public
Rôle
Son rôle est de sauvegarder et manipuler les données de
l’entité Réclamation.
Facile
Complexité
Table 3.14 : Fiche descriptive de la classe Réclamation
Nom de la classe
Description
Relations
Justification
Cette classe représente l’entité Justification du système.
Cette classe a :
• 2 relations d’association avec les classes
ChefDépartement et Enseignant ;
• La classe Justification est une classe-association de
la relation d’association Étudiant-Absence.
Attributs
La classe Justification a les attributs suivants :
1. Identifiant : private
2. IdentifiantPublique : public
3. ÉtatJustification : public
4. URLJustification : public
Rôle
Complexité
Son rôle est de sauvegarder et manipuler les données de
l’entité Justification.
Facile
Table 3.15 : Fiche descriptive de la classe Justification
CHAPITRE 3. CONCEPTION
Nom de la classe
Description
Relations
61
Utilisateur Système
C’est une classe abstraite des entités des utilisateurs du
système (et non pas les administrateurs du système).
Cette classe a :
• Une relation d’association avec la classe Administrateur ;
• Elle est dérivée de la classe Personne ;
• Elle est la classe mère des classes : Étudiant et Enseignant.
Attributs
La classe Utilisateur Système a les attributs suivants :
1. Identifiant : private
2. IdentifiantPublique : public
3. IdentifiantCarte : public
4. PseudoUtilisateur : public
5. EmailUtilisateur : public
6. MotDePasseUtilisateur : public
Rôle
Son rôle est de définir la structure des données et le
comportement en commun des entités des utilisateurs
du système.
Facile
Complexité
Table 3.16 : Fiche descriptive de la classe Utilisateur Système
Nom de la classe
Description
Relations
Attributs
Demande de suppression
Cette classe représente l’entité DemandeSuppression du
système.
Cette classe a 2 relations d’association avec les classes
Administrateur et Enseignant.
La classe Demande de suppression a les attributs suivants :
1. Identifiant : private
2. IdentifiantPublique : public
3. DateDemandeDeSuppression : public
Rôle
Complexité
Son rôle est de sauvegarder et manipuler les données de
l’entité DemandeSuppression.
Facile
Table 3.17 : Fiche descriptive de la classe Demande de suppression
CHAPITRE 3. CONCEPTION
Nom de la classe
Description
Relations
62
Section
Cette classe représente l’entité Section du système.
Cette classe a :
• 2 relations d’agrégation avec les classes Spécialité
et Groupe, la classe Section est l’agrégeant de la
classe Spécialité et l’agrégé de la classe Groupe.
Attributs
La classe Section a les attributs suivants :
1. Identifiant : private
2. IdentifiantPublique : public
3. NomSection : public
Rôle
Complexité
Son rôle est de sauvegarder et manipuler les données de
l’entité Section.
Facile
Table 3.18 : Fiche descriptive de la classe Section
Nom de la classe
Description
Relations
ActionÉtudiantSéance
Cette classe est une classe abstraite qui représente la
relation entre l’étudiant et la séance.
Cette classe :
• Est une classe-association de la relation d’association Étudiant-Séance ;
• Elle est la classe mère des deux classes Présence et
Absence.
Attributs
La classe ActionÉtudiantSéance a les attributs suivants :
• Identifiant : private
• IdentifiantPublique : public
• DateEtHeureAction : public
Rôle
Complexité
Son rôle est de définir la structure des données et le
comportement en commun des entités qui représente la
relation entre l’étudiant et la séance (Présence et Absence).
Facile
Table 3.19 : Fiche descriptive de la classe ActionÉtudiantSéance
CHAPITRE 3. CONCEPTION
Nom de la classe
Description
Relations
63
Présence
Cette classe représente l’entité Section du système.
• Cette classe est dérivée de la classe ActionÉtudiantSéance ;
• Une relation d’agrégation avec la classe Étudiant,
elle est l’agrégeant.
Attributs
Rôle
Complexité
La classe Présence n’a aucun attribut de particulier, sauf
les attributs qu’elle hérite de sa classe mère
Son rôle est de sauvegarder et manipuler les données de
l’entité Présence.
Facile
Table 3.20 : Fiche descriptive de la classe Présence
Nom de la classe
Description
Relations
Absence
Cette classe représente l’entité Absence du système.
• Cette classe est dérivée de la classe ActionÉtudiantSéance ;
• Une relation d’agrégation avec la classe Étudiant,
elle est l’agrégeant.
Attributs
Rôle
Complexité
La classe Absence n’a aucun attribut de particulier, sauf
les attributs qu’elle hérite de sa classe mère
Son rôle est de sauvegarder et manipuler les données de
l’entité Absence.
Facile
Table 3.21 : Fiche descriptive de la classe Absence
CHAPITRE 3. CONCEPTION
3.2.2
64
Diagramme de classes
Après l’identification et la documentation des classes qui nous a permet d’avoir des informations sur les classes on peut dresser un diagramme qui représente la structure du futur système
en utilisant le langage de modélisation UML.
En UML, le diagramme de classe symbolise les classes du système par des rectangles qui contient
des compartiments pour le nom de la classe, ses méthodes et leurs visibilités, ses attributs et
leurs visibilités, le type de la classe (une classe abstraite est symbolisé par un nom de classe en
italique) et un stéréotype définit par le concepteur qui indique la famille de la classe.
La figure suivante représente le diagramme de classes conceptuelles du futur système :
CHAPITRE 3. CONCEPTION
Figure 3.1 : Diagramme de classes
65
CHAPITRE 3. CONCEPTION
3.3
3.3.1
66
Schéma et diagramme de la base de données :
Schéma de la base de données
Après l’élaboration du diagramme de classes, le concepteur doit fournir le schéma de la base de
données avec un diagramme qui représente les différentes tables et leurs relations.
Une base de données est une collection organisée de données stockées sur un support physique, elle permette le partage et l’accès multiple aux informations. Pour accéder aux informations stockées dans une base de données on utilise un Système de gestion de base de données
(SGBD).
Le SGBD nous permet d’interroger la base de données en utilisant un langage déclaratif afin
d’avoir un résultat qui convient à la requête exécutée.
Le concepteur doit penser à l’organisation des informations dans la base de données. Il existe
plusieurs modèles d’organisation, on peut citer : le modèle hiérarchique, le modèle réseau, le
modèle relationnel...
Il existe aussi plusieurs systèmes de gestion de base de données, chaque SGBD implémente un
modèle pour organiser les données. Le modèle implémenté par le SGBD doit être identique au
modèle choisi par le concepteur.
Pour passer du diagramme de classe vers le schéma de la base de données en modèle relationnel, il existe des règles de transformation qui sont appliquées aux classes et leurs relations. Le
passage est conclu par un schéma de la base de données.
Les règles de transformations :
1. Règle 1 : Présence de la cardinalité 1.. ? d’un côté d’une association
• Chaque classe se transforme en une table.
• Chaque attribut de la classe se transforme en un attribut de la table.
• L’identifiant de la classe qui est associée à la cardinalité 1.. ? devient une clé étrangère
de l’autre classe.
2. Règle 2 Présence de la cardinalité ?..* des deux côtés d’une association :
• Chaque classe se transforme en une table.
• Chaque attribut de la classe se transforme en un attribut de la table.
• La classe-association se transforme en une table qui comporte deux clés étrangères
des deux classes de la relation d’association avec la cardinalité ?..*.
3. Règle 3 Présence d’une relation de généralisation :
• Méthode 1 : créer une table avec tous les attributs des classes et ajouter un attribut
type pour repérer les types d’objets.
• Méthode 2 : créer une table pour chaque classe dérivée, chaque table comporte les
attributs en communs plus les attributs spécifiques.
• Méthode 3 : créer une table par classe et définir des relations d’association entre ces
tables.
Le tableau suivant représente le schéma de la base de données :
11
12
13
14
15
7
8
9
10
6
4
5
3
1
2
N
Table 3.22 : Schéma de la base de données
Administrator (id, public id, user name, email, password)
Student (id, public id, first name, last name, birthday, address, phone number,
card id, user name, email, password, gender, group id*)
Professor (id, public id, first name, last name, birthday, address, phone number, level, card id, user name, email, password, gender, department id*)
Faculty (id, public id, name, short name, address, phone number)
Department (id, public id, name, short name, address, phone number, faculty id*,
head of department id*)
Speciality (id, public id, name, short name, department id*,
hed of department id*)
Section (id, public id, name, speciality id*)
Group (id, public id, name, section id*)
Subject (id, public id, name, short name, speciality id*)
Class (id, public id, class date, start time, end time, subject id*, professor id*,
classroom id*, group id*)
Complaint (id, public id, description, status, student id*)
Presence (id, public id, student card id*, class id*)
Justification (id, public id, status, URL, student id*, class id*)
RemovalRequest (id, public id, request date, professor id*)
Classroom (id, public id, name)
Relation
CHAPITRE 3. CONCEPTION
67
CHAPITRE 3. CONCEPTION
3.3.2
Diagramme de la base de données
Pour modéliser le schéma de la base de données, on utilise un diagramme Enhanced entityrelationship (EER). Ce diagramme permet de présenter les entités du système (tables de la
base de données), les attributs de ces entités et ses relations.
La figure suivante représente le diagramme EER de la base de données du futur système :
68
CHAPITRE 3. CONCEPTION
Figure 3.2 : Diagramme de la base de données
69
CHAPITRE 3. CONCEPTION
3.4
70
Scénario d’exécution
La dernière étape de la phase de conception est la modélisation des scénarios d’exécution.
Un scénario d’exécution est lié à un cas d’utilisation, il est modélisé par un diagramme d’activité qui représente l’enchaı̂nèrent des activités invoquées par les différents acteurs du cas
d’utilisation et aussi les actions du système. L’avantage majeur du diagramme d’activité est
l’illustration simple du processus par des organigrammes, cette représentation simple permet la
comparaison facile entre des différents scénarios.
Les figures suivantes représentent une illustration du scénario d’exécution des cas d’utilisation
documentés dans le chapitre précédent :
Figure 3.3 : Diagramme d’activité Ajouter un étudiant
CHAPITRE 3. CONCEPTION
Figure 3.4 : Diagramme d’activité Consulter le relevé d’absence
71
CHAPITRE 3. CONCEPTION
Figure 3.5 : Diagramme d’activité Consulter les statistiques
72
CHAPITRE 3. CONCEPTION
Figure 3.6 : Diagramme d’activité Faire l’appel
73
CHAPITRE 3. CONCEPTION
Figure 3.7 : Diagramme d’activité Faire une réclamation
74
CHAPITRE 3. CONCEPTION
Figure 3.8 : Diagramme d’activité Gérer les justifications
75
CHAPITRE 3. CONCEPTION
Figure 3.9 : Diagramme d’activité Justifier une absence
76
CHAPITRE 3. CONCEPTION
3.5
77
Conclusion
Dans ce chapitre, la structure générale du futur système a été conçue. Une documentation des
classes été faite sous forme de fiches descriptives afin de donner des information sur la structure pour le but de dresser un diagramme de classes.
En utilisant les fiches descriptives et les documentations du chapitre précédent, un diagramme
de classes été dressé, ce diagramme représente les entités du futur système et les relations entre
eux. Le résultat de cette étape est une illustration graphique de la structure générale du système.
Le diagramme de classes n’est pas suffisant aux réalisateurs du projet pour commencer l’implémentation
et la mise en place de la structure conçue, un schéma de base de données est indispensable.
Via les règles de passages présentées dans ce chapitre, un schéma relationnel a été établi et
illustré par un diagramme EER qui figure les tables de la base de données, les attributs et les
différentes relations.
Après le schéma de la base de données et le diagramme EER, les scénarios d’exécutions ont été
modélisés afin d’illustrer l’enchaı̂nement des actions des acteurs pour chaque cas d’utilisation.
La réalisation du projet peut maintenant commencer à l’aide des différents diagrammes et documentations établis dans cette étape.
Chapitre 4
Implémentation
4.1
Introduction
L’implémentation est l’avant-dernière activité du processus de développement unifié, elle consiste
à utiliser les différents documentations et diagrammes établis dans les chapitres précédents et
les traduire en code source dans le but de réaliser la solution conçue. Autrement dit, traduire
les besoins des utilisateurs du système exprimés précédemment en solution livrable qui répond
à ces besoins.
L’activité de l’implémentation est l’activité la plus coûteuse en terme de temps par rapport
aux autres activités du processus unifié.
La solution proposée sera réalisée par des différents technologies, chaque technologie est intégrée
en utilisant un environnement de développement et des outils spécifiés à cette dernière.
Ce chapitre présente les différents technologies et comment ils sont intégrés dans la solution
proposée.
4.2
Environnement de développement
Les tableaux suivants représente la configuration matérielle utilisée dans l’implémentation de la
solution conçue.
Modèle
CPU
GPU
RAM
Stockage
Système d’exploitation
Lenovo ThinkPad X220 4291RW0
Intel i5-2520M (4) @ 3.200GHz
Intel HD Graphics
8GB DDR3
HDD 320GB
Debian GNU/Linux 10 (Buster) x86 64, noyau 4.19.0-10amd64
Table 4.1 : Spécifications techniques de l’ordinateur 1
78
CHAPITRE 4. IMPLÉMENTATION
Modèle
CPU
GPU
RAM
Stockage
Système d’exploitation
79
Dell Inspiron 3542
Intel core i5-4210U @ 1.70GHz
Intel HD Graphics
8GB DDR3
HDD 1TB
Windows 10
Table 4.2 : Spécifications techniques de l’ordinateur 2
4.3
Base de données
Dans le chapitre précédent on a établi à travers les règles de transformation du diagramme de
classes vers le modèle relationnel un tableau des relations de la base de données ainsi qu’un
diagramme de base de données qui illustre les différents tableaux ses relations et ses attributs.
À l’aide du diagramme et la documentation établis précédemment on peut mettre en place la
base de données.
Le système de gestion de base de données choisis pour ce projet est MariaDB. MariaDB est
un système de gestion base de données gratuit et Open Source développé par la communauté.
Ce SGBD est un fork de MySQL.
MariaDB est disponible sur le site officiel https://mariadb.org/ et aussi sur les dépôts du Debian Buster .
% apt - cache search mariadb - server
mariadb - server - MariaDB database server ( metapackage depending on the latest ver
mariadb - server -10.3 - MariaDB database server binaries
mariadb - server - core -10.3 - MariaDB database core server files
Le service de MariaDB doit être lancé en permanence pendant le processus de développement.
$ sudo systemctl enable mariadb;
$ sudo systemctl start mariadb;
La version de MariaDB utilisé pendant le développement de l’application Web est la suivante :
% mariadb -- version
mariadb Ver 15.1 Distrib 10.3.23 - MariaDB , for debian - linux - gnu ( x86_64 ) using re
Un outil d’administration de base de données est indispensable, il permet la création facile et
rapide du schéma de la base de donnés et l’interaction efficace avec la base de donnée. Il permet aussi de générer le diagramme EER qui illustre les différents tables de la base de données,
ses attributs et ses relations.
L’outil d’administration de base de données utilisé pendant le développement de l’application
Web est DBeaver .
CHAPITRE 4. IMPLÉMENTATION
Figure 4.1 : Universal Database Manager
La figure suivante illustre l’interaction entre l’application Web et la base de données :
Figure 4.2 : Interaction avec la base de données
80
CHAPITRE 4. IMPLÉMENTATION
4.4
81
Application Web
Une application web et un programme persistant sauvegardé sur un serveur distant délivré sur
un réseau (par exemple Internet), cette application est accessible par plusieurs utilisateurs en
même temps à travers un navigateur.
l’application Web sert comme une interface de gestion pour le système de gestion des absences
de la faculté des nouvelles technologies de l’information et de la communication.
L’interface de gestion délivre les informations aux utilisateurs via le protocole HTTP.
HTTP est un protocole de la couche application du modèle OSI, son rôle est de distribuer les
informations des ressources accessibles par l’utilisateur. La communication entre l’utilisateur et
le serveur se fait à travers une session HTTP, c’est une série de transactions requête-réponse.
Cette communication est appelée l’approche client-serveur.
Figure 4.3 : L’architecture client-serveur.
Quand l’utilisateur accède à l’application Web, le serveur interroge la base de données pour
récupérer les données et les afficher.
Le tableau suivant définit le langage de programmation, l’environnement de développement et
le serveur de l’application Web.
Langage de programmation
Environnement de
développement
Serveur
Java 11 compilé sur Debain 10 Buster
IntellijIDEA ULTIMATE 2019.3
Tomcat 9.0.34
Table 4.3 : Environnement de développement de l’application Web
CHAPITRE 4. IMPLÉMENTATION
4.4.1
82
Language de programmation
Le langage de programmation utilisé pour développer l’application Web est le fameux langage
basé sur le paradigme orienté-objet Java . L’édition standard de Java n’est pas suffisante pour
développer une application Web, Jakarta EE (précédemment Java Enterprise Edition) est
utilisé dans le but d’étendre l’édition standard de Java. Jakarta EE permet d’ajouter la possibilité de développement des applications hébergées sur un serveur.
% java -- version
openjdk 11.0.8 2020 -07 -14
OpenJDK Runtime Environment ( build 11.0.8+10 - post - Debian -1 deb10u1 )
OpenJDK 64 - Bit Server VM ( build 11.0.8+10 - post - Debian -1 deb10u1 , mixed mode , shari
OpenJDK 11 est disponible sur les dépôts du Debian Buster 10 ou sur le site officiel https://openjdk.java.net/.
% apt - cache search openjdk -11 - jdk
default - jdk - Standard Java or Java compatible Development Kit
default - jdk - headless - Standard Java or Java compatible Development Kit ( headless
openjdk -11 - jdk - OpenJDK Development Kit ( JDK )
openjdk -11 - jdk - headless - OpenJDK Development Kit ( JDK ) ( headless )
Environnement de développement
Les spécifications du matériel utilisé pour développer l’application mobile est cité précédemment
dans ce chapitre. L’application Web est développé à l’aide d’un environment de développement
intégré (IDE) fourni par JetBrains et disponible sur le site officiel https://www.jetbrains.com/frfr/idea/ .
IntellijIDEA facilite la tache de développement car il permet l’intégration facile des projets
Maven, le changement rapide entre des différents versions de la Runtime Java et du serveur
qui héberge l’application.
Figure 4.4 : JetBrains IntellijIDEA
CHAPITRE 4. IMPLÉMENTATION
83
Maven
Maven est un outil de gestion et d’automatisation de production des projets logiciels Java
en général et Java EE en particulier. Il est utilisé pour automatiser l’intégration continue lors
d’un développement de logiciel. Maven est géré par l’organisation Apache Software Foundation https://maven.apache.org/.
L’application Web dépend d’autres projets (appelés aussi dependencies), Maven permet une
intégration et une gestion facile de ces derniers.
La figure suivante illustre les dépendances du projet Maven de l’application Web.
Figure 4.5 : Dépendances du projet Maven
Pour intégrer une dépendance à un projet Maven, il suffit de l’ajouter au ficher de configuration du projet appelé pom.xml.
<dependencies>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.16</version>
</dependency>
</dependencies>
La liste suivante définit en bref le rôle de chaque dépendance illustrée dans la figure 4.5 :
• JUnit : un framework de test unitaire pour le langage de programmation Java, il permet
le test du code avant l’intégration.
• JSTL : la JavaServer Pages Standard Tag Library (JSTL) est un composant de la plateforme JEE de développement. Elle étend la spécification JSP en ajoutant une bibliothèque
de balises.
• servlet-api : permet de créer des contrôleurs.
• mysql-connector-java : permet la connection avec une base de données MySQL.
CHAPITRE 4. IMPLÉMENTATION
4.4.2
84
La structure du projet
L’architecture MVC
Model-View-Control (MVC) est un pattern de développement des applications Web basées sur
le paradigme de programmation orienté-objet. Il permet une meilleure organisation du code
source du projet et une compréhension du rôle de chaque ficher du code source.
Le but de l’architecture MVC est de séparer la logique du code en trois parties :
1. Modèle : cette partie gère les données des entités de l’application. Son rôle et de maintenir les données récupérés de la base de données. Dans le code source, un modèle est une
Classe Java.
public class Model1 {
public String user_name;
private String password;
public Model (String user_name, String password) {
this.user_name = user_name;
this.password = password;
}
}
Figure 4.6 : Modèle
2. Vue : cette partie assure l’affichage des interfaces et des données récupérés de la base de
données. Une vue dans le code source et un ficher HTML si le contenu est statique, ou
un ficher JSP si le contenu est dynamique.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>View1</title>
</head>
<body>
<h1>Welcome to View1</h1>
</body>
</html>
Figure 4.7 : Vue
3. Contrôleur : cette partie est le cerveau du code, elle assure le bon fonctionnement de la
logique de l’application. En code source, un contrôleur est une Classe Java qui hérite
ses fonctionnalité de la classe HttpServlet. En Jakarta EE , un contrôleur est appelé
aussi une Servlet.
CHAPITRE 4. IMPLÉMENTATION
85
public class Controller1 extends HttpServlet {
// Logique du contr^
oleur
}
Figure 4.8 : Contrôleur
Structure du projet
• /src : Contient le code source du projet de l’application Web.
• /pom.xml : Le ficher pom.xml définit la configuration et les dépendances du projet Maven.
• /src/main/java : Contient la dossiers suivants :
– Control : regroupe les classes de contrôle (appelées aussi emphServlets).
– Model : regroupe les classes modèles.
– Utils : regroupe des outils qui facilite la tâche de développement, par exemple les
connecteurs de la base de données.
• /src/main/java/Model/Abstract : Contient les classes abstraites utilisés dans la structure
du système.
• /src/test/java : contient les classes de teste utilisés pout valider les fonctionnalités ajoutées
avant l’intégration.
• /web/WEB-INF : contient les vues du l’architecture MVC (les différents fichiers HTML
et JSP).
• /web/web.xml : appelé aussi Deployment Descriptor est le ficher de configuration qui
permet d’identifier les contrôleurs et configurer le projet pour le déploiement.
Figure 4.9 : Structure du projet de l’application Web
CHAPITRE 4. IMPLÉMENTATION
4.4.3
Captures de l’application Web
Figure 4.10 : Capture 1 de l’application Web
Figure 4.11 : Capture 2 de l’application Web
86
CHAPITRE 4. IMPLÉMENTATION
Figure 4.12 : Capture 3 de l’application Web
Figure 4.13 : Capture 4 de l’application Web
87
CHAPITRE 4. IMPLÉMENTATION
4.5
88
Appareil de prise de présences
La solution proposée pour automatiser la tâche de la prise de présence dans la faculté des nouvelles technologies de l’information et de la communication est de concevoir et de réaliser un
appareil électronique basée sur la carte de contrôle Raspberry PI et à l’aide de la technologie
de la radio-identification.
4.5.1
Raspberry PI
Raspberry Pi est un ordinateur minuscule qui fait les dimensions d’une carte de crédit, il
est capable d’exécuter un système d’exploitation grâce à son microprocesseur de type ARM.
Cette petite machine peut être branchée sur un moniteur et avec un clavier et une souris on
peut l’utiliser comme un ordinateur de bureau pour surfer sur internet, faire des traitements de
texte, apprendre à programmer. . . etc
La première apparition de la Raspberry Pi était en Février 2012 en Royaume Unie, le but de
la création de cet ordinateur et de l’intégrer dans les écoles des pays en développement pour
enseigner les basiques de la science de l’informatique.
Le projet de charité éducative crée par la Raspberry Pi Foundation a connu plusieurs utilisations autre que l’éducation. Il est largement exploité dans des projets IoT comme les maisons
intelligentes (Smart Homes), les robotiques et la collecte de données dans plusieurs domaines
(on peut citer : le domaine agro-alimentaire, la sécurité informatique ...etc).
Figure 4.14 : Raspberry PI Zero
CHAPITRE 4. IMPLÉMENTATION
89
Grâce aux caractéristiques de la Raspberry Pi et de sa portabilité, elle est devenue la carte
de contrôle la plus utilisée pour la collecte des données. Il existe plusieurs générations de cette
carte avec des différentes dimensions et caractéristiques, on peut citer :
Modèle
Raspberry Pi 2 Model B
Caractéristiques
• Microprocesseur Quad Core ARM
• 1GB de RAM
• 40 GPIO pins
• 4 ports USB 2.0
• Stereo output
• Port FULL HDMI
Raspberry Pi 3 Model B+
• Microprocesseur Quad Core ARM
• 1GB de RAM
• Connectivité :
– Double bande Wi-Fi 802.11ac
– Bluetooth 4.2
– Gigabit Ethernet
• 40 GPIO pins
• 4 ports USB 2.0
• Stereo output
• Port FULL HDMI
Raspberry Pi Zero W v1.1
• Microprocesseur Single Core ARM
• 512MB de RAM
• Connectivité :
– Wi-Fi 802.11 b/g/n
– Bluetooth 4.1
• 40 GPIO pins
• 1 port micro USB
Table 4.4 : les versions de la Raspberry PI
CHAPITRE 4. IMPLÉMENTATION
90
Pour accomplir la tâche de la collecte automatique des présences des étudiants, l’appareil électronique
est réalisé en utilisant la carte de contrôle la moins puissante et la technologie de la technologie
de la radio-identification.
Le choix d’utilisation de la Raspberry Pi Zero v1.1 est idéal pour ce cas d’utilisation à
cause de ses dimensions qui facilite l’intégration dans plusieurs endroits, et le grand nombre
des ports GPIO offert par cette dernière qui permet de brancher tous les modules nécessaires
pour le fonctionnement de l’appareil.
Figure 4.15 : Dimensions de la Raspberry PI
Configuration de la carte de contrôle
La Raspberry Pi Zero v1.1 est capable de lancer un système d’exploitation. Généralement
GNU/Linux est l’OS utilisé pour piloter la machine. La distribution GNU/Linux officielle supportée et fournie par la Raspberry Pi Foundation est Raspbian. Cette dernière est basée sur la
distribution Debian 10 Buster sortie en Novembre 2019.
Raspberry Pi Foundation offre trois variantes de la distribution Raspbian :
1. Raspbian Buster avec un environnement graphique et des logiciels recommandés préinstallés, l’image fait plus de 2 Go.
2. Raspbian Buster avec un environnement graphique seulement, l’image fait plus de 1
Go.
3. Raspbian Buster Lite sans interface graphique, l’image fait moins de 500 Mo.
Dans ce projet, on utilise la troisième variante Raspbian Buster Lite. Cette distribution est
très légère pour se lancer sur la Raspberry Pi la moins puissante avec un micro processeur
mono-core et 512 Mo de mémoire vive. De plus, l’appareil de collecte de données réalisée ne
nécessite pas un environnement graphique pour accomplir sa tâche.
Par défaut, la carte de contrôle n’a pas un moyen de stockage de masse intégré. Pour que la
Raspberry Pi puisse démarrer le système d’exploitation, une carte micro SD est ajoutée dans
CHAPITRE 4. IMPLÉMENTATION
91
le lecteur de cartes intégré au niveau de la carte pour maintenir le système d’exploitation et les
différents fichiers de configuration.
L’installation du système d’exploitation sur la Raspberry Pi est particulière. La méthode d’installation diffère d’un système d’exploitation à un autre.
• Pour Microsoft Windows, il est préférable d’utiliser le logiciel officiellement supporté
par la fondation. Raspberry Pi Imager offre une interface graphique simple et facile à
utiliser, il suffit de choisir la carte micro SD branchée sur le bon lecteur et le fichier de
l’image de la distribution pour obtenir une carte SD bootable et prête à installer sur la
carte de contrôle.
• Pour GNU/Linux et Apple Mac OS , il est possible d’utiliser l’outil dd (aussi connu
sous le nom de Data Duplicator ) pour créer une carte micro SD bootable et prête à utiliser sur une Raspberry Pi.
La commande à utiliser est la suivante :
\$ sudo dd if=/lien/vers/image/raspbian.img of=/dev/sdX bs=4M conv=fsync
la Raspberry Pi est alimentée par un courant continue d’une tension électrique entre 4.75V et
5.25V. Une petite lampe LED intégrée clignotera pour indiquer le bon fonctionnement de la
carte.
Figure 4.16 : Raspberry PI détaillée
CHAPITRE 4. IMPLÉMENTATION
92
La prochaine étape de configuration est d’accéder à l’invite de commandes (aussi connu par le
shell) de la Raspberry Pi.
Afin d’avoir accès au compte utilisateur de la carte on doit configurer la connexion au réseau
local via le récepteur Wi-Fi intégré. Cette connexion est effectuée en ajoutant un fichier de
configuration wpa supplicant.conf au dossier boot du système d’exploitation gravé sur la
carte micro SD.
# Création du dossier boot sur la machine locale
\$ mkdir boot_raspberry;
# Montage de la partition boot de la Raspberry Pi
\$ sudo mount /dev/sdX ./boot_raspberry && cd ./boot_raspberry;
# Création du fichier de configuration
\$ echo '''
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="NomDuRéseauWiFi"
psk="MotDePasseRéseau"
key_mgmt=WPA-PSK
}
''' > wpa_supplicant.conf
Une fois la connection est effectuée avec succès, un serveur SSH doit être lancé sur la carte de
contrôle.
Secure Shell
Secure Shell (SSH) est un protocole de la couche présentation du modèle TCP/IP, il permet la
connexion à une machine distante avec la possibilité de la télé-exécution des commandes. Le
système d’exploitation de la Raspberry PI utilise OpenSSH , une suite d’outils pour établir
une connexion sécurisée basée sur le protocol SSH qui opère sur le port 22 de la machine.
OpenSSH server est installé par défaut sur la Raspberry PI . Il suffit de l’activer par la
création d’un fichier vide avec le nom ssh dans le dossier boot de la carte micro SD.
# Création du dossier boot sur la machine locale
\$ mkdir boot_raspberry;
# Montage de la partition boot de la Raspberry Pi
\$ sudo mount /dev/sdX ./boot_raspberry && cd ./boot_raspberry;
# Création du fichier ssh
\$ touch ssh
Le résultat des étapes précédentes est une Raspberry PI connectée au réseau avec un serveur
SSH qui marche en permanence.
CHAPITRE 4. IMPLÉMENTATION
93
Connexion à une Raspberry PI
Pour prendre le contrôle de la carte, on doit posséder 3 informations reliée à cette dernière :
1. Le nom d’utilisateur par défaut ;
2. Le mot de passe par défaut ;
3. L’adresse IP locale de la Raspberry PI .
Le nom d’utilisateur et le mot de passe par défaut des cartes Raspberry PI sont présents sur
le site officiel de la Raspberry Pi Fondation.
Nom d’utilisateur
Mot de passe
pi
raspberry
Pour connaı̂tre l’adresse IP locale de la Raspberry Pi connectée au réseau, il existe plusieurs
techniques. La méthode la plus efficaces est d’utiliser un logiciel d’exploration de réseau comme
Nmap.
Une simple commande qui prend en entrée l’adresse du réseau et le masque sous-réseau nous
rend une liste des appareils connectés avec leurs adresses logiques, adresses physiques et le nom
du fabricant (Raspberry Pi Foundation dans notre cas).
\$ sudo nmap -sn 192.168.1.0/24
Nmap scan report for 192.168.1.0/24
Host is up (0.00051s latency).
MAC Address : B8:27:EB:B2:D9:AC (Raspberry Pi Foundation)
On peut aussi vérifier le statut du serveur SSH par l’analyse des ports sur l’adresses IP obtenue. Si le port 22 est ouvert, le serveur SSH est en état actif.
\$ sudo nmap 192.168.1.0/24
Host is up (0.0033s latency).
Not shown: 999 closed ports
22/tcp open ssh
Après la configuration headless (sans brancher des équipements d’entrée/sortie extérieures
comme un écran ou un clavier), la Raspberry Pi est prête à l’utilisation.
La commande suivante permet d’accéder au shell de la carte de contrôle.
\$ ssh -p 22 pi@192.168.1.105
Il faut noter que OpenSSH client doit être installé sur la machine locale. OpenSSH est disponible sur les dépots du Debian Buster 10 .
\$ sudo apt install openssh-{server,client}
CHAPITRE 4. IMPLÉMENTATION
94
Figure 4.17 : Connexion SSH à une Raspberry Pi
Une fois qu’on a accès au shell de la Raspberry Pi il faut la mettre à jour, activer l’interface
GPIO et installer les librairies nécessaires pour le fonctionnement de l’appareil.
L’interface GPIO
GPIO est une interface présente sur la carte de contrôle sous forme de 40 pins. Elle permet la
connexion avec d’autres circuits et modules pour la réalisation de projets électroniques.
Figure 4.18 : GPIO
CHAPITRE 4. IMPLÉMENTATION
4.5.2
95
La technologie de radio-identification
Afin d’identifier les étudiants et les enseignants dans le système, le choix a été porté sur la
technologie de radio-identification Radio Frequency Identification (RFID). La technologie RFID
utilise les champs électromagnétiques afin d’identifier des cartes ou des tags marchant sur la
même fréquence du capteur.
Les tags et les cartes RFID contiennent un émetteur/récepteur radio, ce dernier envoi une
information au moment de son déclenchement par une pulsion électromagnétique d’un lecteur (module) RFID. L’information envoyée est généralement l’identifiant unique de la carte.
Dans ce projet, le capteur utilisé pour lire les informations des tags et des cartes RFID est le
RC522.
Figure 4.19 : Module RFID-RC522
4.5.3
Conception de l’appareil
La conception de l’appareil électronique est faite à l’aide d’un logiciel dédié à cette tâche appelé Fritzing disponible sur le site officiel https://fritzing.org/.
Ce logiciel permet d’élaborer le schéma de branchement des différentes modules électroniques
avec la carte de contrôle.
Le matériel utilisé pour réaliser l’appareil électronique :
• Une carte de contrôleRaspberry Pi Zero v1.1
• Des lampes LED ;
• Des résistances ;
• Une Breadboard ;
• Un module RFID-RC522 ;
• Des cables de connexion Jumper.
CHAPITRE 4. IMPLÉMENTATION
La figure suivante illustre le schéma de branchement de l’appareil électronique de prise de
présences automatique :
Figure 4.20 : Schéma de branchement
96
CHAPITRE 4. IMPLÉMENTATION
4.5.4
97
Communication avec la base de données
La communication entre l’appareil électronique est la base de données conçue est mise en place
dans les chapitres précédents est effectuée à travers un intermédiaire de communication appelé
API.
Qu’est ce qu’une API REST ?
Une API est une séries de règles qui permet les programmes de se communiquer entre eux,
le développeur crée le serveur et autorise les clients d’interroger et de communiquer avec ce
dernier.
Une API Representational State Transfer (REST) est aussi une série de règles qui définissent
la façon de communication de l’API avec les clients. Dans une API REST une information
est retournée lorsqu’une requête est faite vers un URL spécifié. La communication entre un
client et une API est effectuée à travers un format de données universel appelé JavaScript
Object Notation (JSON).
{
"user_name": "ouailderghal25",
"email": "ouailderghal@gmail.com",
"password": "SuperSecretPASSWORD25"
}
Figure 4.21 : Données en format JSON
Chaque route de l’API REST accepte un ou plusieurs type de requêtes, ces types sont appelées des méthodes :
Méthode
GET
POST
PUT
DELETE
Description
permet d’effectuer une opération de lecture sur le serveur afin d’avoir une
information spécifique.
permet de créer une nouvelle entité sur la base de données.
permet de mettre à jour une entité sur la base de de données.
permet de supprimer une entité sur la base de données.
Table 4.5 : Les méthodes HTTP
Chaque requête effectuée sur l’API REST possède un code de statut. Le tableau suivant
représente la signification des codes courants :
Code
200
201
403
404
501
Signification
Succès OK.
Entité crée avec succès.
Accès limité.
Contenu non disponible.
Erreur du serveur.
Table 4.6 : Les codes HTTP
CHAPITRE 4. IMPLÉMENTATION
4.6
98
Le projet API REST
Pour assurer la communication de l’appareil électronique avec la base de données, une API
REST doit être mise en place. L’API REST est développée par le langage de programmation Python et la librairie Flask .
Flask est un micro-framework qui permet la création des applications Web à travers le langage de programmation Python. La version du langage de programmation utilité pour développer
l’API est la suivante :
% python3 -- version
Python 3.7.3
Les dépendances du projet de l’API REST sont :
1. Flask : permet de créer les différentes routes de l’API, retourner les réponses et convertir
les dictionnaires de Python en objets JSON .
2. mysql-connector : assure la connexion entre l’API et la base de données.
3. uuid : permet de générer des identifiants uniques à la demande.
4. unittest : permet de tester le code avant l’intégration.
Ce projet est développé à l’aide de l’éditeur de code Sublime Text https://www.sublimetext.com/.
Les testes de l’API avant la mise en services sont faits à travers des différents méthodes :
• En utilisant l’outil cURL, il permet d’effectuer des requêtes HTTP via la ligne de commande.
• Par le module des testes unitaires unittest et le module requests qui permet l’interaction avec l’API en utilisant les requêtes HTTP.
• A l’aide d’un logiciel dédié au teste des APIs, ce logiciel est Postman. Grace à son interface simple, il permet d’exécuter les requêtes HTTP d’une façon simple et efficace et
de sauvegarder les résultats. Postman est disponible sur le site officiel https://www.postman.com/.
Figure 4.22 : Architecture de communication
CHAPITRE 4. IMPLÉMENTATION
4.7
99
Le projet de l’appareil de prise de présences
Après l’établissement du schéma de branchement et la réalisation de l’appareil électronique, il
est impératif de développer le cerveau de l’appareil. Le programme qui joue le rôle de cerveau
permet de communiquer avec les modules connectés à la carte de contrôle et invoquer des actions définies par la logique du programme.
L’enseignant doit déverrouiller l’appareil pour chaque séance ; cette mesure de sécurité est
posée pour éviter le fonctionnement non nécessaire et les erreurs humaines. Quand l’appareil
détecte la carte de l’enseignant, il se déverrouille en clignotant la lampe verte.
Quand un étudiant introduit sa carte sur le lecteur, l’appareil vérifie s’il s’agit d’une carte
valide. Si la carte n’est pas valide la lampe rouge se clignotera, sinon l’appareil enregistre la
présence de l’étudiant en clignotant la lampe bleue.
Pour éviter la manipulation extérieure l’appareil ne permet pas de sauvegarder une présence
existante dans la base de données et aussi l’enseignant est capable de verrouiller et déverrouiller
l’appareil dans la limite du temps de la séance.
Le programme cerveau de l’appareil de prise de présence est développé en Python v3.7.3
et il dépends d’autres modules nécessaire pour effectuer la communication entre la carte de
contrôle, les modules connectés et l’API développée et mise en place précédemment.
Les dépendances du projet de l’Appareil de prise de présences sont :
1. mfrc522 : ce module permet de communiquer avec le module RFID-RC522 utilisé comme
un lecteur de cartes et de tags.
2. requests : ce module permet d’effectuer des requêtes HTTP à l’API mise en place précédemment.
3. gpiozero : ce module permet de contrôler les lampes LED qui indique le statut de l’appareil.
4. GPIO : ce module permet la communication avec les ports GPIO de la Raspberry Pi .
5. JSON : ce module permet de gérer les objets JSON.
6. threading : ce module permet de créer et lancer des programmes en parallèle.
7. unittest : permet de tester le code avant l’intégration.
Ce projet est développé avec l’éditeur de code Vim. Il est un éditeur de code robuste et puissant qui peut se lancer dans une session SSH car il ne nécessite pas une interface graphique.Vim
est disponible sur les dépôts du Debain Buster et sur le site officiel https://www.vim.org/.
La version de Vim utilisée est la suivante :
% vim -- version | head -n 1
VIM - Vi IMproved 8.1 (2018 May 18 , compiled Jun 15 2019 16:41:15)
CHAPITRE 4. IMPLÉMENTATION
100
Figure 4.23 : Éditeur de code Vim
4.8
Application mobile
Il s’agit d’application conçue pour une grande partie de systèmes d’exploitation fiables par les
Smartphones en se référant à un langage particulier à chacun d’eux.
Ce mode d’application est accessible seulement sur les plateformes d’applications suivant ses
particularités et ses formules. Ces plateformes retirent 25% du prix de vente pour une application native payante.
Le développement de l’application mobile nécessite le recours à la mémoire du Smartphone
sans omettre les options reliées au système d’exploitation en question. De cette façon, le résultat
se résume dans l’aboutissement à des applications mobiles avec des fonctions plus professionnelles, développées et performantes au même niveau que les applications en HTML5/CSS3 et
les applications hybrides.
Le souci des applications mobile est que les utilisateurs doivent avoir un système d’exploitation mobile donné pour qu’ils puissent les utiliser. Pour assurer un usage plus exponentiel de
ces applications mobiles, il faut penser à lancer la même application mobile compatible à tout
système d’exploitation mobile.
4.8.1
Android
Android est un système d’exploitation ouvert (Open Source) pour tablettes tactiles, terminaux
mobiles et TV connectées. Il a été conçu en 2007, par la société Android, une startup rachetée
par Google. C’est un système d’exploitation fondé sur un noyau Linux disponible grâce à une
licence Apache.
Android inclut tous les utilitaires requis par un constructeur pour le mettre en œuvre dans
un téléphone portable. Il est proposé à tous les fabricants de téléphones mobiles pour faciliter
son adoption. Il a été conçu pour intégrer les applications Google comme Gmail, Google Map,
Google Agenda, Google Talk ou encore You Tube.
Android est un système presque équivalent à IOS, tant en fonctionnalités qu’en applications.
CHAPITRE 4. IMPLÉMENTATION
101
Là où Apple cherche la cohérence et la sécurité, Android offre plus de choix et de personnalisation.
Pour développer une application mobile sur ce support, le langage de programmation utilisé
sera Java. Le kit de développement ou SDK (Software Développement Kit) autrement dit
les outils de développement utilisés seront le SDK Android. On peut également utiliser le langage C++ avec le NDK (Native Développement Kit).
4.8.2
L’historique des versions d’Android
Le système de Google n’aurait pas connu un tel succès s’il était resté le même en six ans. C’est
là que l’on voit la puissance d’un tel OS qui a su s’adapter aux besoins des utilisateurs à chaque
version majeure et qui s’enrichit de nouveautés.
Nom de code
Apple pie
Version
1.0
Honeycomb
3.x.x
Lollipop
5.0
Caractéristiques
Version connue uniquement
ou presque des développeurs
car c’est la version du SDK
distribuée avant la sortie du
premier téléphone Android
Réservé aux tablettes tactiles et aux téléviseurs
connectés16, cette mise à
jour comprend de nombreux
changements dans l’interface
• Nouvelle interface /
design (”Material design”)
• Amélioration de la rapidité
• Amélioration de la gestion de la batterie
Table 4.7 : Quelques versions d’Android
Les principaux composants de ce système sont :
• Le noyau Linux : Android repose sur un noyau Linux (version 2.6) qui gère les services du système, comme la sécurité, la gestion de la mémoire et des processus, la pile
réseau et les pilotes. Il agit également comme une couche d’abstraction entre le matériel
et la pile logicielle.
• Les bibliothèques : En interne, Android inclut un ensemble de bibliothèques C et
C++ utilisées par de nombreux composants de la plateforme Android.
• Moteur d’exécution Android : Chaque application Android s’exécute dans son propre
processus, avec sa propre instance de machine virtuelle Dalvik.
CHAPITRE 4. IMPLÉMENTATION
102
• Le Framework : Android offre aux développeurs la possibilité de créer des applications
extrêmement riches et innovantes.
• Applications : Android est fourni avec un ensemble d’applications natives permettant
d’accéder à des fonctionnalités comme les courriels, le téléphone, le calendrier, les photos Ces applications sont développées à l’aide du langage de programmation Java. Pour
l’utilisateur final, c’est la seule couche accessible et visible.
Figure 4.24 : Architecture logicielle de l’Android
4.8.3
Environnement de développement
Android Studio
Depuis décembre 2014, l’environnement de développement Eclipse, avec son module ADT ont
pris leur retraite afin de faire place au tout nouvel environnement Android Studio.
Android Studio représente la plateforme officielle, soutenue par Google, pour le développement
d’applications Android. Il repose sur IntelliJ (Community Edition) de JetBrain et devrait permettre aux développeurs d’être plus rapides et plus productifs. Il offre toutes les possibilités
nécessaires pour développer une application Android complète. Android Studio est annoncé le
15 mai 2013 lors du Google I/O et une version ”Early Access Preview” est disponible le jour
même.
Le 8 décembre 2014, Android Studio passe de la version bêta à la version stable 1.0. Android
Studio remplace alors Eclipse ADT en tant qu’IDE officiel. Le 7 avril 2016, la version v2.0 est
centrée sur la performance. Elle introduit un émulateur beaucoup plus rapide et depuis le 19
CHAPITRE 4. IMPLÉMENTATION
103
septembre 2016, c’est la dernière version stable v2.2 Elle supporte Java 1.8, et améliore les performances globales.
Dans ce projet on a choisi de travailler avec la version Android 4.0.1 (Beta 5).
Figure 4.25 : Android Studio version 4.0.1
4.8.4
Communication avec la base de données
La méthode la plus répondue de se connecter a une base de données MySQL à distance à partir d’une application mobile est de mettre une sorte de service au milieu. La façon la plus simple
est d’écrire des Scripts en Java, Php, JavaScript . . . pour gérer la base de données en utilisant
le protocole HTTP du système Android. Ce service est appelé API (Application Programming
Interface). Dans notre projet on a développée cette dernière en JavaScript.
Node.js
Node.js est une plateforme logicielle libre en JavaScript orientée vers les applications réseaux
événementielles hautement concurrentes qui doivent pouvoir monter en charge. Parmi les modules natifs de Node.js, on retrouve http qui permet le développement de serveur HTTP.
On a ajouté plusieurs Middleware pour assurer la fiabilité de notre API. Ces Middleware sont
les suivantes :
• Express.js : est une infrastructure d’applications Web Node.js minimaliste et flexible
qui fournit un ensemble de fonctionnalités robuste pour les applications Web et mobiles.
API Grâce à une foule de méthodes utilitaires HTTP et de middleware mise à votre disposition, la création d’une API robuste est simple et rapide.
• BodyParser.js : Analyser les corps de demande entrants dans un middleware avant vos
gestionnaires, disponibles sous la propriété req.body .
• md5 : permet de crypter mots de passe.
• UUID : permet de générer des identifiants universels et unique.
CHAPITRE 4. IMPLÉMENTATION
104
• MySQL : permet d’accéder à une base de données.
• Multer : permet de télécharger un fichier.
Gradle
Gradle est un moteur de production (un logiciel dont la fonction principale consiste à automatiser l’ensemble des actions (préprocessing, compilation, éditions des liens, etc.) contribuant,
à partir de données sources, à la production d’un ensemble logiciel opérationnel) fonctionnant
sur la plateforme Java. Il permet de construire des projets en Java.
On a ajouté plusieurs dépendances à l’aide du Gradle pour nous aider à construire notre application mobile. Ces dépendances sont :
• androidx.appcompat :appcompat :1.2.0 : permet l’accès aux nouvelles API sur les
anciennes versions API de la plate-forme.
• androidx.constraintlayout :constraintlayout :1.1.3 : positionner les widgets d’une
manière flexible avec un positionnement relatif.
• androidx.recyclerview :recyclerview :1.1.0 : Affichez de grands ensembles de données
dans votre interface utilisateur tout en minimisant l’utilisation de la mémoire.
• com.android.volley :volley :1.1.1 : permet de récupérer la réponse à partir de l’API.
• com.github.bumptech.glide :glide :4.11.0 : permet de récupérer l’URL d’une image
placée dans un répertoire dans notre serveur et l’affichée.
Figure 4.26 : Les dépendances de l’application mobile
4.8.5
La structure du projet
Tout projet Android doit respecter une hiérarchie bien précise qui permettra au compilateur
de retrouver les différents éléments et ressources lors de la génération de l’application. Cette
hiérarchie favorise la modularité des applications Android.
CHAPITRE 4. IMPLÉMENTATION
105
A la création du projet, Android Studio crée automatiquement des dossiers pour contenir les
fichiers de code Java, les fichiers XML, et les fichiers multimédias.
L’explorateur de projet nous permettra de naviguer dans ces dossiers. Ce projet a les caractéristique
du modèle MVC car on a le package Activities qui représente les contrôleurs de notre application, Models représente le modèle et on trouve les vues dans le package Layout. On trouve
l’URL de notre API dans le package API, les icônes et les images dans le package Drawable, le
package Data a les classes qui nous aide à manipuler notre application. Ces classes sont : SharedPrefProfessor/SharedPrefStudent qui laisse l’utilisateur connecté, List Adapter permet de
lister les éléments voulus.
Le package Values contient les valeurs des couleurs, styles et strings.
Figure 4.27 : La structure du projet Android
CHAPITRE 4. IMPLÉMENTATION
4.8.6
Captures de l’application mobile
Figure 4.28 : Capture 1 de l’application mobile
106
CHAPITRE 4. IMPLÉMENTATION
Figure 4.29 : Capture 2 de l’application mobile
107
CHAPITRE 4. IMPLÉMENTATION
Figure 4.30 : Capture 3 de l’application mobile
108
CHAPITRE 4. IMPLÉMENTATION
4.9
109
Conclusion
Dans chapitre on a présentée l’environnement de développement et les technologies utilisés
pour mettre en place le système conçu dans les chapitres précédents.
On a présenté l’environnement de développement et les spécifications matérielles utilisés pour
mettre en place le système d’information en question.
Une application Web est mise en place pour permettre aux utilisateurs d’administrer le système
ainsi qu’un appareil de prise de présences.
Une application mobile est mise en place pour permettre aux utilisateurs d’accéder aux informations fournies par le système.
Le résultat de ce chapitre est la solution proposée et conçue ultérieurement qui répond aux
besoins des utilisateurs exprimés dans le cahier des charges.
Chapitre 5
Conclusion générale
Dans ce mémoire, on a présenté les différentes étapes et phases de développement d’un projet
logiciel. Dans un premier temps on a élaboré une étude préliminaire, ensuite on a présenté l’architecture du système qui est le résultat de l’étape de conception et au final on a implémenté
le système conçu à la base des différentes documentations établis dans les étapes précédentes.
Le premier avantage du système conçu et mis en place est d’automatiser la tâche de prise de
présences manuelle. Le système offre une interface de gestion qui permet aux administrateurs
de mieux contrôler les séances pédagogiques. Il offre aussi une interface de visualisation des
statistiques, cela permet aux gérants de la faculté de prendre des meilleures décisions.
Le système peut être amélioré par :
• L’intégration des technologies moins chers lors de la construction de l’appareil de prise de
présences.
• La transformation de l’appareil conçu et réalisé en un seul circuit sur une carte modulaire.
• Rendre la communication entre les APIs et la base de données plus sécurisée en appliquant des technologies d’authentification.
• Améliorer l’interface graphique de l’application mobile et du site web en appliquant les
règles du design UI/UX.
110
Acronymes
API Applicaition Programming Interface. 24, 96
BF besoin fonctionnel. 27
BNF besoin non-fonctionnel. 27
CDC cahier des charges. 22
CDCF cahier des charges fonctionnel. 22
CDCT cahier des charges technique. 22
DA diagramme d’activités. 16
DC diagramme de communication. 16
DCL diagramme de classes. 15
DCO diagramme de composants. 16
DCU Diagramme de cas d’utilisation. 29
DD diagramme de déploiement. 16
DET diagramme d’états-transitions. 16
DO diagramme d’objets. 16
DS diagramme de séquence. 16
EER Enhanced entity-relationship. 68
GPIO General Purpose Input/Output interface. 6, 93, 98
IDE environment de développement intégré. 82
JSON JavaScript Object Notation. 96, 98
JSTL JavaServer Pages Standard Tag Library. 83
MVC Model-View-Control. 84
111
Acronymes
REST Representational State Transfer. 96
RFID Radio Frequency Identification. 94
SGBD Système de gestion de base de données. 66
SSH Secure Shell. 91
TIC Technologies de l’information et de la communication. 9
UP processus unifié. 17
112