Université de Sfax

Faculté des Sciences Economiques et de Gestion

Département d’Informatique Appliquée à la Gestion

MEMOIRE DE STAGE
POUR L’OBTENTION DE LA LICENCE FONDAMENTALE
EN INFORMATIQUE APPLIQUEE A LA GESTION

AUTOMATISATION DE LA GESTION DU REGISTRE DE

CLASSE AU SECONDAIRE

Réalisé par :
Hadj Taieb Salma

Encadré par :
Mme. HADDAR Nahla

JURY

Mme. Boukadi Khouloud : Présidente

Mme. Magdich Amina : Rapporteur
Mr. Ziraoui Tawfik : Invité

Année universitaire : 2014-2015

 Dédicaces
C'est grâce à Dieu que tout a commencé, et c'est à lui que je rends grâce.
Le reste n'est que dédicace.
Je dédie ce mémoire à tous ceux que j'estime, en guise de reconnaissance
et de gratitude pour tous les sacrifices qu'ils ont faits et pour toute la
patience et la compréhension dont ils ont fait preuve à mon égard:

Ma chère mère Hela,

Qui a été toujours là pour moi, et qui m'a toujours encouragé à progresser
dans mes études. Je ferais toujours de mon mieux pour rester un sujet de
fierté à tes yeux.

Mon cher père Kamel,

J'espère qu'il trouvera dans ce travail toute ma reconnaissance et tout
mon amour.

Ma chère sœur Sana,

Pour votre bonté, votre générosité, votre serviabilité et votre
dévouement.
Pour les liens sacrés et éternels qui nous unissent.
Que dieu vous fasse réaliser tous ce que vous souhaitez et vous méritez.

Ma chère Mariam,
Pour la sœur agréable qu'elle était et qu'elle serait pour moi.
Tous mes amis et toute personne qui m’a soutenu moralement durant la
réalisation de ce mémoire et qui m’a motivé pour réaliser mon rêve
 Tous ceux qui m'aiment et qui ne méritent pas d'être oubliés.

Remerciements
C'est avec un grand plaisir que nous réservons cette page en signe de
gratitude et de reconnaissance pour tous ceux qui ont assisté ce travail.
Au terme de ce travail modeste nous tenons à exprimer notre gratitude à
notre encadreur Mme. Nahla Haddar, pour assurer le suivi de notre projet
avec beaucoup de bienveillance et d'encouragement aussi pour sa
gentillesse et ses conseils judicieux.
Nous exprimons notre profond respect à Mme. Amina Magdich pour
l'honneur qu'elle nous fait en acceptant de présider notre jury de mémoire
de fin d'études.
Nos sincères remerciements s'adressent également à Mme. Khouloud
Boukadi pour accepter de juger notre travail.
Nous exprimons finalement nos vifs remerciements à tous les
enseignants de la Faculté des Sciences Économiques et de Gestion de
Sfax pour les efforts qu'ils ont déployés durant toutes les années
universitaires.
 Table des matières

Introduction Générale....................................................................................................................1

Chapitre 1 : Modélisation du métier.............................................................................................4

Introduction.......................................................................................................................................................... 5
1.1 Définition de la mission.............................................................................................................................5
1.1.1 Présentation de l’application...........................................................................................5
1.1.2 Objectifs à atteindre........................................................................................................6
1.2 Repérage du domaine................................................................................................................................6
1.3 Description des processus métier...........................................................................................................7
1.4 Description des supports d’information..............................................................................................12
Conclusion...........................................................................................................................................................18

Chapitre 2 : Capture des besoins................................................................................................19

Introduction........................................................................................................................................................ 20
2.1 Acteurs du système informatisé............................................................................................................20
2.2 Modèle de contexte du système informatisé.......................................................................................21
2.3 Identification des cas d’utilisation.........................................................................................................21
2.4 Description textuelle des cas d’utilisation...........................................................................................23
Conclusion..........................................................................................................................................................40

Chapitre 3 : Analyse.....................................................................................................................41

Introduction........................................................................................................................................................ 42
3.1 Réalisation des cas d’utilisation...........................................................................................................42
3.2 Construction du modèle du domaine....................................................................................................67
Conclusion..........................................................................................................................................................68

Chapitre 4 : Conception...............................................................................................................70

Introduction.........................................................................................................................................................71
4.1 Environnement de réalisation..................................................................................................................71
4.1.1 Environnement matériel.................................................................................................71
4.1.2 Environnement logiciel..................................................................................................71
 4.2 Architecture du futur système.................................................................................................................73
4.3 Conception des schémas logiques et physique des données..........................................................74
4.4 Réalisation des cas d’utilisation.............................................................................................................75
4.4.1 Conception des interactions...........................................................................................76
4.1.2 Construction des diagrammes d’états...........................................................................85
4.1.3 Conception des classes..................................................................................................87
4.1.4 Conception des opérations complexes.........................................................................93
4.2. Composants et déploiement...................................................................................................................93
Conclusion..........................................................................................................................................................93

Conclusion Générale....................................................................................................................94

Bibliographie.................................................................................................................................96
 LISTE DES FIGURES

Figure 1.1 : Diagramme de collaboration contexte métier...........................................................7

