You are on page 1of 67

UNIVERSITÉ MOHAMMED V DE RABAT

Faculté des Sciences

Département d’Informatique
Filière Licence fondamentale
en Sciences Mathématiques et Informatique

PROJET DE FIN D’ÉTUDES

intitulé :Application de gestion des notes des évaluations et des délibérations
des résultats des examens.
Saisie des notes, délibérations modulaire, semestrielle, annuelle et gestion de l’historique

Présenté par : MOHAMED Boudouar - MEHDI Sakhi

soutenu le lundi 27 Juin devant le Jury

M. Said SLAOUI Professeur à la Faculté des Sciences - Rabat Président
M. Younès EL AMRANI Professeur à la Faculté des Sciences - Rabat Examinateur
M. Oussama REDA Professeur à la Faculté des Sciences - Rabat Encadrant

Année universitaire 2015-2016
Résumé : L’objectif principal de ce projet tutoré est de réaliser une application
pour la saisie des notes des étudiants et les délibérations des résultats des examens. En
minimisant les déplacements et les mouvements de la main. L’application offre un espace de
saisie des notes intuitif, simple et optimal rendant ainsi cette opération plus confortable à ses
utilisateurs. En outre, l’application permet le traitement des notes d’étudiants par modules,
par semestre et par année. Elle permet aussi les fonctionnalités d’édition et de reporting
des résultats de traitement dans leur forme basique. Un ensemble de design patterns ont
été aussi utilisés pour contourner les différents problèmes de conception rencontrés lors de
la phase de développement du système. L’interface graphique utilisateur de L’application a
été réalisée avec la bibliothèque javaFX du langage JAVA et le gestionnaire de projets Java
Maven a été utilisé pour le déploiement de l’application..

Mots clés : IHM,JAVAFX, Design Patterns, Maven

student marks management application
Abstract : The main objective of this project consists of releasing a graphical user
interface that facilitate the entry of marks, and managing the results in an easy process.
Taking into account that this application has to be easy to use. The application has been
created using javaFX which is a Java library. It has been decided to use some design patterns
that respond to various design problems, and finally Maven as a Java project manager has
been chosen guaranteeing the deploy phase of the project.

Keywords : GUI,JAVAFX, Design Patterns, Maven
Remerciements
Nous tenons à remercier profondément notre encadrant Pr. REDA Oussama pour son
encadrement judicieux ainsi que pour sa patience et son dévouement envers ses étudiants.
Nous le remercions d’avoir été généreux dans le partage de ses connaissances et de ses
précieux conseils avec toute son expertise et expérience.

Nous tenons à remercier énormément Pr. Said SLAOUI d’avoir accepté de présider le
jury de soutenance. Nous remercions également Pr. EL AMRANI Younès d’avoir accepté
d’être examinateur de notre rapport.

Nous tenons à remercier l’ensemble des enseignants pour la formation de qualité qu’on
a eu durant les trois ans de formation à la faculté des sciences de Rabat et pour les efforts
qui nous ont fourni afin que ce projet de fin d’études soit fructueux et profitable.

Merci aussi à toutes nos familles, et tous les camarades, ainsi que tous ceux qui ont de
près ou de loin contribué à la réalisation de ce travail.
Table des matières

1 Introduction générale 3

2 Les Règles métier 5
2.1 Organisation de l’année universitaire . . . . . . . . . . . . . . . . . . . . . . 5
2.2 La nature des modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 La nature de l’épreuve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Pondération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Validation et acquisition du module par compensation . . . . . . . . . . . . . 6
2.6 Validation du semestre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 La modélisation 9
3.1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Étude Fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Diagramme des cas d’utilisations . . . . . . . . . . . . . . . . . . . . 10
3.2.3 Diagrammes d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.4 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.5 Importation des Fichiers Excel . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Réalisation 21
4.1 Technologies et Frameworks utilisés . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1 JavaFX 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.2 Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3 L’utilisation des threads . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.4 Apache POI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.5 Apache Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.6 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Conclusion et perspectives 61

1
2
Chapitre 1

Introduction générale

L’amélioration de la gestion des notes des étudiants d’une façon automatisée est une né-
cessité pour faciliter le travail des utilisateurs notamment les enseignants et l’administration
qui déploient actuellement beaucoup d’efforts et de temps.

En effet, ceci nous a incité à chercher des solutions permettant d’une part la gestion des
données d’une façon simple et fiable et de gain du temps en remplaçant le traitement de ces
données par les outils bureautiques usuels (Microsoft Excel,LibreOffice Calc. . . ).
D’autre part offrir à l’utilisateur des interfaces graphiques pour la saisie des notes à
travers des outils simples(curseur,liste, texte) pour avantages de minimiser les déplacements
entre le clavier et la souris, élimination des risques d’erreurs typographiques, élimination
des bugs résultants des entrées non valides et finalement prendre en compte le confort de
traitement pour l’utilisateur.

Le rapport présent a pour objectif de présenter la réalisation de l’application qui met en
place un gestionnaire évolué des notes qui offre des interfaces graphiques faciles à tous les
utilisateurs.

Dans un premier chapitre, nous avons commencé par une étude sur les règles métier éta-
blies par notre faculté, ensuite nous procédons à la phase d’analyse et de conception dans le
deuxième chapitre en identifiant les différents besoins ce qui nous mène vers l’étude fonction-
nelle et technique qui a pour objectif de définir les acteurs et les fonctionnalités principales.
Enfin le troisième chapitre nous introduisons les différentes outils de programmation utilisés
ainsi qu’une vue globale sur la réalisation de l’application.

3
4
Chapitre 2

Les Règles métier

Introduction
Dans ce chapitre, nous allons commencer par une présentation globale du règlement
d’évaluation établie par la faculté des sciences de Rabat(Voir annexe extrait CNPN), en
présentant les différentes règles des évaluations et l’organisation de l’année universitaire .

2.1 Organisation de l’année universitaire
L’année universitaire est composée de 2 semestres correspondant à deux sessions :
— Une session d’automne de septembre à mi-février.
— Une session de printemps de mi-février à fin juillet.
Le cycle de Licence est organisé en 6 semestres. Chacun de ces semestres comporte 6
modules, à l’exception les deux premiers semestres qui comportent 7.

2.2 La nature des modules
Le module est l’unité fondamentale du système de formation. Il peut être dispensé sous
forme d’une ou de plusieurs formes suivantes :
— Cours théoriques.
— Travaux dirigés(TD).
— Projet ou stage
— Activités pratiques(TP)

2.3 La nature de l’épreuve
L’évaluation des connaissances est ainsi propre à chaque module. Jusqu’à présent elle
peut être dispensé sous forme d’une des formes suivantes
— Contrôle Final et Contrôle de TP.

5
— Controle continu et Contrôle Final.
— Contrôle Final.
— Contrôle Continu , TP et Contrôle Final(CF).

2.4 Pondération
La note d’un module est une moyenne pondérée des différentes évaluations du module,
d’où la pondération tient compte de la nature de l’évaluation(contrôle continu, TP et contrôle
final).
Exemples :
— Note des modules avec TP 0.25 et contrôle final 0.75.
— Note des modules sans TP : Contrôle continu 0.5 et contrôle final 0.5.
— Note des modules avec TP et CC et CF : 0.25 pour les CC ,0.25 TP et 0.5 pour les
CF.

2.5 Validation et acquisition du module par compensa-
tion
Un module est acquis soit par validation soit par compensation.
1. Un module est validé si sa note est supérieure ou égale à 10/20.
2. Un module est acquis par compensation si l’étudiant valide le semestre dont fait partie
ce module.

2.6 Validation du semestre
— Un semestre de cycle Licence est validé si la moyenne des notes obtenues dans les
modules composant le semestre est au moins égale à 10/20 et si aucune note de l’un
de ces modules n’est inférieure à 5/20.
— Les étudiants n’ayant pas validé un semestre, peuvent le valider par compensation
annuelle entre les semestres de la même année si les deux conditions suivantes sont
satisfaites :
1. La moyenne des notes obtenues dans les deux semestres concernés est supérieure ou
égale à 10/20 ;
2. Aucune note de l’un des modules des semestres concernés n’est inférieure à 5 sur 20.

6
Les règles métier :

Figure 2.1 – règles métier de traitement par module

Figure 2.2 – règles métier de traitement par semestre

7
Figure 2.3 – règles métier de traitement par année

Conclusion
Ce chapitre était consacré à l’étude des différentes règles métier. Dans le prochaine cha-
pitre nous allons entamer l’identification des besoins ensuite la modélisation et l’étude tech-
nique et fonctionnelle de notre application.

8
Chapitre 3

La modélisation

Introduction
Ce chapitre traite tout ce qui est observation et analyse, qui sont deux phases nécessaires
pour tracer le fonctionnement général de l’application, extraire les besoins de l’utilisateur et
faire une étude fonctionnelle générale.

3.1 Analyse des besoins
Actuellement, les enseignants et l’administration utilisent des outils bureautique dans
tous ce qui concerne la gestion des notes des étudiants. Ces logiciels présentent de nombreux
inconvénients, a titre d’exemple les déplacements incommodes entre le clavier et la souris et
les erreurs typographiques.
Tous cela nous a amené à développer un gestionnaire évolué qui remplace d’une façon
automatisée le travail des utilisateurs qui déploient beaucoup d’efforts et perdent du temps.