Figure 1.2 : Diagramme de classes des travailleurs......................................................................7
Figure 1.3 : Diagramme de cas d’utilisation métier......................................................................8
Figure 1.4 : Diagramme d’activité « Livrer et contrôler registre ».............................................10
Figure 1.5 : Diagramme d’activité « Gérer les retardataires et les absents»..............................11
Figure 1.6 : Diagramme d’activité « Inscrire un élève »............................................................11
Figure 1.7 : Diagramme d’activité « Gérer les informations d’avertissement ».........................12
Figure 1.8 : Registre des présences.............................................................................................13
Figure 1.9 : Emploi du temps......................................................................................................14
Figure 1.10 : Reçu d’inscription.................................................................................................15
Figure 1.11 : Billet d’entrée........................................................................................................16
Figure 1.12 : Billet de retard.......................................................................................................16
Figure 1.13 : Proposition d’une punition....................................................................................17
Figure 1.14 : Diagramme de classe de support d’information du système métier......................18
Figure 2.1 : Diagramme de collaboration du futur système.......................................................21
Figure 2.2 : Diagramme des cas d’utilisation.............................................................................22
Figure 3.1 : Diagramme de séquence « S’authentifier ».............................................................42
Figure 3.2 : Diagramme de classes issu du UC « S’authentifier ».............................................43
Figure 3.3 : Diagramme de séquence « Inscrire un surveillant ou un professeur »....................43
Figure 3.4 : Diagramme de séquence « Modifier un professeur »..............................................44
Figure 3.5 : Diagramme de séquence « Supprimer un surveillant ou un professeur»................44
Figure 3.6 : Diagramme de séquence « Modifier un surveillant ».............................................45
Figure 3.7 : Diagramme de classes issu du UC « Gérer les utilisateurs »..................................45
Figure 3.8 : Diagramme de séquence « Enregistrer une absence, un retard ou un exclus ».......46
Figure 3.9 : Diagramme de séquence « Modifier une absence, un retard ou un exclus »..........47
Figure 3.10 : Diagramme de séquence « Supprimer une absence, un retard ou un exclus »......48
Figure 3.11 : Diagramme de classes issu du UC « Gérer les observations »..............................49
Figure 3.12 : Diagramme de séquence « Consulter fiche élève »...............................................50
Figure 3.13 : Diagramme de séquence « Ajouter un élève potentiel ».......................................51
Figure 3.14 : Diagramme de séquence « Modifier un élève potentiel ».....................................52
Figure 3.15 : Diagramme de séquence « Supprimer un élève potentiel »..................................52
Figure 3.16 : Diagramme de classes issu de l’UC «Gérer élève »..............................................53
Figure 3.17 : Diagramme de séquence « Consulter classe »......................................................53
Figure 3.18 : Diagramme de classes issu du UC «Gérer profil de classe »................................54
Figure 3.19 : Diagramme de séquence « Ajouter une inscription »...........................................55
Figure 3.20 : Diagramme de séquence « Supprimer une inscription ».......................................55
Figure 3.21 : Diagramme de classes issu du UC «Gérer profil d’inscription »..........................56
Figure 3.22 : Diagramme de séquence « Ajouter un billet »......................................................57
Figure 3.23 : Diagramme de classes issu du UC «Gérer les billets ».........................................57
Figure 3.24 : Diagramme de séquence « Ajouter une séance d’enseignement ou une séance de
rattrapage ».................................................................................................................................58
Figure 3.25 : Diagramme de séquence « Modifier une séance d’enseignement ou une séance de
rattrapage »................................................................................................................................59
Figure 3.26 : Diagramme de séquence « Supprimer une séance d’enseignement ou une séance
de rattrapage ».............................................................................................................................59
Figure 3.27 : Diagramme de classes issu du UC «Gérer les séances d’enseignement et les
séances de rattrapage »...............................................................................................................60
Figure 3.28 : Diagramme de séquence « Ajouter une classe »...................................................61
Figure 3.29 : Diagramme de séquence « Modifier une classe ».................................................61
Figure 3.30 : Diagramme de séquence « Supprimer une classe »..............................................62
Figure 3.31 : Diagramme de classes issu du UC «Gérer les classes».........................................62
Figure 3.32 : Diagramme de séquence « Ajouter une matière»..................................................63
Figure 3.33 : Diagramme de séquence « Modifier une matière »...............................................63
Figure 3.34 : Diagramme de séquence « Supprimer une matière».............................................64
Figure 3.35 : Diagramme de classes issu du UC «Gérer les matières»......................................64
Figure 3.36 : Diagramme de séquence « Ajouter une salle»......................................................65
Figure 3.37 : Diagramme de séquence « Modifier une salle»....................................................65
Figure 3.38 : Diagramme de séquence « Supprimer une salle»..................................................66
Figure 3.39 : Diagramme de classes issu du UC «Gérer les salles»...........................................67
Figure 3.40 : Diagramme de classes du domaine.......................................................................68
Figure 4.1 : Caractéristique du pc utilisé....................................................................................71
Figure 4.2 : Architecture logique de l’application......................................................................74
Figure 4.3 : Schéma physique de la base de données.................................................................75
Figure 4.4 : Diagramme de séquence de conception de scénario nominal « S’authentifier » du
UC « S’authentifier »..................................................................................................................76
Figure 4.5 : Diagramme de séquence de conception de scénario nominal « Inscrire un
surveillant ou un professeur » du UC « Gérer les utilisateurs ».................................................77
Figure 4.6 : Diagramme de séquence de conception de scénario nominal « Enregistrer une
absence, un retard ou un exclus» du UC « Gérer les observations »..........................................78
Figure 4.7 : Diagramme de séquence de conception de scénario nominal « Consulter fiche
élève» du UC « Gérer les élèves »..............................................................................................79
Figure 4.8 : Diagramme de séquence de conception de scénario nominal « Ajouter un élève» du
UC « Gérer les élèves »..............................................................................................................80
Figure 4.9 : Diagramme de séquence de conception de scénario nominal « Consulter classe »
du UC « Gérer profil de classe ».................................................................................................80
Figure 4.10 : Diagramme de séquence de conception de scénario nominal « Ajouter une
inscription» du UC « Gérer profil d’inscription »......................................................................81
Figure 4.11 : Diagramme de séquence de conception de scénario nominal « Ajouter un billet»
du UC « Gérer les billets »..........................................................................................................82
Figure 4.12 : Diagramme de séquence de conception de scénario nominal « Ajouter une séance
d’enseignement ou une séance de rattrapage » du UC « Gérer les séances d’enseignements et
les séances de rattrapage »..........................................................................................................83
Figure 4.13 : Diagramme de séquence de conception de scénario nominal « Ajouter une classe
» du UC « Gérer les classes ».....................................................................................................84
Figure 4.14 : Diagramme de séquence de conception de scénario nominal « Ajouter une
matière » du UC « Gérer les matières »......................................................................................84
Figure 4.15 : Diagramme de séquence de conception de scénario nominal « Ajouter une salle »
du UC « Gérer les salles »..........................................................................................................85
Figure 4.16 : Diagramme d’états-transitions de l’entité "Elève"...............................................86
Figure 4.17 : Diagramme d’états-transitions de l’entité "Séance".............................................86
Figure 4.18 : Diagramme de classes de conception issu du UC «S’authentifier ».....................87
Figure 4.19 : Diagramme de classes de conception issu du UC «Gérer les utilisateurs »..........87
Figure 4.20 : Diagramme de classes de conception issu du UC «Gérer les observations ».......88
Figure 4.21 : Diagramme de classes de conception issu du UC «Gérer les élèves ».................88
Figure 4.22 : Diagramme de classes de conception issu du UC «Gérer les élèves»..................89
Figure 4.23 : Diagramme de classes de conception issu du UC «Gérer profil de classe»..........89
Figure 4.24 : Diagramme de classes de conception issu du UC «Gérer profil d’inscription»....90
Figure 4.25 : Diagramme de classes de conception issu du UC «Gérer les billets»...................90
Figure 4.26 : Diagramme de classes de conception issu du UC «Gérer les séances
d’enseignements et les séances de rattrapages»..........................................................................91
Figure 4.27 : Diagramme de classes de conception issu du UC «Gérer les classes »................91
Figure 4.28 : Diagramme de classes de conception issu du UC «Gérer les matières »..............92
Figure 4.29 : Diagramme de classes de conception issu du UC «Gérer les salles »...................92
Figure 4.30 : Diagramme d’activités de l’opération « Ajouter une séance d’enseignement » de
l’entité "Séance Enseignement".................................................................................................93
Figure 4.31 : Diagramme de déploiements selon l’architecture 3_Tiers....................................93
Automatisation de la gestion du registre de classe au secondaire

Introduction Générale

Page |1
Automatisation de la gestion du registre de classe au secondaire

Avec le progrès technologique et les besoins accrus de la recherche scientifique, le secteur de

l’informatique a connu une croissance fulgurante ces dernières années. Actuellement, l’apparition
et les évolutions en matière de langages ont permis d’étendre leur application à tous les domaines
dont ceux de l’enseignement et de l’administration.

Actuellement les inscriptions des élèves, la gestion des présences ainsi que toutes les tâches
administratives sont gérées manuellement. Ceci peut générer une perte énorme de temps, voire
une perte de données liées à la pénibilité de ces tâches et à l’utilisation excessive de paperasse
dans nos administrations.
Afin de faciliter ces différentes tâches administratives, et en vue d’assurer la sécurité de
l’information, l’automatisation des tâches indirectes entre les professeurs et le bureau de présence
au sein des lycées secondaires s’avère nécessaire. D’où la problématique suivante :
 Comment peut-on réduire les inconvénients du régime manuel administratif ?
 A quels stades peut-on améliorer la rentabilité des anciens régimes manuels ?
Pour résoudre cette problématique, nous nous somme proposés de concevoir une application
baptisée « Automatisation de la gestion du registre de classe au secondaire » dans le cadre d’un
projet de fin d’étude.
Ce projet innovateur et créatif a été apprécié par le lycée privé Tawfik qui nous a invité dans ses
locaux afin de comprendre les différents problèmes liées au système administratif actuel et afin
de développer cette application en fonction des besoins des professeurs et des surveillants. Nous
nous penchons en particulier sur l’automatisation de la présence des élèves, la notification des
revois et la consultation des fichiers d’inscriptions.
Nous développons notre application en utilisant le langage C#. Une extension Androïd sera
également élaborée afin de rendre l’usage de cette application plus facile dans les salles de classe.
Le présent rapport se scinde en quatre chapitres :
Le premier chapitre intitulé Modélisation du métier est consacré à la présentation de notre
mission, à l’analyse du fonctionnement actuel du système administratif et à la modélisation
conceptuelle des flux.
Le second chapitre, Capture des besoins, illustrera une présentation des besoins fonctionnels et
techniques par rapport à l’application à développer.
Dans le troisième chapitre intitulé Analyse, nous formaliserons et analyserons les besoins
exprimés dans le second chapitre.
Le dernier chapitre intitulé Conception, décrira l’implémentation et la réalisation de
l’application par les outils de développement.

Page |2
Automatisation de la gestion du registre de classe au secondaire

Enfin, nous clôturons notre travail par une conclusion générale qui synthétise notre travail et
présente des perspectives de ce projet.

Page |3
Automatisation de la gestion du registre de classe au secondaire

Chapitre 1 : Modélisation du

métier

Page |4
Automatisation de la gestion du registre de classe au secondaire

Introduction
La modélisation du métier est un bon moyen de maîtriser la complexité du projet et d’assurer sa
cohérence. Cette modélisation est essentielle pour aboutir à une compréhension commune des
différents intervenants ainsi que le problème à étudier. La réalisation de cette étape devrait
commencer par l’étude du système et la définition de notre mission. Il faut ensuite dégager un
repérage du domaine, décrire les processus du métier et les supports d’informations.

1.1 Définition de la mission

Notre mission dans le cadre de ce projet consiste à créer une application ainsi qu’une extension
mobile permettant aux professeurs et aux surveillants de gérer les inscriptions, les présences et les
différentes autres notifications. La première sous-section présente cette application. La deuxième
sous-section décrit les objectifs à atteindre.

1.1.1 Présentation de l’application

Notre application aura comme principales fonctionnalités :

 Gestion des utilisateurs :

L’administrateur en tant que utilisateur peut exécuter une mise à jour sur la liste des
utilisateurs soit :
- Ajouter un nouvel utilisateur.
- Modifier les informations de lui-même.
- Supprimer un utilisateur.

 Gestion des observations :

Cette fonctionnalité offre aux professeurs l’opportunité de consulter la fiche de présence
des élèves qui doit contenir leurs photos, leurs noms et leurs prénoms.
Elle permet de :
- Effectuer une mise à jour sur la liste des élèves.
- Gérer les statuts des élèves.

 Gestion des élèves et de leurs inscriptions:

Cette tâche permet aux agents administratifs de gérer la base de données des élèves ainsi
que les opérations d’inscription en insérant des informations relatives à eux. Aussi elle
permet de :
- Ajouter, modifier, supprimer un élève.
- Ajouter ou supprimer une inscription.

Page |5
Automatisation de la gestion du registre de classe au secondaire

 Gestion des billets :

Le surveillant avec cette fonctionnalité peut exécuter la tâche de :
- Donner aux élèves retardataires des billets de retard et à ceux qui se comporte hors
la loi interne d’établissement des billets d’entrée.

 Gestion des séances :

Le surveillant d’après cette tâche il se trouve face à une organisation planifiée de gestion
des heures de rattrapages ou des études:

 Gestion des classes :

Le surveillant est d’après la liste des classes ajoutée à la scolarité la gestion des nouvelles
classes et leurs niveaux, spécialités attaché à son numéro.

 Gestion des matières :

Cette tâche permet aux surveillants de gérer les matières :
- Ajouter, modifier, supprimer une matière.

 Gestion des salles :

Cette fonctionnalité permet aux surveillants de gérer les salles :
- Ajouter, modifier, supprimer une salle.

1.1.2 Objectifs à atteindre

Les principaux objectifs communs de tous les modules concernant le logiciel « Automatisation de
la gestion du registre de classe au secondaire » sont :

- Faciliter à l’administration et aux professeurs de mémoriser les portraits de tous les élèves
rapidement et prendre une décision adéquate pour chacun selon son comportement.
- Eviter au responsable de classe d’assumer la responsabilité du registre.
- Se procurer plusieurs détails d’une manière rapide et efficace.
- Sécuriser les informations sur les élèves.

1.2 Repérage du domaine

Le repérage du domaine consiste à délimiter le champ d’étude et à définir ses frontières avec
l’environnement en montrant ses acteurs externes (métiers) et éventuellement le domaine d’étude
sous forme d'un diagramme de collaboration métier.

Page |6
Automatisation de la gestion du registre de classe au secondaire

 Notre domaine d’étude intitulé, gestion du registre de classes est en interaction avec les
acteurs métier de notre système sont :
- Parent
- Elève
- Elève responsable
- Surveillant général
- Service de scolarité

La figure 1.1 ci-après montre le domaine d’étude et ses échanges avec l’environnement :

Figure 1.1 : Diagramme de collaboration contexte métier

1.3 Description des processus métier

Les travailleurs du domaine sont tous des surveillants.

Page |7
Automatisation de la gestion du registre de classe au secondaire

Figure 1.2 : Diagramme de classes des travailleurs

Il est indispensable que le surveillant soi prêt du contact direct des élèves. Sa tâche manuelle de
gestion des élèves lui exige une confrontation directe afin de:

- Préparer les papiers d’entrée des élèves qui avaient des sujets d’avertissements ;
- Contrôler chaque registre restauré et prendre note des avertissements nécessaires qui ont
été adressés à chaque élève.

Figure 1.3 : Diagramme de cas d’utilisation métier

La figure 1.3 ci-dessus montre les différents processus métier du domaine.

Page |8
Automatisation de la gestion du registre de classe au secondaire

 Les processus métier :

Dans ce qui suit, nous décrivons chacun des processus représentés dans la figure 1.3

Les processus métier Description des processus métier

Au début de chaque séance d’étude, le responsable de classe doit

livrer à son professeur le registre des présences afin de noter la
présence, l’absence ou le retard des élèves. A la fin des séances
d’études il le dépose dans le bureau des présences et notifications
des élèves. La responsabilité de ce registre est toujours à la charge
de cet élève. Dans le cas de disparition de ce registre, l’élève
responsable doit le récupérer afin d’éviter une punition.
Livrer et contrôler le
Si non, le surveillant doit remplir une fiche de proposition d’une
registre
punition qu’il transfère au surveillant général. Cette fiche contient
l’origine de la faute commise et la nature de la punition (voir figure
1.4).

Grâce à cette procédure, le contrôle du registre permet d’assembler

les informations des retards et des absences des élèves et de les
partagent entre les professeurs, le responsable et le domaine de
l’étude.

Page |9
Automatisation de la gestion du registre de classe au secondaire

L’élève qui vient en retard doit contacter le surveillant du bureau

des présences et notifications des élèves pour prendre un billet de
retard.

L’élève qui est exclus lors d’une séance doit être accompagné par
Gérer les retardataires
le responsable de la classe au surveillant qui lui donne un billet
et les absents
d’entrée pour la séance prochaine.

Un parent doit se présenter à l’administration dans le cas d’une

demande d’un tuteur pour avoir le billet d’entrée (voir figure 1.5).

Cette procédure permet de gérer les retards et les absences des

élèves et de les avertir et même d’inviter leurs tuteurs.

Au début de chaque année scolaire, le service de scolarité envoi aux

Inscrire un élève surveillants la liste des nouveaux élèves potentiels afin de valider
leurs inscriptions dans leurs classes. Une fois le processus est
validé, l’élève reçoit du surveillant un emploi de temps de sa classe
avec le reçu d’inscription (voir figure 1.6).

Dans le cas où l’élève reçoit un avertissement, le surveillant général

Gérer les informations
doit informer le surveillant pour prendre note dans la fiche de
d’avertissement
l’élève averti (voir figure 1.7).

Page |10
Automatisation de la gestion du registre de classe au secondaire

Figure 1.4 : Diagramme d’activité « Livrer et contrôler registre »

Page |11
Automatisation de la gestion du registre de classe au secondaire

Figure 1.5 : Diagramme d’activité « Gérer les retardataires et les absents»

Figure 1.6 : Diagramme d’activité « Inscrire un élève »

Page |12
Automatisation de la gestion du registre de classe au secondaire

Figure 1.7 : Diagramme d’activité « Gérer les informations d’avertissement »

1.4 Description des supports d’information

Notre domaine d’étude nécessite des supports d’information pour effectuer les opérations
nécessaires de sauvegarde des données. Ces supports sont :

Le registre des présences, l’emploi du temps, le reçu d’inscription, le billet d’entrée, le billet de
retard et la fiche de proposition.

Les figures 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 ci-après donnent des exemples de ces supports
d’information.

 Registre des présences

Chaque registre de présence contient :
- La date
- Les noms et prénoms des élèves sont numérotés dans l’ordre
- Les observations en cas de retard, d’entrée ou d’absence
- Des colonnes qui présente les heures du 8h jusqu’à 18h
- Des colonnes vides pour la spécification de matières étudiées à chaque horaire
- La signature de chaque professeur pour justifier sa présence
- Chaque colonne d’horaire est subdivisée sur trois colonnes déterminant
l’absence, le retard et l’entrée

Page |13
Automatisation de la gestion du registre de classe au secondaire

Figure 1.8 : Registre des présences

 Emploi du temps :
L’emploi du temps d’un élève doit indiquer :
- Le nom du lycée
- La classe
- L’année scolaire
- Les jours de la semaine
- Les heures d’études
- La matière attachée à chaque heure d’étude avec notification de numéro de
salle

Page |14
Automatisation de la gestion du registre de classe au secondaire

Figure 1.9 : Emploi du temps

 Reçu d’inscription :
Un reçu d’inscription contient :
- Le nom du lycée
- Le prénom de l’élève
- Le nom de l’élève
- La date et le lieu de naissance
- La classe de l’élève
- la signature du directeur

Page |15
Automatisation de la gestion du registre de classe au secondaire

Figure 1.10 : Reçu d’inscription

 Billet d’entrée :
Un billet d’entrée présente :
- Le nom et le prénom de l’élève
- La classe de l’élève
- Le jour de l’autorisation d’être accepté en entrée
- L’heure d’entrée
- La cause de l’absence
- Le caché du surveillant générale

Figure 1.11 : Billet d’entrée

Page |16
Automatisation de la gestion du registre de classe au secondaire

 Billet de retard :
Un billet de retard présente :
- Le nom et le prénom de l’élève
- La classe de l’élève
- Le jour qui permet de l’accéder à la séance d’étude
- L’heure d’entrée
- La cause de l’absence
- Le caché du surveillant générale

Figure 1.12 : Billet de retard

 Fiche de proposition d’une punition :

Une fiche de proposition contient :
- Le nom du lycée et le lieu
- L’année scolaire
- Le nom et le prénom de l’élève
- La classe
- La cause de punition
- La date de remplissage
- Le nom et prénom du professeur
- Le statut
- La signature
- L’avis de directeur

Page |17
Automatisation de la gestion du registre de classe au secondaire

Figure 1.13 : Proposition d’une punition

Le diagramme de classes de la figure 1.14 montre les dépendances entre les différents supports
d’information.

Page |18
Automatisation de la gestion du registre de classe au secondaire

Figure 1.14 : Diagramme de classe de support d’information du système métier