3.2 Étude Fonctionnelle
3.2.1 Identification des acteurs
L’application est destiné pour :
— Les enseignants.
— Les chef de filières.
— L’administration.

9
3.2.2 Diagramme des cas d’utilisations
Avant d’aborder les cas d’utilisations de notre application, en générale l’application per-
met le traitement des notes par modules ce qui facilite le travail des enseignants d’une part
, ainsi que par semestre et par année. Elle permet aussi les fonctionnalités édition et de
reporting des résultats de traitement dans leur forme basique afin d’offrir a l’administration
et les chefs de filières un outil qui remplace le traitement normale.
Après avoir capturé tous les besoins fonctionnels attendus de notre application, nous
procédons au diagramme des cas d’utilisations qui permet de décrire les interactions entre
les utilisateurs (cités en haut) et les différentes fonctionnalités.

Figure 3.1 – Diagramme des cas d’utilisation de l’application

L’utilisateur :
— Commence le traitement par choisir le mode de la délibération c’est-à-dire le mode
de délibération annuelle, semestrielle, ou bien par module.

10
— Saisit les notes d’un module afin de calculer les moyennes des étudiants après l’im-
portation de fichier Excel qui contient la liste des étudiants inscrit dans le module.
— Peut effectuez des statistiques sur les résultats obtenues.
— Peut effectuer la délibération entre les unités d’un semestre après l’importation des
fichiers des modules avec leurs historiques.
— Peut effectuer la délibération entre les unités des deux semestres c’est à dire une déli-
bération annuelle après l’importation des fichiers des modules avec leurs historiques.
— Exporte les résultats complètes de chaque délibération sous un fichier Excel.
— Peut effectuer des filtres sur les résultats des étudiants en fonction de code, nom, pré-
nom, et la moyenne générale(inférieur,supérieur ou égale)ou la mention de validation
(validé, non validé, par compensation).
— Exporte les résultats des filtres sous format Excel.

3.2.3 Diagrammes d’activités
Afin de présenter les différents cas d’utilisations, nous proposons d’utiliser les diagrammes
d’activités pour avoir une vision sur l’ensemble des actions.
La première tâche consiste à choisir le mode à suivre. C’est une étape très importante
pour déterminer le traitement à suivre.

11
Traitement des modules : Après le choix du mode convenable et exact, l’interface
graphique propose à l’utilisateur d’importer le fichier Excel des étudiants, afin de saisir les
notes à travers l’interface graphique en utilisant les différents modes de saisie qui optimise les
mouvements de la main conduisant à une opération de saisie confortable pour les utilisateurs.
— par curseur(page 37, figure 4.12 ).
— par liste( page 38, figure 4.13).
— par texte( page 39,figure 4.14).

Figure 3.2 – Diagramme d’activité de traitement par Module

12
Traitement des semestres :
Comme nous avons annoncé dans le règlement, la délibération semestrielle consiste à
calculer la moyenne générale entre les unités.
Après le choix du mode délibération semestrielle, la première étape consiste à importer
les fichiers des modules après le rattrapage.

Figure 3.3 – Diagramme d’activité de traitement par semestre

13
Traitement par Année :
La délibération annuelle consiste a calculer la moyenne entre les unités des deux semestres.
La première étape consiste à importer les notes en se servant des fichiers Excel des modules
des deux semestres.

Figure 3.4 – Diagramme d’activité de traitement par année

3.2.4 Diagramme de classes

Pour implémenter les règles métier présentées dans le chapitre précédent,nous proposons
le diagramme de classes suivant :

14
Figure 3.5 – Diagramme de classes

3.2.5 Importation des Fichiers Excel

La tache de l’importation des fichiers est très importante pour le déroulement normale de
l’application , pour évité tous cas d’erreurs nous proposons d’utiliser les formats suivantes.

3.2.5.1 Importation des Fichiers des Modules

Examens de session Normale :
Le traitement des notes des modules au session normale, est basé sur un fichier contient
la liste des étudiants inscrits dans le module.

format proposé :

15
Figure 3.6 – Format de Fichier des Modules : session Normale

Examens de session de Rattrapage :
Le traitement au session du rattrapage est différent de celui de la session normale, car il
est nécessaire d’importer le fichier de la session normale qui contient la liste des étudiants
inscrits dans le module avec leur notes, afin de faire le calcule qui concerne les rattrapages
annoncé dans le règlement.

Les Formats Proposés :

— Mode Contrôle Final et Contrôle de TP .

Figure 3.7 – Format de Fichier CF et TP :pour la session Rattrapage

— Mode Contrôle continu et Contrôle Final.

16
Figure 3.8 – Format de Fichier CC et CF :pour la session Rattrapage

— Mode Contrôle Final.

Figure 3.9 – Format de Fichier CF seul :pour la session Rattrapage

— Mode Contrôle Continu ,TP et Contrôle Final.

17
Figure 3.10 – Format de Fichier CC, TP et CF :pour la session Rattrapage

3.2.5.2 Importation des fichiers de la délibération par semestre

Le traitement de la délibération semestrielle nécessite l’importation des fichiers des mo-
dules après le rattrapage, ces derniers contenant les notes avant et après la session de rat-
trapage, mais le problème qui se pose est comment avoir la note d’un étudiant inscrit déjà
dans un module dans les années précédentes et dans le reste des modules cette année ?
Solution : l’application propose à l’utilisateur d’importer les fichiers de chaque module
de semestre courant et tous l’historique des modules au années précédentes, ce qui facilite
le travaille manuelle de l’administration auparavant grâce a une fonction générique qui offre
la possibilité d’importer un nombre infini des fichiers excel, afin de remplacer le traitement
à travers une base des données.
Après la session de rattrapage l’application exporte les résultats sous un format précis
selon le mode du module.

Les Formats Proposés :

— Mode Contrôle Final et Contrôle de TP .

18
Figure 3.11 – Format de Fichier CF et TP :après la Session du Rattrapage

— Mode Contrôle Final.

Figure 3.12 – Format de Fichier CF seul :après la Session du Rattrapage

— Mode Contrôle Continu ,TP et Contrôle Final.

19
Figure 3.13 – Format de Fichier CC, TP et CF :après la session du Rattrapage

3.2.5.3 Importation des fichiers de la délibération annuelle
Le traitement de la délibération annuelle nécessite l’importation de tous les fichiers des
modules des deux semestres(12 Modules ou 14 Modules), ces derniers contenant les moyennes
générales obtenus après la session de rattrapage.
On à adopter la même solution de la délibération semestrielle pour résoudre le problème
qui nous face à-propos des étudiants déjà inscrit dans certains modules au années précé-
dentes, ce qui nécessite d’avoir un historique des modules dans le but de faire la délibération
avec toutes informations requises.

3.3 Conclusion
Dans ce chapitre nous avons essayé d’extraire tous les besoins de l’utilisateur, en suite nous
avons présenté une étude techniques et fonctionnels du projet. Dans le prochaine chapitre
nous allons introduire les outils utilisés et les interfaces graphiques des applications conçues.

20
Chapitre 4

Réalisation

Introduction
Ce chapitre a pour objectif de définir la dernière phase du processus du développement
de l’application. Il comporte les outils utilisés, la réalisation et le test de l’application. Nous
présentons alors l’architecture de notre solution en détaillant les différentes parties et leurs
fonctionnalités.

4.1 Technologies et Frameworks utilisés

4.1.1 JavaFX 8
4.1.1.1 Définition

JavaFX est une bibliothèque graphique intégrée dans le JRE et le JDK de Java, elle
permet de réaliser des interfaces graphiques évoluées et modernes grâce à de nombreuses
fonctionnalités, telles que les animations, les effets, la 3D, l’audio, la vidéo, etc. Elle a de
plus l’avantage d’être dans le langage Java, qui permet de réaliser des architectures avec des
paradigmes objet.

4.1.1.2 Bref historique

Avant d’aborder les concepts principaux de JavaFX il est nécessaire de présenter une
chronologie des principales étapes d’évolution du domaine de développement des applications
avec des interfaces graphiques en java

21
Figure 4.1 – Chronologie des principales étapes de développement des Interfaces graphiques
en Java

4.1.1.3 Potentiel de JavaFX
1. JavaFX étant le résultat de développements récents, il bénéficie de concepts modernes.
2. La possibilité de découpler le design graphique pour adopter le MVC.
3. L’intégration de feuilles de style CSS renforce encore la séparation entre le design
graphique et les traitements.
4. Différents composants complexes(graphes 2D,3D...).

4.1.1.4 Scene Builder
JavaFX Scene Builder est un outil open source de mise en page visuelle qui permet de
concevoir rapidement des interfaces, avec modification simple et générer le code FXML au
format XML dont la syntaxe est conçue pour décrire la vue avec ses composants.

4.1.2 Design Patterns
4.1.2.1 Définition
Les design patterns représentent les meilleures pratiques utilisées par les développeurs de
logiciels orientés objets expérimentés. Ils sont des solutions aux problèmes généraux que les
développeurs de logiciels confrontés au cours du développement de logiciels.