Conclusion
Après avoir analysé l’existant et présenté une description du modèle métier, nous allons définir
dans le chapitre suivant les besoins par la présentation des diagrammes nécessaires de la
spécification de ces besoins.

Page |19
 Chapitre 2 : Capture des besoins

Page |20
Introduction
La capture des besoins est l’une des phases les plus importantes dans le développement
logiciel, car elle doit spécifier les besoins des utilisateurs envers le logiciel à développer. Elle
nous permet de bien comprendre les fonctionnalités du futur système. Pour réaliser cette
étape, nous utilisons le langage de modélisation UML pour identifier le modèle de contexte du
système informatisé et pour présenter un recueil des besoins.

Dans ce chapitre, nous allons présenter pour le système informatisé :

- Les acteurs futurs

- Le modèle de contexte
- Le diagramme des cas d’utilisation
- La description textuelle des cas d’utilisation

2.1 Acteurs du système informatisé

Un Acteur est un élément qui interagit avec le système dans le but de satisfaire un besoin. Il
est considéré comme une personne, un logiciel ou un matériel. Il peut échanger de
l’information avec le système ; consulter ou modifier l’état du système.

Dans notre projet, nous pouvons distinguer les acteurs suivants :

 Surveillant :
Il a des tâches très importantes dans notre application tel que:
- Inscrire un élève,
- Gérer les séances d’études,
- Gérer les matières,
- Gérer les salles,
- Gérer classes et contrôler les observations qui sont adressées à chaque élève,
- Consulter les fiches des élèves et leurs historiques tout au long de leur
trimestre de scolarisation,
- Gérer les billets des élèves afin d’assumer une vie scolaire régulière et
- Modifier l’état d’un professeur ou d’un surveillant.

 Professeur :
Le professeur est un acteur principal dans notre application, il peut accéder à la liste
des élèves, soit pour la consulter ; pour élaborer la présence des élèves ou les exclus
effectués ; ou encore pour modifier ses informations.

Page |21
2.2 Modèle de contexte du système informatisé
Le contexte du système est représenté par un diagramme de contexte (DC) qui montre
les interactions entre le domaine de l’étude et ses échanges avec l’environnement (figure 2.1).

Figure 2.1 : Diagramme de collaboration du futur système

2.3 Identification des cas d’utilisation

Un cas d'utilisation est une unité cohérente représentant une fonctionnalité visible de
l'extérieur. Il réalise un service de bout en bout, avec un déclenchement, un déroulement et
une fin, pour l'acteur qui l'initie.

Un cas d'utilisation (UC) modélise donc un service rendu par le système, ainsi l’ensemble des
cas d’utilisation sert de base à la traçabilité d’un ensemble autonome de fonctionnalité
possédant une forte cohésion.

Dans les faits, un diagramme de cas d’utilisation montre les différentes possibilités
d'interaction entre le système et les acteurs.

Page |22
La figure 2.2 ci-dessous montre les relations fonctionnelles entre les acteurs internes et le
système étudié.

Page |23
 Figure 2.2 : Diagramme des cas d’utilisation

2.4 Description textuelle des cas d’utilisation

Les cas d’utilisations Description des cas d’utilisations

S’authentifier Identification :

Titre : S’authentifier

Acteurs : Tous les acteurs

Objectif : Ce UC permet de spécifier les droits d’accès des

acteurs.

Date de création : 24/02/2015

Date de mise à jour : 24/02/2015

Version : 1.1

Description des scénarios:

Pré condition : Néant

Post condition : La session de l’utilisateur s'ouvre.

Scénario nominal : S’authentifier

Le scénario se poursuit selon les étapes suivantes :

1. L’utilisateur doit accéder à l’interface de

l’authentification, saisir son nom d’utilisateur et son mot
de passe.
2. Le système vérifie la validité du nom d’utilisateur et du
mot de passe.
- Si l’une des informations saisies est invalide,
l’exception 1 est déclenchée.
- Si l’utilisateur est un surveillant, le système affiche
l’interface de menu surveillant, si l’utilisateur est un
professeur alors le système accède directement à la
liste des élèves conformément à son emploi du temps.

Exception 1 :

Page |24
 - Le système affiche le message : « Nom utilisateur/Mot
de passe invalide veuillez essayer de nouveau ».

Identification :
Gérer les observations
Titre : Gérer les observations

Acteurs : Professeur

Objectif : Ce UC permet au professeur de consulter la liste

des élèves et d’élaborer la présence.

Date de création : 24/02/2015

Date de mise à jour : 24/02/2015

Version : 1.1

Description des scénarios:

Pré condition : Le professeur est authentifié.

Post condition : La présence du jour est enregistrée.

Scénario nominal :

Scénario 1 : Enregistrer une absence, un retard ou un exclus

Ce cas d’utilisation débute lorsque le professeur demande

d’enregistrer les présences.

Il se poursuit selon les étapes suivantes :

1. Le système vérifie la conformité de l’emploi du temps de

la classe avec le temps actuel.
- Le système fournit automatiquement la liste des
élèves conformément à l’emploi du temps de la
classe.
-Une exception 2 est déclenchée en cas de non-
conformité de la date système avec l’emploi du
temps.
2. Le professeur sélectionne une observation pour l’élève
(absent, retard, exclus).
3. En cas de validation, le système enregistre les
modifications notées.

Scénarios alternatifs :

Page |25
 Scénario 2 : Modifier une absence, un retard ou un exclus

Ce cas d’utilisation débute lorsque le professeur demande de

modifier une observation.

Il se poursuit selon les étapes suivantes :

1. Le système vérifie la conformité de l’emploi du temps de

la classe avec le temps actuel en cas de s'authentifier.
- Le système fournit automatiquement la liste des
élèves conformément à l’emploi du temps de la
classe.
- Une exception 2 est déclenchée en cas de non-
conformité de la date système avec l’emploi du
temps.
2. Le professeur modifie l’observation de l’élève concerné
(absent, retard, exclus).
3. En cas de validation, le système enregistre les
modifications notées.

Scénario 3 : Supprimer une absence, un retard ou un exclus

Ce cas d’utilisation débute lorsque le professeur demande de

supprimer une observation.

Il se poursuit selon les étapes suivantes :

1. Le système vérifie la conformité de l’emploi du temps de

la classe avec le temps actuel en cas de s'authentifier.
- Le système fournit automatiquement la liste des
élèves conformément à l’emploi du temps de la
classe.
- Une exception 2 est déclenchée en cas de non-
conformité de la date système avec l’emploi du
temps.
2. Le professeur choisit l’élève concerné et supprime son
observation.
3. En cas de validation, le système enregistre la suppression
effectuée.

Exception 2 :

- Le système affiche le message : « Aucune séance en ce

moment ».

Page |26
 Gérer élèves Identification :

Titre : Gérer élève

Acteurs : Surveillant

Objectif : Ce UC permet de consulter la fiche de l’élève ;

ajouter, modifier ou supprimer un élève

potentiel.

Date de création : 24/02/2015

Date de mise à jour : 24/02/2015

Version : 1.1

Description des scénarios:

Pré condition : Le surveillant est authentifié.

Post conditions : La gestion des élèves est enregistrée.

Scénarios nominaux :

Scénario 1 : Consulter fiche élève

Ce cas d’utilisation débute lorsque le surveillant demande un

profil d’élève.

Le scénario se poursuit selon les étapes suivantes :

1. Le système affiche la liste des élèves inscrits.

2. Le professeur choisit un élève.
3. Le système affiche toutes les informations (photo,
matricule, nom, prénom, date naissance, nombre
d’absences, nombre de retards et le nombre d’exclus)
concernant l’élève.
- Si le surveillant veut affecter une punition à celui-ci,
alors il demande d’enregistrer une punition.
- Le système donne la main au surveillant pour
introduire la punition.
- Le surveillant remplit la proposition en précisant la
cause de cette punition et l’envoie au surveillant
général.
- Le système affiche « Envoi réalisé avec succès ».

Page |27
 Scénario 2 : Ajouter un élève potentiel

Ces cas d’utilisation débutent lorsque le surveillant demande un

profil d’élève potentiel.

Le scénario se poursuit selon les étapes suivantes :

1. Le surveillant saisit les informations de l’élève (photo,

matricule, nom, prénom, date naissance, ville, adresse,
classe) et valide l’ajout.
2. Le système vérifie l’existence de l’élève.
- Si l’élève existe déjà, l’exception 3 est lancée.
- Sinon le système enregistre l’élève en tant qu’un
élève potentiel.

Scénarios alternatifs :

Scénario 3 : Modifier un élève potentiel

1. Le système affiche la liste des élèves potentiels.

2. Le surveillant choisit un élève potentiel qui se trouve
dans la liste affichée.
3. Le système affiche toutes les informations liées à l’élève
sélectionné.
4. Le surveillant sélectionne le détail qu’il veut modifier,
effacer ou saisir de nouvelles informations. Puis, il valide
la saisie.
5. Le système vérifie que toutes les coordonnées
obligatoires sont saisies.
- S’il y’a une information manquante, l’exception 4
est lancée.
- Sinon le système enregistre les modifications
effectuées.