22
4.1.2.2 MVC pattern
Il existe différentes manières de structurer le code des applications interactives, une de ces
architectures communément utilisée, et qui comporte de nombreuses variantes, est connue
sous l’acronyme MVC qui signifie Model - View - Controller.
— Le modèle(Model) se charge de la gestion des données (accès, transformations, cal-
culs, etc.),il enregistre (directement ou indirectement) l’état du système et le tient à
jour(Extension .Java).
— La vue(View) représente la visualisation des données qui contient le modèle(Extension
.Fxml).
— Le contrôleur(Controller) est chargé de réagir aux actions de l’utilisateur (clavier,
souris, gestes)(Extension .Java)
Notre application est composée de nombreuses interfaces graphiques, afin de faciliter le
traitement et utiliser les points forts de javafx , nous avons décidé de travailler avec le MVC
de telle sorte que le code soit plus lisible et plus adaptable avec le modèle de gestion des
notes et a toute prochaine mise a jour probable.

4.1.2.3 Observer pattern
Observer pattern est l’un des design patterns comportementales, il est utile lorsque on
s’intéresse par l’état d’un objet et que nous souhaitons être averti à chaque fois qu’il y a un
changement. En modèle d’observateur, l’objet qui montre l’état d’un autre objet est appelé
observer et l’objet qu’est surveillé est appelé Subject.

Avant d’aborder l’intérêt d’utiliser observer pattern, nous détaillons la tache qui suit
l’importation des fichiers qui prépare les données pour le contrôleur afin de les afficher
dans un composant graphique qui s’appelle TableView, En effet ce dernier est l’un des
contrôles virtualisés en javaFX, qui nécessite dans un premier temps de définir une classe
modèle TableClass au package(src.main.java.Models.Helpers) qui aura quelques variables
d’instance pour le code, le nom, le prénom et les notes. afin de produire une liste observable
"ObservableList " qui contient l’ ensemble des object de type TableClass.

Avec JavaFX il est courant d’utiliser les instances de type "Property" pour tous les
champs de la classe TableCLass. Une propriété (Property) nous permet, par exemple, d’être
automatiquement averti lorsque la variable code ou toute autre variable a été modifiée. Ceci
nous aide à maintenir la vue synchronisée avec les données. suite à cela et en respectant les
besoins, chaque mode des modules a son propre format de fichier, ce qui nécessite de définir
une fonction d’importation pour chaque mode afin de produire la structure de données des
objet TableClass pour alimenter le Tableview.

En respectant la structure de notre modèle avec le motif MVC et en adoptant le modèle
de gestion des notes on propose une structure de données sous une classe qui contient
deux type des données, ObservableList<TableClass> et une liste de type LesEtudiants. Le

23
contrôleur de chaque interface graphique fait appel à la fonction qui convertie le fichier
Excel importé vers un objet de type Properity qui contient les deux listes de même contenu,
la premier avec des objets observables de type TableClass pour la vue de l’interface et
l’autre de Type Etudiant pour le modèle de gestion des notes.

En suite après le choix de la structure de données, il faut chercher un outil qui nous
permet de lier les deux listes, c’est-à-dire un outil qui synchronise la liste Observable avec la
liste des étudiants à chaque changement, sachant que le traitement des notes est établie à la
liste LesEtudiants, d’autre part un des avantages des propriétés JavaFX est la possibilité de
pouvoir lier les propriétés entre-elles. Ce mécanisme, appelé "binding", permet de mettre à
jour automatiquement une propriété en fonction d’une autre. Par exemple lorsque la variable
code ou toute autre variable de chaque objet de type TableClass de la liste observable est
modifiée, automatiquement il averti l’objet de type Etudiant qui prend le même code afin
de changer la valeur du code d’une manière qui tienne compte de la stabilité des deux listes.

En outre dans notre projet on a remplacé le principe de "Data Binding" par "the
Observer design pattern", ce dernier contrairement au "Data Binding" permet le contrôle
des mises a jour après avoir reçu les notifications, en effet la mise a jour de l’état de l’objet
observer (qui est intéresse par l’état d’un autre objet observé nommé "subject") ne se fait
qu’après une vérification selon des critères pour le but de valider la mise a jour comme on
peut la négliger. Suite a cela on a développé un modèle qui jouera le rôle d’une forme stan-
dard (classes + interfaces) de toute les fenêtres de telle sorte que le code soit plus lisible et
plus adaptable avec le modèle de gestion des notes et à toute prochaine mise a jour probable.