Scénario 4 : Supprimer un élève potentiel

1. Le système affiche la liste des élèves potentiels.

2. Le surveillant choisit un élève potentiel qui se trouve
dans la liste affichée.
3. Le système affiche toutes les informations liées à l’élève
sélectionné.
4. Le surveillant demande au système de supprimer l’élève.
5. Le système demande une confirmation de suppression.
- Si le surveillant valide la suppression alors le système
effectue la suppression avec un message déclenchant

Page |28
 « Elève supprimé avec succès».

Exception 3:

- Le système affiche le message : «Elève existe déjà »

Exception 4 :

- Le système affiche le message : «Champs obligatoire !»

Identification :

Titre : Gérer profil de classe

Acteurs : Surveillant

Objectif : Ce UC permet de contrôler les observations

prises adressées à chaque élève.

Date de création : 24/02/2015

Date de mise à jour : 24/02/2015

Version : 1.1

Description des scénarios:

Pré condition : Le surveillant est authentifié.

Gérer profil de classe
Post condition : Le surveillant consulte la liste des

présences.

Scénario nominal :

Scénario 1 : Consulter classe

Ce cas d’utilisation débute lorsque le surveillant demande un

profil de classe.

Le scénario se poursuit selon les étapes suivantes :

1. Le surveillant sélectionne une classe en précisant la

date et l’heure du suivi.
2. Le système affiche la liste des présences et notifie le
surveillant des élèves qui ont des punitions.

Page |29
 Gérer les classes Identification :

Titre : Gérer les classes

Acteurs : Surveillant

Objectif : Ce UC permet d’ajouter, modifier ou supprimer

une classe

Date de création : 24/02/2015

Date de mise à jour : 24/02/2015

Version : 1.1

Description des scénarios:

Pré condition : Le surveillant est authentifié.

Post condition : La gestion des classes est enregistrée.

Scénarios nominaux :

Ces cas d’utilisations débutent lorsque le surveillant demande un

profil d’emploi.

Scénario 1 : Ajouter une classe

Il se poursuit selon les étapes suivantes :

1. Le surveillant saisit le niveau, la spécialité et le numéro

de la classe et valide l’ajout.
2. Le système vérifie l’existence de la famille (ajoutée au
niveau de l’étape 1).
- Si la famille existe déjà, l’exception 5 est lancée.
- Sinon le système enregistre une nouvelle classe qui
porte les informations saisies.

Scénarios alternatifs :

Scénario 2 : Modifier une classe

1. Le système affiche au surveillant la liste des classes déjà

existantes afin de choisir une seule pour la modification.
2. Le surveillant sélectionne la classe à modifier.
3. Le système affiche les informations relatives à la
sélection.
4. Le surveillant saisit les cordonnées à modifier et valide la

Page |30
 modification.
5. Le système vérifie que toutes les coordonnées obligatoires
sont saisies.
- S’il y’a une information manquante, l’exception 6
est lancée.
- Sinon le système enregistre la modification.

Scénario 3 : Supprimer une classe

1. Le système affiche au surveillant la liste des classes déjà

existantes afin de choisir une seule pour la suppression.
2. Le surveillant choisit la classe à supprimer.
3. Le système supprime la classe sélectionnée.
4. Le système demande une confirmation de suppression.
- Si le surveillant valide la suppression alors le système
effectue la suppression avec un message déclenchant
« Classe supprimée avec succès».

Exception 5 :

- Le système affiche le message : «classe existe déjà »

Exception 6 :

- Le système affiche le message : «Champs obligatoire !»

Gérer les matières Identification :

Titre : Gérer les matières

Acteurs : Surveillant

Objectif : Ce UC permet d’ajouter, modifier ou supprimer

une matière

Date de création : 24/02/2015

Date de mise à jour : 24/02/2015

Version : 1.1

Description des scénarios:

Pré condition : Le surveillant est authentifié.

Post condition : La gestion des matières est enregistrée.

Ces cas d’utilisations débutent lorsque le surveillant demande le

Page |31
 profil des matières.

Scénario nominal :

Scénario 1 : Ajouter une matière

Il se poursuit selon les étapes suivantes :

1. Le surveillant saisit le libellé et valide l’ajout.

2. Le système vérifie l’existence de la matière.
- Si le libellé existe déjà, l’exception 7 est lancée.
- Sinon le système enregistre une nouvelle matière qui
porte le libellé saisi.
Scénarios alternatifs :

Scénario 2 : Modifier une matière

1. Le système affiche au surveillant la liste des classes déjà

existantes afin de choisir une seule à modifier.
2. Le surveillant sélectionne la matière à modifier.
3. Le système affiche le libellé de la matière
4. Le surveillant saisit le nouveau libellé et valide la
modification.
5. Le système vérifie que le libellé de la matière est rempli
- S’il est vide, l’exception 8 est lancée.
- Sinon le système enregistre la modification.

Scénario 3 : Supprimer une matière

1. Le système affiche au surveillant la liste des matières déjà

existant afin de choisir un seul à supprimer.
2. Le surveillant choisit la matière à supprimer.
3. Le système demande une confirmation de suppression.
- Si le surveillant valide la suppression alors le système
effectue la suppression avec un message déclenchant
« Matière supprimée avec succès».
- Sinon le système supprime la matière sélectionnée.

Exception 7 :

- Le système affiche le message : «Matière existe déjà »

Exception 8 :

- Le système affiche le message : «Champs obligatoire !»

Page |32
 Identification :

Titre : Gérer les salles

Acteurs : Surveillant

Objectif : Ce UC permet d’ajouter, modifier ou supprimer

une salle

Date de création : 25/02/2015

Date de mise à jour : 25/02/2015

Version : 1.1

Description des scénarios:

Pré condition : Le surveillant est authentifié.

Post condition : La gestion des salles est enregistrée.

Ces cas d’utilisations débutent lorsque le surveillant demande le

profil des salles.

Gérer les salles Scénarios nominaux :

Scénario 1 : Ajouter une salle

Il se poursuit selon les étapes suivantes :

1. Le surveillant saisit le libellé et valide l’ajout.

2. Le système vérifie l’existence du libellé.
- Si la salle existe déjà, l’exception 9 est lancée.
- Sinon le système enregistre une nouvelle salle qui
porte le libellé saisi.

Scénarios alternatifs :

Scénario 2 : Modifier une salle

1 Le système affiche au surveillant la liste des salles déjà

existantes afin de choisir une seule à modifier.
2 Le surveillant sélectionne la salle à modifier.
3 Le système affiche les informations relatives à la
sélection.
4 Le responsable saisit les cordonnées à modifier et valide
la modification.
5 Le système vérifie que toutes les coordonnées

Page |33
 obligatoires sont saisies.
- S’il y’a une information manquante, l’exception 10
est lancée.
- Sinon le système enregistre la modification.

Scénario 2 : Supprimer une salle

1. Le système affiche au surveillant la liste des salles déjà

existantes afin de choisir une seule à supprimer.
2. Le surveillant choisit la salle à supprimer.
3. Le système demande une confirmation de suppression.
- Si le surveillant valide la suppression alors le système
effectue la suppression avec un message déclenchant
« Salle supprimée avec succès».
- Sinon le système supprime la salle sélectionnée.

Exception 9 :

- Le système affiche le message : «salle existe déjà »

Exception 10 :

- Le système affiche le message : «Champs obligatoire !»

Page |34
 Identification :

Titre : Gérer les billets

Acteurs : Surveillant

Objectif : Ce UC permet d’affecter un billet à ceux qui se

comporte hors la loi de la vie scolaire.

Date de création : 25/02/2015

Date de mise à jour : 25/02/2015

Version : 1.1

Description des scénarios:

Pré condition : Le surveillant est authentifié.

Post condition : Billet imprimé

Gérer les billets
Scénario nominal :

Scénario 1 : Ajouter un billet

Ce cas d’utilisation débute lorsque le surveillant demande un

profil de billets.

Il se poursuit selon les étapes suivantes :

1. Le système affiche au surveillant la liste élèves déjà

existantes.
2. Le surveillant sélectionne l’élève et choisi la date relative
à l’observation afin de surveiller l’heure liée à
l’observation.
3. Le système affiche les observations de l’élève suivi à
l’heure de création.
4. Le surveillant précise le type de billet.
5. Le système imprime le billet.

Page |35
 Gérer les séances
d’enseignements ou les
Identification :
séances de rattrapages
Titre : Gérer les séances d’enseignements ou les séances de

rattrapages.

Acteurs : Surveillant

Objectif : Ce UC permet d’ajouter, modifier, supprimer ou

consulter une séance d’étude ou une séance de

rattrapage.

Date de création : 26/02/2015

Date de mise à jour : 26/02/2015

Version : 1.1

Description des scénarios:

Pré condition : Le surveillant est authentifié.

Post condition : Séance est ajoutée, modifiée, supprimée

ou consultée.