Avant de passer à l’implementation de la solution, "observer pattern" passe par une
implementation d’un autre design pattern nommé "The strategy pattern" qui permet de
définir un contrat en utilisant des interfaces, ce contrat explique le comportement des
objets concernés par l’observation(observer/subject), autrement dit ces interfaces du contrat
contient la signature des méthodes appelés l’or du changement d’état d’objet surveillé
quant pour l’objet observateur, ce qui rend le code plus lisible et plus adaptable au futur
améliorations, en effet pour effectuer une mise a jour au niveau du code il ne faut qu’a
changer le contrat, par contre le "Data binding" relie des objets sans contrat ou contrôle,
il fait la mise ajour automatiquement. On avait du mal a l’utiliser pour effectuer des
mises a jour au niveau du structures de données dédiées au étudiants car cela nécessite
le binding de tous ses attributs aux ceux du "TableClass" qui n’est pas évident tous le
temps car ceci nécessite des opérations compliquées au niveau des structures de données
pour maper les objets de type "Etudiant" et ceux du type "TableClass" et établir un
lien entre leurs attributs avec le binding car leur indices en structures de données est en
changement permanent, à part le fait que la destruction en mémoire d’un objet que leur
attribut participent dans un binding va générer une erreur.

D’autre part le "Data Binding" contrairement au "the observer design pattern" utilise

24
des processus légers "Threads" qui tournent tout le temps avec un cycle, ce qui alourdit
la plateforme, ou même des fois le dépassement du "java memory heap" dans le cas ou il
existe plusieurs étudiants, donc c’est une perte non justifiable des ressources.

En respectant la structure de notre modèle avec le motif MVC, Observer pattern est
également un élément important dans ce cas, où la vue doit observer des changements dans
le modèle, suite à nos besoins et en respectant le modèle de gestion des notes en propose Le
modèle suivant, qu’est adoptable à toutes les interfaces graphiques.

le diagramme de classes UML (figure 4.2) qui montre les participants de motif dans ce cas :

Figure 4.2 – Diagramme de classes de motif Observer

la mise en oeuvre d’observer pattern :
la mise en oeuvre du observer pattern passe par l’implementation du strategy pattern
pour définir le contrat du mise a jour (update ,notifyObserver(),register()...).

25
Nous avons une interface "Subject", qui fournis des observateurs et ainsi que pour
attacher et détacher des objets observateurs. De l’autre côté, nous avons un observateur
"TableViewObserver", qui définit des méthodes update() utilisées par la classe Etudiant
pour notifier les changements dans la classe "TableClass".

Les deux interfaces sont respectivement prolongés par "TableClass, qui stocke l’état des
objets d’observation et envoie une notification à ses observateurs après chaque changements
d’état. Et par la classe Etudiant, qui redéfinit la méthode update () pour maintenir son état
compatible avec celui de TableClass.

4.1.3 L’utilisation des threads
Par défaut, un programme JavaFX a un thread(processus léger). Ce thread exécute le
code dans le programme de démarrage et de fin avec la méthode Main. Chaque instruction
exécutée par Main(soit directement soit indirectement) est effectuée par la valeur par
défaut, ou thread principal, et ce thread se termine lorsque Main est retournée. Toutefois,
les threads auxiliaires peuvent être créés et utilisés pour exécuter le code en parallèle avec
le thread principal. Ces threads sont souvent appelés threads actifs.

le design pettern "Produce/consume"
On a utiliser le design pettern "Produce/consume" (Producteur/ consomateur) avec des
processus legers. Le thread chargé au lancement de l’application et le thread producteur le
thread chargé a la recherche des erreurs qui se produisent au niveau de l’application.

Deuxième utilisation
Dans notre application pas mal des objets du "java Concurrency package" on été utilisé,
certain pour se débarrasser des éléments de vue quand on en a pas besoin (ce sont des
garbage cleaners qui nettoient l’a vue), il tournent souvent avec un cycle (idée inspiré du
garbage cleaner de Java qui fait le nettoyage des objets au niveau du tas (heap memory)),
il y en a d’autres qui marchent pour une durée limitée durant toute leur période de vie,
et il y en a d’autre qui marchent seulement si on en a besoin sinon il revient a l’état du
sommeille pour ne pas gaspiller les ressources et pour permettre aussi une rapidité au niveau
de l’application qu’était un peu lourde dans un premier temps.

Fixage des bugs du JavaFX 8
Comme cette bibliothèque est assez récente, c’est normale qu’elle contiennent pas mal
de bugs. Qu’on on a voulu de créer de zero des composants graphiques personnalisés qui
ne sont pas définie dans la librairie JavaFX8, on avait besoin de définir leur vue et leur
comportement, comme on a fait avec les cellules personnalisés des tableau, par exemple
un composant graphique slider qui apparaît l’or du clique sur une cellule du tableau pour
pouvoir saisir les note, mais ce composant graphique a un bug qui génère des valeurs erronées
l’or du glissement de ce slider, on a joué un peu avec les threads pour pouvoir s’en sortir.