Ces cas d’utilisations débutent lorsque le surveillant demande de

gérer les emplois du temps des classes.

Scénario nominal :

Scénario 1 : Ajouter une séance d’enseignement ou une

séance de rattrapage

Le scénario se poursuit selon les étapes suivantes :

1. Le surveillant précise la classe recherchée, sélectionne le

détail qu’il veut remplir en précisant la date s’il s’agit
d’un ajout d’une séance de rattrapage.
2. Le système donne la main au surveillant afin d’ajouter
des séances.
3. Le surveillant saisit le nom du professeur, la matière ainsi
que la salle, le jour et l’heure. Il valide ensuite l’ajout.
4. Le système vérifie la disponibilité des données saisies.

Page |36
 11 est déclenchée.
- Si la salle n’est pas disponible alors l’exception 12
est déclenchée.
- Sinon le système enregistre la nouvelle séance.

Scénarios alternatifs :

Scénario 2 : Modifier une séance d’enseignement ou une

séance de rattrapage

1. Le surveillant précise la classe préférée, demande au

système de modifier les détails d’une séance.
2. Le système affiche les détails de la séance.
3. Le surveillant sélectionne le détail qu’il veut modifier,
saisit les nouvelles informations et valide la saisie.
4. Le système vérifie que toutes les coordonnées
obligatoires sont saisies.
- S’il y’a une information manquante, l’exception 13
est lancée.
- Sinon le système enregistre les modifications
effectuées.

Scénario 3 : Supprimer une séance d’enseignement ou une

séance de rattrapage

1. Le surveillant précise la classe préférée, sélectionne le

détail qui veut supprimer puis valide la suppression.
2. Le système affiche un message de confirmation « Etes
vous sûr de vouloir supprimer cette séance ! ».
- Si le surveillant confirme la suppression alors un message
déclenchant « Séance supprimée avec sucées » va être
affichée.

Scénario 5 : Consulter un emploi du temps

1. Le surveillant précise la classe préférée.

2. Le système affiche l’emploi demandé. Il peut alors
l’imprimer ou s’informer sur un professeur, une salle ou
une matière.

Exception 11 :

- Le système affiche le message : «Professeur non

disponible»

Page |37
 Exception 12 :

- Le système affiche le message : «Salle non disponible »

Exception 13 :

- Le système affiche le message : «Champs obligatoire ! »

Gérer Inscription

Identification :

Titre : Gérer profil d’inscription

Acteurs : Surveillant

Objectif : Ce UC permet d’effectuer les inscriptions des

élèves.

Date de création : 26/02/2015

Date de mise à jour : 26/02/2015

Version : 1.1

Description des scénarios:

Pré conditions : Une demande d’inscription.

Le surveillant est authentifié.

Post condition : Un élève supprimé.

Une inscription imprimée.

Ces cas d’utilisations débutent lorsque le surveillant reçoit la

demande d’inscription d’un élève ou une demande de
suppression.

Scénario nominal :

Le scénario se poursuit selon les étapes suivantes :

Scénario 1 : Ajouter une inscription

1. Le système affiche la liste des élèves potentiels.

Page |38
 2. Le surveillant sélectionne l’élève précis.
3. Le système affiche les renseignements nécessaires
attachés à l’élève.
4. Le surveillant saisit le reçu nécessaire et confirme
l'inscription.
5. Le système ajoute l’élève non inscrit et imprime son reçu
d’inscription. Sinon l’exception 14 est déclenchée.

Scénario alternatif :

Scénario 2 : Supprimer une inscription

1. Le système affiche les renseignements nécessaires attaché

à l’élève.
2. Le surveillant demande au système de supprimer une
inscription.
3. Le système affiche un message de confirmation « Vous
êtes sur le point de supprimer cette inscription».
- Si le surveillant valide la suppression alors le système
effectue la suppression avec un message déclenchant
« Inscription supprimée avec succès».

Exception 14 :

- Le système affiche le message : « l’élève est déjà inscrit».

Gérer les utilisateurs

Identification :

Titre : Gérer les utilisateurs

Acteurs : Surveillant

Professeur

Objectif : Ce UC permet d’ajouter, de modifier ou de

supprimer des utilisateurs.

Date de création : 26/02/2015

Date de mise à jour : 26/02/2015

Version : 1.1

Description des scénarios:

Page |39
 Pré conditions : Utilisateur est authentifié s’il s’agit d’une

modification ou suppression d’un acteur

sinon néant.

Post conditions : Inscription, modification ou suppression

d’un acteur

Scénario nominal :

Scénario 1 : Inscrire un surveillant ou un professeur

Ce cas d’utilisation débute lorsque l’acteur demande une

inscription.

Le scénario se poursuit selon les étapes suivantes :

1. Le surveillant donne l’autorisation d’accès aux

utilisateurs concernés en leurs fournissant toutes les
informations du serveur (numéro de la carte d’identité,
nom, prénom, date naissance, ville, nom utilisateur, mot
de passe et la spécialité s’il s’agit d’un professeur).
2. Dans le cas où toutes les informations du serveur sont
saisies correctement, le système affiche «Bienvenue, vous
avez inscrit à nos services ». Sinon, si l’utilisateur saisit
un nom d’utilisateur existe déjà dans notre serveur alors
une exception 15 est lancée.
Dans le cas où il existe une information manquante alors
l’exception 16 est déclenchée.

Scénarios alternatifs :

Ce cas d’utilisation débute lorsque l’acteur demande une

modification de son paramétrage.

Scénario 2 : Modifier un utilisateur

1. Le système affiche toutes les informations concernant

l’utilisateur en question.
2. L’utilisateur saisit de nouveau les informations à
modifier.
3. Le système vérifie les informations saisies.
4. Si les informations sont erronées alors une l’exception 17
est lancée sinon le système met à jour l’utilisateur.

Scénario 3 : Supprimer un utilisateur

Page |40
 1. Le surveillant saisit l’identifiant d’un surveillant ou d’un
professeur et valide la suppression.
1. Le système valide l’existence de l’identifiant concernés,
s’il n’existe pas alors l’exception 18 est déclenchée sinon
il mettre l’utilisateur à l’état bloqué.

Exception 15 :

- Le système affiche le message : « Nom utilisateur déjà

existe, voulez vous le modifié ! ».

Exception 16 :

- Le système affiche le message : « Champs obligatoire ».

Exception 17 :

- Le système affiche le message : «Informations erronée».

Exception 18 :

- Le système affiche le message : « utilisateur inexistant».

Conclusion
Au cours de ce chapitre nous avons présenté les différents acteurs de notre projet, ainsi que les
interactions entre eux et leurs rôles. Nous avons également définit les conditions d’utilisations
du système informatisé. Ceci nous permettra de présenter dans le chapitre suivant les
diagrammes de séquences et le diagramme de classes de l’application.

Page |41
 Chapitre 3 : Analyse

Page |42
Introduction
A ce stade d'études, nous franchissons la frontière qui sépare le monde fonctionnel du monde
objet, afin de commencer une analyse qui nous permet d'identifier les objets du système.

L’analyse est une étape très importante durant l’implémentation d’un système informatisé.

Elle consiste principalement à élaborer un modèle des classes du domaine qui permet d’opérer
une transition vers une véritable modélisation objet et d’illustrer la dynamique du système en
formalisant les scénarii de ses cas d’utilisation.

3.1 Réalisation des cas d’utilisation

Les diagrammes de séquence présentent la coopération entre les différents objets selon un
point de vue temporel. Ces diagrammes sont plus aptes à modéliser les aspects dynamiques de
scénarios de cas d’utilisation complexes.

Cas d’utilisation « S’authentifier »

La figure 3.1 ci-dessous montre l’intégration des données des utilisateurs.

Page |43
 Figure 3.1 : Diagramme de séquence « S’authentifier »

Figure 3.2 : Diagramme de classes issu du UC « S’authentifier »

Cas d’utilisation « Gérer les utilisateurs »

Page |44
Les figures 3.3, 3.4, 3.5 et 3.6 ci-après donnent aux utilisateurs leurs droits d’accès.

Figure 3.3 : Diagramme de séquence « Inscrire un surveillant ou un professeur »

Page |45
 Figure 3.4 : Diagramme de séquence « Modifier un professeur »

Figure 3.5 : Diagramme de séquence « Supprimer un surveillant ou un professeur»

Figure 3.6 : Diagramme de séquence « Modifier un surveillant »

Page |46
 Figure 3.7 : Diagramme de classes issu du UC « Gérer les utilisateurs »

Cas d’utilisation « Gérer les observations »

Les figures 3.8, 3.9 et 3.10 ci-dessous permet la mise à jour des différentes observations marquées par
le professeur.

Page |47
Figure 3.8 : Diagramme de séquence « Enregistrer une absence, un retard ou un exclus »

Page |48
 Figure 3.9 : Diagramme de séquence « Modifier une absence, un retard ou un exclus »

Page |49
 Figure 3.10 : Diagramme de séquence « Supprimer une absence, un retard ou un exclus »

Remarque : Si le paramètre seuil dépasse quatre retards ou deux exclus alors une punition
d’avertissement est déclenchée. Si le seuil atteint trois jours d’absence, alors une punition doit être
remplie.

Page |50
 Figure 3.11 : Diagramme de classes issu du UC « Gérer les observations »

Page |51
 Cas d’utilisation « Gérer élèves »
La figure 3.12 ci-dessous montre certaines tâches de surveillance.

Figure 3.12 : Diagramme de séquence « Consulter fiche élève »

Page |52
Les figures 3.13, 3.14 et 3.15 ci après facilitent la mise à jour des élèves.

Figure 3.13 : Diagramme de séquence « Ajouter un élève potentiel »

Figure 3.14 : Diagramme de séquence « Modifier un élève potentiel »

Page |53
 Figure 3.15 : Diagramme de séquence « Supprimer un élève potentiel »

Figure 3.16 : Diagramme de classes issu de l’UC «Gérer élève »

Page |54
 Cas d’utilisation « Gérer profil de classe »

Figure 3.17 : Diagramme de séquence « Consulter classe »

La figure 3.17 ci-dessus montre les mouvements des élèves en une classe.

Page |55
 Figure 3.18 : Diagramme de classes issu du UC «Gérer profil de classe »

Cas d’utilisation « Gérer profil d’inscription »

La figure 3.19 et 3.20 expliquent les opérations d’inscriptions.

Page |56
 Figure 3.19 : Diagramme de séquence « Ajouter une inscription »

Figure 3.20 : Diagramme de séquence « Supprimer une inscription »

Page |57
 Figure 3.21 : Diagramme de classes issu du UC «Gérer profil d’inscription »

Cas d’utilisation « Gérer les billets »

La figure 3.22 ci-dessous montre la démarche de la vie scolaire.

Page |58
 Figure 3.22 : Diagramme de séquence « Ajouter un billet »

Figure 3.23 : Diagramme de classes issu du UC «Gérer les billets »

 Cas d’utilisation «Gérer les séances d’enseignements et les séances de rattrapage»

Figure 3.24 : Diagramme de séquence « Ajouter une séance d’enseignement ou une séance de
rattrapage »

Page |59
 Figure 3.25 : Diagramme de séquence « Modifier une séance d’enseignement ou une
séance de rattrapage »

Page |60
 Figure 3.26 : Diagramme de séquence « Supprimer une séance d’enseignement ou une
séance de rattrapage »

Page |61
Les figures 3.24, 3.25 et 3.26 ci-dessus montrent une organisation planifiée de gestion des heures de
rattrapages ou des études.

Figure 3.27 : Diagramme de classes issu du UC «Gérer les séances d’enseignement et

les séances de rattrapage »

Page |62
  Cas d’utilisation «Gérer les classes»

Figure 3.28 : Diagramme de séquence « Ajouter une classe »

Figure 3.29 : Diagramme de séquence « Modifier une classe »

Page |63
 Figure 3.30 : Diagramme de séquence « Supprimer une classe »

La figure 3.28, 3.29 et 3.30 ci-dessus offrent aux utilisateurs une bonne gestion des classes.

Figure 3.31 : Diagramme de classes issu du UC «Gérer les classes»

Page |64
  Cas d’utilisation «Gérer les matières»
La figure 3.32, 3.33 et 3.34 ci-dessous montrent la mise à jour des matières.

Figure 3.32 : Diagramme de séquence « Ajouter une matière»

Figure 3.33 : Diagramme de séquence « Modifier une matière »

Page |65
 Figure 3.34 : Diagramme de séquence « Supprimer une matière»

Figure 3.35 : Diagramme de classes issu du UC «Gérer les matières»

Page |66
  Cas d’utilisation «Gérer les salles»
La figure 3.36, 3.37 et 3.38 ci-dessous offrent aux utilisateurs une bonne gestion des salles.

Figure 3.36 : Diagramme de séquence « Ajouter une salle»

Figure 3.37 : Diagramme de séquence « Modifier une salle»

Page |67
 Figure 3.38 : Diagramme de séquence « Supprimer une salle»

Figure 3.39 : Diagramme de classes issu du UC «Gérer les salles»

Page |68
3.2 Construction du modèle du domaine
L’intérêt de cette section est de représenter un diagramme de classes qui modélise les entités du
système d’information, représente les informations finalisées qui sont gérées par le domaine en
exprimant la structure statique du système en termes de classes et de relations entre ces classes. Ce
diagramme de classes (figure 3.40) est obtenu pour fusionner de tous les diagrammes de classes issus
des différentes UC.

Figure 3.40 : Diagramme de classes du domaine

Page |69
Conclusion
Dans ce chapitre, nous avons clôturé la phase d’analyse en utilisant l'approche UML. D'abord,
nous avons essayé de donner une vision claire et rigoureuse du système à réaliser en
déterminant ses éléments et leurs interactions.

Dans le chapitre suivant, nous présenterons les technologies de programmation utilisées dans
l'implémentation et nous décrirons la phase de conception de la solution que nous proposants
pour réaliser les modèles d’analyse.

Page |70
 Chapitre 4 : Conception

Page |71
Introduction
Dans ce chapitre nous décrivons les différentes technologies adoptées et utilisées pour la
réalisation de ce projet.

Pour cela, nous commençons par une étude des environnements du travail, ainsi que les outils
de développement utilisés. Ensuite nous présentons l’architecture de notre application, puis
nous donnons un aperçu sur les différentes parties développées du travail que nous avons
accompli tout au long de la période de notre projet.

4.1 Environnement de réalisation

C’est la phase de réalisation qui nous met en contact réel avec l’environnement de
développement. Nous consacrerons la première partie à la présentation du contexte logiciel et
matériel de développement

4.1.1 Environnement matériel

Pour concrétiser notre application, nous avons utilisé un pc ayant les caractéristiques suivantes :

Caractéristique Type
Marque SAMSUNG

Processeur Intel® CoreTM i5

Fréquence 2.50 GHz

Mémoire centrale 4GO

Système d’exploitation Windows 7

Figure 4.1 : Caractéristique du pc utilisé

4.1.2 Environnement logiciel

Le choix de l’environnement logiciel constitue un grand défi pour le développeur car il

influence directement les facteurs temps et coût. Pour cela, il représente une étape critique et
importante.

Page |72
Les outils logiciels que nous avons utilisés pour notre application sont :

 OUTILS DE DÉVELOPPEMENT :

SGBD : SQL Server est un serveur de bases de données développé dans un

souci de performances élevées en lecture, ce qui signifie qu'il est d’avantage orienté vers le
service de données déjà en place que vers celui de mises à jour fréquentes et fortement
sécurisées.

Eclipse avec ADT (Android Developper Tools) : Eclipse est l’Environnement de

Développement Intégré (IDE) le plus largement utilisé pour la programmation Java, très
performant, de plus il est gratuit et open source. Le langage privilégié pour le développement
d’applications Android est justement Java. Google a donc tout naturellement conçu un plugin
pour Eclipse (un plugin est un module qui complète un logiciel hôte pour lui apporter des
nouvelles fonctionnalités).

Android Developper Tools, ou ADT, est très complet et surtout très pratique : conception
graphique d’interfaces utilisateur, debug distant sur un téléphone.

Visual Studio 2010 avec DevExpress : Visual Studio est un ensemble

complet d'outils de développement permettant de générer des applications Web
ASP.NET, des Services Web (XML, JSON), des applications bureautiques et des applications
mobiles. Visual Basic, Visual C++, Visual C# utilisent tous le même environnement de
développement intégré (IDE, Integrated Development Environment), qui leur permet de
partager des outils et facilite la création de solutions faisant appel à plusieurs langages.

Mais la qualité des IDE Visual Studio n'est plus à prouver, très complet alors le DevExpress
est l’outil qui offre ces compléments, il offre énormément de super composants pour la
couche présentation, des grid hiérarchiques exportables sous Excel, Xml, Pdf, un éditeur
d'état imprimable très puissant…

Microsoft Word 2007 : Outil d'édition et de traitement de textes et tous autres documents qui
nous ont utilisées dans la rédaction du cahier de spécification fonctionnelle pour notre
application.

Android : Android est un système d'exploitation open source utilisant le noyau Linux, pour
smartphones, tablettes tactiles et terminaux mobiles conçu par Android, une startup
rachetée par Google. Celui-ci met à disposition un kit de développement (SDK) basé
sur le langage Java.

Page |73
Bugdroid, le petit robot vert qui sert de logo à Android, et qui est sous License Créative
Commons, permettant modifications en toute légalité.

XML : Le langage XML est extensible, c'est-à-dire qu’il peut décrire n’importe quel domaine
des données. Il est facilement transporté par n’importe quel protocole de même qu’il
peut être facilement intégré dans n’importe quelle plateforme.

 Les services web :

L'utilisation des services web dans notre solution mobile était indispensable pour garantir
l'échange des données entre le serveur et l'appareil téléphonique en toute sécurité et fiabilité.