26
4.1.3.1 Programmation événementielle
La programmation des applications avec interfaces graphiques est généralement basée
sur un paradigme nommé programmation événementielle, avec ce type de paradigme les
événements (généralement déclenchés par l’utilisateur, mais aussi par le système) qui pilotent
l’application. Ce mode non directif convient bien à la gestion des interfaces graphiques.
En programmation événementielle, on prépare les actions(code en java) à exécuter en
les associant aux événements que l’on souhaite traiter et on attend que le processus de sur-
veillance nous avertisse en exécutant le code prévu. Comme les composants des interfaces
graphiques sont diverses, chaque composant graphique a sont contrôleur, c’était indispen-
sable d’établir une sorte communication entre ces contrôleurs , ça ce fait par la création des
évènements personnalisés (des classe de type Event) , quand un contrôleur veut envoyer des
objets ou bien des structures de données a un autre, il lui envoie un évènement qui porte
des objets afin de le capturé par le contrôleur destinataire, et ensuite faire le traitement
convenable.
Ainsi que un évènement peut être capturé et renvoyer par plusieurs contrôleurs avant
d’arriver a la destination finale selon le hiérarchie des fichiers(.fxml).

4.1.4 Apache POI
Apache POI est une API populaire qui permet de créer, modifier et même si décoder
les données d’entrée d’utilisateur ou écrire un fichier MS Office Excel. Est une bibliothèque
open source développer et distribuer par Apache Software Foundation pour le traitement des
fichiers Microsoft Office en utilisant un programme Java .

4.1.5 Apache Maven
L’utilisation de plusieurs bibliothèque au sein de notre application a généré une défaillance
au niveau de la gestion du programme d’où la nécessite d’avoir recours à Apache Maven qui
un outil pour la gestion et l’automatisation de production des projets logiciels java (pour
notre cas la fonctionnalités dont on a besoin est sa gestion des dépendances).

4.1.6 Implémentation
L’application en générale contient 8 modes pour les traitements des modules, 2 modes de
la délibération semestrielle (6 modules et 7 modules) ainsi que 2 modes de la délibération
annuelle(6 modules et 7 modules).
L’interface graphique principale de l’application est sous forme d’un slider qui contient
des images des modes avec la description de chacun.

Traitement des modules
Après le choix du mode convenable, l’application propose à l’utilisateur d’importer le
fichier(Excel) qui contient la liste des étudiants inscrits dans le module. en suite l’interface

27
du mode choisie s’affiche pour commencé le traitement( exemple :figure 4.3).

Figure 4.3 – choix des feuilles a partir de fichier Excel importé

28
Mode TP et CF :

Figure 4.4 – mode TP et CF

29
Mode TP, CC et CF :

Figure 4.5 – Mode TP, CC et CF

30
Mode CF seul :

Figure 4.6 – Mode CF seul.

31
Mode CC et CF :

Figure 4.7 – Mode CC et CF.

32
Mode rattrapage de TP et CF :

Figure 4.8 – mode rattrapage TP et CF

33
Mode rattrapage de CC, TP et CF :

Figure 4.9 – mode rattrapage CC, TP et CF

34
Mode rattrapage de CF :

Figure 4.10 – mode rattrapage CF

35
Mode rattrapage de CC, CF :

Figure 4.11 – mode rattrapage CC, CF

36
La saisie des notes :

Figure 4.12 – Insertion par slider

37
Figure 4.13 – Insertion par une liste

38
Figure 4.14 – Insertion par text

39
Affichage des statistiques en graphe :

Figure 4.15 – Affichage des statistiques

40
Statistiques en graphe :

Figure 4.16 – Affichage des statistiques

41
Exportation du graphe :
L’application offre à l’utilisateur le choix d’exporter le g´raphe’ en format PDF/PNG/JPG.
Exemple d’exportation en pdf(figure 4.17).

Figure 4.17 – Exemple d’exportation en PDf

42
D’autre part l’application permet à l’utilisateur d’effectuer des filtres sur les résul-
tats.(figure 4.17). Ces derniers sont exportables en format Excel.

Figure 4.18 – Activation du filtrage

43
Les filtres disponibles :

Figure 4.19 – filtrage par nom, code ou prénom

44
Figure 4.20 – filtrage par moyenne supérieur

45
Figure 4.21 – filtrage par moyenne inférieur

46
Figure 4.22 – filtrage par moyenne égale

47
Figure 4.23 – filtrage par validation

48
Le traitement des modules se termine par l’exportation du fichier en format Excel.
exemple l’exportation de traitement du mode 1(figure 4.24)

Figure 4.24 – Exportation des résultats

49
Figure 4.25 – Fichier exporté

50
la délibération semestrielle :
Après le choix du mode délibération semestrielle de 6 modules, l’application affiche l’interface
suivante(figure 4.26).

Figure 4.26 – Espace de la délibération semestrielle