Il faut bien comprendre les notions qui entourent un service web. Il existe trois types de
service web : RPC, SOAP et REST.

RPC et SOAP sont des architectures de services web complexes, souvent trouvées dans le
monde professionnel sur de gros systèmes d'informations. Généralement, ils sont
accompagnés du langage de description WSDL qui permet de proposer une annuaire des
services du serveur.

Très compliqué à mettre en œuvre, ces architectures ont rebutés longtemps les développeurs
en herbe, c'est pourquoi les fournisseurs de web services ont créé une architecture simplifiée
pour favoriser l’accès aux développeurs à leurs bouquets d'API, il s'agit de l'architecture
REST.

REST (REpresentational State Transfer) est un type d'architecture que l'on utilise de plus en
plus pour réaliser un service web. Il n'est pas définit précisément par un standard. REST est
basé sur des requêtes transmises par des protocoles standards (http, ftp, ...), il renvoi un fichier
souvent au format XML ou JSON.

Un service REST permet de traiter des ressources distantes, pour cela il définit 4 fonctions
dites de bases :

 GET : pour lire la ressource,

 PUT : pour modifier la ressource,
 DELETE : pour supprimer la ressource,
 POST : pour écrire la ressource.

Les formats d'échange sont le XML ou le JSON. On parle aussi de sérialisation des données.
J'ai retenu le format JSON qui est très employé dans les API.

JSON (JavaScript Object Notation) est un format de structuration des données. Les données
sont considérées comme des objets avec des propriétés et sous-propriétés. Ce formalisme est
assez proche de XML et est basé sur le langage JavaScript.

Page |74
4.2 Architecture du futur système

Figure 4.2 : Architecture logique de l’application

Page |75
4.3 Conception des schémas logiques et physique des données

Figure 4.3 : Schéma physique de la base de données

Page |76
4.4 Réalisation des cas d’utilisation
4.4.1 Conception des interactions

Cas d’utilisation « S’authentifier »

Figure 4.4 : Diagramme de séquence de conception de scénario nominal « S’authentifier » du

UC « S’authentifier »

Page |77
 Cas d’utilisation « Gérer les utilisateurs »

Figure 4.5 : Diagramme de séquence de conception de scénario nominal « Inscrire un

surveillant ou un professeur » du UC « Gérer les utilisateurs »

Page |78
 Cas d’utilisation « Gérer les observations »

Figure 4.6 : Diagramme de séquence de conception de scénario nominal « Enregistrer

une absence, un retard ou un exclus» du UC « Gérer les observations »

Page |79
  Cas d’utilisation « Gérer élèves »

Figure 4.7 : Diagramme de séquence de conception de scénario nominal « Consulter

fiche élève» du UC « Gérer les élèves »

Page |80
 Figure 4.8 : Diagramme de séquence de conception de scénario nominal « Ajouter un
élève» du UC « Gérer les élèves »

Cas d’utilisation « Gérer profil de classe »

Figure 4.9 : Diagramme de séquence de conception de scénario nominal « Consulter

classe » du UC « Gérer profil de classe »

Page |81
 Cas d’utilisation « Gérer profil d’inscription »

Figure 4.10 : Diagramme de séquence de conception de scénario nominal « Ajouter une

inscription» du UC « Gérer profil d’inscription »

Page |82
 Cas d’utilisation « Gérer les billets »

Figure 4.11 : Diagramme de séquence de conception de scénario nominal « Ajouter un

billet» du UC « Gérer les billets »

Page |83
  Cas d’utilisation «Gérer les séances d’enseignements et les séances de rattrapage»

Figure 4.12 : Diagramme de séquence de conception de scénario nominal « Ajouter une

séance d’enseignement ou une séance de rattrapage » du UC « Gérer les séances
d’enseignements et les séances de rattrapage »

Page |84
  Cas d’utilisation «Gérer les classes»

Figure 4.13 : Diagramme de séquence de conception de scénario nominal « Ajouter une

classe » du UC « Gérer les classes »

 Cas d’utilisation «Gérer les matières»

Figure 4.14 : Diagramme de séquence de conception de scénario nominal « Ajouter une

matière » du UC « Gérer les matières »

Page |85
  Cas d’utilisation «Gérer les salles»

Figure 4.15 : Diagramme de séquence de conception de scénario nominal « Ajouter une

salle » du UC « Gérer les salles »

4.1.2 Construction des diagrammes d’états

Les diagrammes d'états-transitions décrivent le comportement interne d'un objet à l'aide d'un
automate à états finis. Ils présentent les séquences possibles d'états et d'actions qu'une
instance de classe peut traiter au cours de son cycle de vie en réaction à des événements
discrets.

Ce diagramme montre l’évolution d’une instance élève par rapport à l’axe de l’inscription et
l’axe de l’assiduité (absence, retard et exclusion).

Page |86
 Figure 4.16 : Diagramme d’états-transitions de l’entité "Elève"

Ce diagramme montre l’évolution d’une instance séance

Figure 4.17 : Diagramme d’états-transitions de l’entité "Séance"

Page |87
 4.1.3 Conception des classes

Figure 4.18 : Diagramme de classes de conception issu du UC «S’authentifier »

Figure 4.19 : Diagramme de classes de conception issu du UC «Gérer les utilisateurs »

Page |88
Figure 4.20 : Diagramme de classes de conception issu du UC «Gérer les observations »

Page |89
 Figure 4.21 : Diagramme de classes de conception issu du UC «Gérer les élèves »

Page |90
 Figure 4.22 : Diagramme de classes de conception issu du UC «Gérer profil de classe»

Figure 4.23 : Diagramme de classes de conception issu du UC «Gérer profil d’inscription»

Page |91
 Figure 4.24 : Diagramme de classes de conception issu du UC «Gérer les billets»

Figure 4.25 : Diagramme de classes de conception issu du UC «Gérer les séances

d’enseignements et les séances de rattrapages»

Page |92
 Figure 4.26 : Diagramme de classes de conception issu du UC «Gérer les classes »

Figure 4.27 : Diagramme de classes de conception issu du UC «Gérer les matières »

Page |93
 Figure 4.28 : Diagramme de classes de conception issu du UC «Gérer les salles »

4.1.4 Conception des opérations complexes

Figure 4.29 : Diagramme d’activités de l’opération « Ajouter une séance d’enseignement » de

l’entité "Séance Enseignement"

Conclusion
Nous avons commencé ce chapitre par fixer l’environnement matériel et logiciel choisi pour le
développement de notre application et les technologies mises en œuvre. Puis, nous avons proposé une
conception des scénarios de cas d’utilisation, des classes de l’application et nous avons décrit à l’aide
de diagramme d’états transitions le comportement des objets dont le cycle de vie n’est pas trivial.

Page |94
 Conclusion Générale

Page |95
Dans ce projet, nous avons développé une application de gestion de scolarité qui pourrait faciliter
certaines tâches administratives au sein des lycées.

Dans le premier chapitre de ce travail, nous avons présenté une description du modèle métier ainsi que
les différentes orientations visées. Le second chapitre, permet de présenté les différents acteurs de
notre projet, ainsi que les interactions entre eux. Ceci nous a permis de passer à la phase d’analyse
dans le chapitre 3. Le dernier chapitre constitue notre principale apport dans ce projet, il s’intéresse en
effet à la spécification de l’environnement matériel et logiciel ainsi que la présentation des
technologies utilisés.

Ce projet de fin d’étude nous a permis d’approfondir nos connaissances théoriques, acquises tous le
long de notre formation, par la pratique des nouvelles technologies. Cette expérience nous a permis de
maîtriser le langage de modélisation UML, les outils de développement Android à savoir le SDK
Android, sous lequel, le développement n’a pas été une tâche facile, mais nous n’avons pas hésité à y
participer. Le développement sous Visual Studio 2010 et l’outil DevExpress (DX) fait également
partie de notre apport pratique.

Notre travail nous a également permis de découvrir comment intégrer une application sur un serveur
web distant et comment utiliser un format JSON pour gérer la communication des données entre deux
environnements hétérogènes qui sont le client Android et le serveur de bases de données SQL Server.

Le stage quotidien au sein du lycée Tawfik a aussi été pour nous une occasion unique pour épanouir
nos capacités de communication dans un environnement professionnel. C’est une expérience très
enrichissante sur tous les domaines. Des imprimes écrans qui expliquent le fonctionnement de notre
application sont présentés dans un fichier Word séparé de notre projet.

Bien que les principaux objectifs de notre projet soient atteints, l’application que nous avons
développée pourrait être enrichie par d’autres améliorations et fonctionnalités avancées pouvant la
rendre plus interactive et plus pratique.

Page |96
 Bibliographie

Page |97
http://laurent-piechocki.developpez.com/uml/tutoriel/lp/cours/#LII-C-4

http://loopj.com/android-async-http

http://fr.wikipedia.org/wiki/UML_(informatique)

https://blograchita.wordpress.com/2012/10/24/using-putextra-and-getextras-in-android/

Page |98