51
Comme nous avons annoncé l’application propose à l’utilisateur d’importer les fichiers de
chaque module de semestre courant et tous l’historique des modules au années précédentes,
ce qui facilite le travaille manuelle de l’administration et le chef de filière auparavant grâce
a une solution qui offre la possibilité d’importer un nombre infini des fichiers Excel, afin de
remplacer le traitement à travers une base des données.

Figure 4.27 – Espace d’importation des fichiers

52
A titre d’exemple après l’importation des modules de semestre courant, on passe à l’im-
portation de l’historique, en prend l’historique de module UML des deux années 2014/2015
et 2013/2014. la même chose pour les autres modules il suffit juste choisir le nom de module
parmi les autres dans la liste. ensuite un espace de drag and drop s’affiche afin de déposer le
fichier dans l’icône créée (figure 4.28).

Figure 4.28 – importation de l’historique

Après l’importation de tous les fichiers, afin de faire la délibération on clique sur le bouton
"CommencerDelib" pour faire les calcules en arrière plan, en suite pour retourner à l’interface
d’affichage on clique sur le bouton"Importer fichier Excel" un tableau s’affiche contient les
calcules et les résultats de la délibération semestrielle(figure 4.29).
Si l’utilisateur n’a pas sélectionné le fichier exact, il peut modifier son choix en cliquant
sur le bouton d’importation sans fermer l’application et refaire le traitement dès le dé-
but.(exemple figure 4.30)

53
Figure 4.29 – résultats de la délibération semestrielle

54
Figure 4.30 – mise à jour de l’importation

55
le fichier exporté de la délibération semestrielle(figure 4.31).

Figure 4.31 – Le fichier exporté de la délibération semestrielle.

56
La même chose pour la délibération semestrielle, on peut établir des filtres sur les résultats
et même si avec la possibilité de l’exportation en format Excel(figure 4.32) et l’affichage d’un
graphe qui donne les distributions des notes de chaque module(figure 4.33).

Figure 4.32 – Filtrage des résultats de la délibération semestrielle

57
Figure 4.33 – Graphe de distribution des notes

Délibération semestrielle 7 modules
Avant de terminer la section qui concerne la délibération semestrielle, pour le traitement
de la délibération des semestres dont le nombre des modules est égale à 7(Semestre 1 ou
2) le même traitement de la délibération des 6 modules s’applique sur le traitement des 7
modules.

58
Délibération annuelle
le traitement de la délibération annuelle nécessite l’importation de tous les fichiers des
modules des deux semestres(12 Modules ou 14 Modules), comme le cas de la délibération par
semestre l’interface de la délibération par année offre un espace d’importation des fichiers avec
la possibilité d’importation de l’historique et la modification après le choix des fichiers(figure
4.34)

Figure 4.34 – L’importation des fichiers pour la délibération par année

59
Affichage des résultats par année :

Figure 4.35 – Affichage de la délibération annuelle

60
Chapitre 5

Conclusion et perspectives

Le projet effectué a effectivement répondu à notre problématique de départ, qui est la
réalisation d’un système de gestion des notes évolué et facile à utiliser. Notre projet nous
a permis de sortir avec certaines conclusions très pertinentes. Dans un premier temps,
l’importance de suivre les étapes de génie logiciel, la chose qui mène facilement au résultat
désiré. Dans un second temps, notre projet nous a permis d’apprendre des nouvelles
technologies qui facilitent le processus de développement.

Une amélioration de l’application peut se faire en intégrant deux fonctionnalités supplé-
mentaires que nous n’avons pas pu intégrer suite à la contrainte du temps :
1. La possibilité d’ajouter une fonctionnalité d’introduire les notes à partir d’un péri-
phérique d’entrée de sons en utilisant un traitement de la reconnaissance vocale.
2. Ajouter une fonctionnalité d’impression des relevets des notes des étudiants.
Par ailleurs, ce projet nous a été bénéfique en grande partie en ce qui concerne l’or-
ganisation du travail et cela nous permettra de concevoir des applications puissantes dans
l’avenir.

61
62
Bibliographie

[1] Oracle, Java Platform, Standard Edition (Java SE) 8, 22 mai 2014
http ://docs.oracle.com/javase/8/javase-clienttechnologies.html
[2] code.makery.ch, JavaFX 8 Tutorial - Part 1 : Scene Builder , 16 Apr 2014.
http ://code.makery.ch/library/javafx-8-tutorial/part1
[3] site web proposant des questions et réponses, http ://stackoverflow.com/
[4] Observer Design Pattern, http ://sourcemaking.com/designpatterns/observer
[5] Concurrency in JavaFX , https ://docs.oracle.com/javafx/2/threads/jfxpub-threads.htm
[6] bug de javaFx , http ://stackoverflow.com/questions/14359596/javafx-graphic-bug-with-
progressbar-and-slider

63