Vous êtes sur la page 1sur 117

N° d’ordre ……….

MEMOIRE DE FIN D’ETUDES


En vue de l’obtention de
LICENCE FONDAMENTALE

Délivrée par :
Faculté des Sciences et Techniques de Sidi Bouzid
Discipline : Sciences Informatiques

Application mobile Android pour la gestion


administrative de l’école primaire

Présenté et soutenu par :

Saibi Abdelbaki & Sahraoui sahar


Soutenu le 00 MOIS 2020

Jury 

Président : M.
Rapporteurs : M.
Encadrant : M. ASHREF HENI

Encadrant : M.

ANNÉE UNIVERSITAIRE : 2019 - 2020


Dédicace
Dédicace
REMERCIEMENTS
Table de matière 
Table des figures :................................................................................................................................................................7

Introduction générale...........................................................................................................................................................1

Chapitre I..............................................................................................................................................................................2

Introduction......................................................................................................................................................................3

Etude fonctionnelle..........................................................................................................................................................3

1. Présentation du projet.........................................................................................................................................3

2. Présentation de l’organisme d’accueil :...............................................................................................................3

A. Description.....................................................................................................................................................3

B. Organigramme................................................................................................................................................4

3. Problématique......................................................................................................................................................4

4. Cahier des charges................................................................................................................................................4

A. Les besoins fonctionnels.................................................................................................................................5

 Les besoins fonctionnels pour l’élève :......................................................................................................5

 Les besoins fonctionnels pour l’enseignant :.............................................................................................5

 Les besoins fonctionnels pour l’administrateur :.......................................................................................6

B. Les besoins non fonctionnels :.......................................................................................................................6

5. Etude de l’existant................................................................................................................................................7

A. Présentation et analyse de l’existant.............................................................................................................7

B. Critique de l’existant......................................................................................................................................8

6. Objectifs à atteindre :...........................................................................................................................................9

7. Solution proposée :..............................................................................................................................................9

8. Planning de réalisation.........................................................................................................................................9

Spécification :.................................................................................................................................................................10

1. Identification des cas d’utilisation :....................................................................................................................10

2. Présentation des acteurs :..................................................................................................................................10

3. Classification des cas d’utilisations par acteur :.................................................................................................10

 Administrateur :.......................................................................................................................................10
 Enseignant :..............................................................................................................................................11

 Parent (élève) :.........................................................................................................................................11

4. Diagrammes des cas d’utilisation :.....................................................................................................................11

5. Relations entre les cas d’utilisation :..................................................................................................................14

A. La relation d’inclusion :................................................................................................................................15

B. Relation d’extension :...................................................................................................................................15

C. Relation de généralisation :..........................................................................................................................15

Chapitre II...........................................................................................................................................................................16

Introduction....................................................................................................................................................................17

I. Choix de la méthode de conception :.....................................................................................................................17

II. Description des scénarios et des diagrammes de séquence..................................................................................17

1. Administrateur :.................................................................................................................................................18

2. Enseignant :........................................................................................................................................................34

3. Parent :...............................................................................................................................................................47

4. Parent(élève) :....................................................................................................................................................51

Développement de modèle statique..............................................................................................................................56

1. Le dictionnaire de données................................................................................................................................56

2. Représentation des classes :..............................................................................................................................57

3. Diagramme de classe..........................................................................................................................................60

La base de données........................................................................................................................................................61

1. Modèle logique des données.............................................................................................................................61

 Définition de MLD....................................................................................................................................61

 Règles de transformations.......................................................................................................................62

2. Modèle logique de données...............................................................................................................................62

Conclusion..........................................................................................................................................................................63

Chapitre III..........................................................................................................................................................................64

I. Introduction :..........................................................................................................................................................65

II. Environnement de travail :.....................................................................................................................................65

1. Environnement matériel :..................................................................................................................................65
2. Environnement logiciel :.....................................................................................................................................66

 Android Studio :.......................................................................................................................................66

 StarUml :..................................................................................................................................................66

 Xampp :....................................................................................................................................................67

III. Choix techniques :..............................................................................................................................................68

IV. Test et validation :..............................................................................................................................................69

V. Interface de notre application :..............................................................................................................................69

1. Authentification d’un élève :..............................................................................................................................72

2. Espace administrateur :......................................................................................................................................73

VI. Conclusion :........................................................................................................................................................76

Conclusion général.........................................................................................................................................................77

Bibliographie...................................................................................................................................................................78

Netographie....................................................................................................................................................................79

Annexe A.........................................................................................................................................................................80
Table des figures :
Figure 1 : Idée du projet.......................................................................................................................................................3

Figure 2 : organigramme......................................................................................................................................................4

Figure 3: Solution "EducaPhone".........................................................................................................................................8

Figure 4 : Solution "Madrassati"...........................................................................................................................................8

Figure 5 : Planning de réalisation.........................................................................................................................................9

Figure 6: diagramme cas d’utilisation parent (élève).........................................................................................................12

Figure 7 : diagramme cas d’utilisation (enseignant)..........................................................................................................13

Figure 8 : diagramme cas d’utilisation (administrateur)....................................................................................................14

Figure 9 : relation inclusion................................................................................................................................................15

Figure10 : relation généralisation......................................................................................................................................15

Figure 11 : Logo UML..........................................................................................................................................................17

Figure 12 : diagramme de séquences du cas d’utilisation « S’authentifier »....................................................................19

Figure 13 : diagramme de séquences du cas d’utilisation « gérer les élèves » (Ajouter un élève)...................................20

Figure 14 : diagramme de séquences du cas d’utilisation « gérer les élèves » (Modifier un élève).................................22

Figure 15 : diagramme de séquences du cas d’utilisation « gérer les élèves » (Supprimer un élève)..............................24

Figure 16 : diagramme de séquences du cas d’utilisation « gérer les enseignants » (Modifier un enseignant)...............26

Figure 17 : diagramme de séquences du cas d’utilisation « gérer les enseignants » (Ajouter un enseignant).................28

Figure 18 : diagramme de séquences du cas d’utilisation « gérer les enseignants » (Supprimer un enseignant)............30

Figure 19 : diagramme de séquences du cas d’utilisation « Planifier rendez-vous »........................................................31

Figure 20 : diagramme de séquences du cas d’utilisation « Consacrer un volet pour les avis ».......................................32

Figure 21 : diagramme de séquences du cas d’utilisation « Déposer notes des examens ».............................................34

Figure 22: diagramme de séquences du cas d’utilisation « S’authentifier » : enseignant.................................................36

Figure 23 : diagramme de séquences du cas d’utilisation « Explorer fiche de renseignement »......................................38

Figure 24: diagramme de séquences du cas d’utilisation « Exposer éléments d’enseignement »...................................40

Figure 25 : diagramme de séquences du cas d’utilisation « Exposer éléments de renseignements »..............................43

Figure 26 : diagramme de séquences du cas d’utilisation « Fixer date des examens »....................................................44

Figure 27 : diagramme de séquences du cas d’utilisation « prendre rendez-vous avec parent ».....................................46

Figure 28 : diagramme de séquences du cas d’utilisation « Consulter éléments de renseignement »............................48


Figure 29 : diagramme de séquences du cas d’utilisation « prendre rendez-vous avec un enseignant »........................50

Figure 30 : diagramme de séquences du cas d’utilisation « Consulter les cours et les activités »....................................52

Figure 31: diagramme de séquences du cas d’utilisation« Consulter plan d’étude ».......................................................54

Figure 32 : diagramme de séquences du cas d’utilisation « Consulter plan du cours personnalisé »..............................56

Figure 33 : diagramme des classes.....................................................................................................................................61

Figure 34  : Information sur système.................................................................................................................................65

Figure 35 : Interface Android Studio..................................................................................................................................66

Figure 36 : Interface StarUml.............................................................................................................................................67

Figure 37 : Lugo xampp......................................................................................................................................................67

Figure 39 : Lugo XML..........................................................................................................................................................68

Figure 39 : Lugo JAVA.........................................................................................................................................................69

Figure 39 : Page Principale.................................................................................................................................................70

Figure 40 : accueil application............................................................................................................................................71

Figure 41 : Page Utilisateurs...............................................................................................................................................72

Figure 42 : Authentification élève......................................................................................................................................72

Figure 43 : gestion administrative de l’application............................................................................................................73

Figure 44 : gestion des élèves............................................................................................................................................74

Figure 45 : formulaire d’ajout d’un enseignant.................................................................................................................75


Liste des tableaux :

Tableau 1 : Scénario d’exécution du cas d’utilisation « S’authentifier »...........................................................................18

Tableau 2 : Scénario d’exécution du cas d’utilisation « gérer les élèves » (Ajouter un élève)..........................................19

Tableau 3 : Scénario d’exécution du cas d’utilisation « gérer les élèves » (Modifier un élève)........................................21

Tableau 4 : Scénario d’exécution du cas d’utilisation « gérer les élèves » (Supprimer un élève).....................................23

Tableau 5 : Scénario d’exécution du cas d’utilisation « gérer les enseignants » (Modifier un enseignant)......................24

Tableau 6 : Scénario d’exécution du cas d’utilisation « gérer les enseignants » (Ajouter un enseignant)........................27

Tableau 7 : Scénario d’exécution du cas d’utilisation « gérer les enseignants » (Supprimer un enseignant)...................29

Tableau 8 : Scénario d’exécution du cas d’utilisation « Planifier rendez-vous »...............................................................30

Tableau 9 : Scénario d’exécution du cas d’utilisation « Consacrer un volet pour les avis »..............................................32

Tableau 10 : Scénario d’exécution du cas d’utilisation « Déposer notes des examens »..................................................33

Tableau 11 : Scénario d’exécution du cas d’utilisation « S’authentifier » : enseignant....................................................34

Tableau 12 : Scénario d’exécution du cas d’utilisation « Explorer fiche de renseignement »..........................................37

Tableau 13 : Scénario d’exécution du cas d’utilisation « Exposer éléments d’enseignement ».......................................38

Tableau 14 : Scénario d’exécution du cas d’utilisation « exposer éléments de renseignement »....................................41

Tableau 15 : Scénario d’exécution du cas d’utilisation « Fixer date des examens ».........................................................43

Tableau 16 : Scénario d’exécution du cas d’utilisation « prendre rendez-vous avec parent ».........................................45

Tableau 17 : Scénario d’exécution du cas d’utilisation « Consulter éléments de renseignement ».................................47

Tableau 18 : Scénario d’exécution du cas d’utilisation « prendre rendez-vous avec un enseignant ».............................49

Tableau 19 : Scénario d’exécution du cas d’utilisation « Consulter éléments d’enseignement ».....................................51

Tableau 20 : Scénario d’exécution du cas d’utilisation « Consulter plan d’enseignement ».............................................53

Tableau 21 : Scénario d’exécution du cas d’utilisation « Consulter plan d’étude (personnalisé) »..................................55

Tableau 23 : Classe Enseignant..........................................................................................................................................58

Tableau 24 :Classe élève.....................................................................................................................................................58

Tableau 29 : Classe avis libre..............................................................................................................................................59

Tableau 30 : Classe examen...............................................................................................................................................60


Introduction générale
Nul doute quelle monde change d’une façon rapide et incontrôlable et la présence
de l’informatique est devenue importante pour son un rôle de circuler une information fiable,
automatique et rapide. Cette information ne peut accomplir sa fonction que si celle-
ci est prise en charge par un système d’information moyennant des
équipements informatiques. C’est pour cela que la production à la consommation des biens et
services informatiques est au centre de tout actuellement.

En effet, Le marché des technologies a connu une énorme évolution ces dernières
années et avec l’intégration de l’internet il y a eu des changements sur la façon et la rapidité
d’accès aux informations. Plusieurs secteurs se sont adaptés à ce changement et les
établissements essayent de plus en plus de profiter au maximum possible de ces technologies.
C’est notre but d’études en Informatique fondamentale au sein de la Faculté de Sciences de
Gafsa.

Notre projet consiste à développer une application scolaire mobile sous Android qui
propose de nombreuses fonctionnalités à l’utilisateur ainsi que sa partie administrative qui
consiste à gérer les services de tous les utilisateurs.

Aujourd'hui, il est rare de rencontrer un organisme ne possédant pas d’ergonomie et la


sécurité et surtout une base dynamique afin de fournir des réponses pertinentes, une telle
absence faisant encourir le risque de ne pas attirer de plus en plus les utilisateurs de croire
vraiment dont l’importance de l’informatique intégrée dans les méthodes pédagogique et
d’échange d’information en général.

Notre rapport de projet de fin d’études est organisé comme suit :

– Le premier chapitre concerne la présentation général et l’étude analytique de


l’existant et définir la mission ainsi que la spécification des besoins.

– Le deuxième chapitre illustre les phases de conception générale et détaillée du


système d’information.
– Le troisième chapitre est réservé à l’implémentation et la mise en œuvre de
l'application.
– Enfin, une conclusion qui synthétise notre travail et présente les perspectives
envisageables

hapitre I

PRÉSENTATION GÉNÉRALE DU
PROJET ET SPÉCIFICATION
Introduction
Ce premier chapitre est consacré à la présentation générale de notre projet en faisant la
spécification et l’étude fonctionnelle de la situation actuelle dans laquelle, on fera l’analyse et
la critique de l’existant achevée par proposer des solutions pour la mise en œuvre de notre
futur système d’information (application) et ce, en partant d’un cahier des charges précisant
tous les besoins client quels doit répondre ce système.
Ce chapitre sera clôturé par la description détaillée du fonctionnement du futur système
d’information à travers l’identification de ses différents cas d’utilisation et les acteurs y
participants.

Etude fonctionnelle
1. Présentation du projet
Le futur système, fruit de notre projet de fin d’études sera dédié aux écoles primaires et
plus précisément l’école primaire MOUHAMED BRAHMI, organisme pour lequel on
développera ce système, et ce, dans le but d’offrir de nouveaux services administratifs ainsi
mettre à la disposition des parents et les vis-à-vis de l’école, de nouveaux moyens d’accès
aux services déjà existants sans avoir la peine de se déplacer à l’école, sauf cas de nécessité
contraire. Ce qui assure une meilleure communication entre l’école (administration et staff
éducatif) et les parents/élèves.
Ce futur système se matérialisera en une application Android s’adaptant à tout type de
plateforme matérielle (PC, Tablette, Smartphone…).
En fait, ce système est une partie d’un grand projet comportant deux volets : volet
administratif et volet pédagogique. On s’intéressera au volet administratif.

Figure 1 : Idée du projet

2. Présentation de l’organisme d’accueil :


A. Description 
L’école primaire MOUHAMED BRAHMI est situé à cité Elwouroud au centre-ville de
SOUK JDID.
Au cours de l’année 2019-2020, l’école contient :
- 870 élèves répartis sur 31 classes d’étude
- 38 enseignants

- 13 salles d’enseignement
Cette école est un membre de l’espace numérique des écoles primaires Tunisiennes à
travers les identifiants numériques suivants :
- url :http://www.ent3.cnte.tn/sidibouzid/ali-ben-sadok
- Email : medbrahmiecole@gmail.com
- Page Facebook : https://www.facebook.com/pages/école-primaire-medbrahmi/

B. Organigramme

directeur enseignants éleves

parents(éleves)

Figure 2 : organigramme

3. Problématique 
En examinant les différentes conceptions et réalisations des applications similaires
préexistantes, on a constaté faiblesses et voire la quasi-absence des moyens fiables et
sécurisés assurant dans les règles de l’art, la communication réelle entre l’école et les
parents (élèves). En fait, ce qui est adopté dans ce domaine, n’est certes que des plates
formes pauvres de point de vue contenu, information et sécurité ou dédiées uniquement aux
écoles privées.
Sujet de notre projet, c’est de trouver une solution de remède à ces insuffisances en se
basant sur l’étude de l’état actuel du système d’information tout en se référant aux
exigences du cahier des charges du bénéficiaire.

4. Cahier des charges


Le futur système d’information à développer doit être une plateforme dédiée à
l’organisme d’accueil.
Cette plateforme ne sera accessible que par les personnes appropriées qui auront le droit
des services y offerts après avoir eu la permission d’y accéder.
La permission d’accès pour chaque personne autorisée doit être accordée via des
paramètres d’authentification lui ait attribués de façon authentique et unique par la personne
responsable de l’administration en arrière-plan de cette plateforme tout en respectant un
ensemble de besoins qui seront détaillés dans ce qui suit.

A. Les besoins fonctionnels

 Les besoins fonctionnels pour l’élève :

Le futur système d’information doit contenir un espace réservé aux élèves leur
permettant chacun, après authentification de consulter toute information qui lui est
intéressante et qui lui permet de :

- Consulter les cours d’enseignement par matière, par module, par unité/chapitre par
enseignant en suivant un assistant simple de recherche guidée.
- Télécharger les cours déjà exposés par ses enseignants.
- Déposer les comptes rendus et devoirs à la maison achevés dans l’espace de
l’enseignant approprié.
- Consulter les activités demandées par ses enseignants.
- Accomplir les activités demandées par ses enseignants.
 Les besoins fonctionnels pour l’enseignant :

Tout comme l’élève, après authentification, l’enseignant aura accès à différentes


fonctionnalités dans son espace personnel lui permettant entre autres de :
- Explorer ses cours d’enseignement par matière, par module, par unité/chapitre, sous
forme de :
 Contenu WYSIWYG (contenu HTML directement sur la page)
 Diaporama
 Animations
 Vidéos
 Documents Texte simples (Word)
 Documents PDF …
- Explorer des activités en ligne se rapportant aux cours déjà enseignés par matière, par
module, par unité/chapitre, sous forme de :
 QCM en ligne (tout type de QCM)
 Questions/Réponses
 Paragraphes troués (mots à compléter)
 Tableaux à remplir
 Relier des éléments entre eux par des flèches
 Production écrite (sous forme de rédaction)
- Exposer des devoirs à la maison et des comptes rendus en lignes.
- Exposer des évaluations exhaustives des acquis de ses élèves pour chaque unité
d’enseignement déjà achevée.
- Consulter et examiner les travaux exposés par ses élèves en leur faisant les remarques
et consignes correspondants.
- Exposer des statistiques de niveau d’acquis de ses élèves par matière, par unité
d’enseignement.
- Explorer les corrections détaillées des tests d’évaluation déjà passés par ses élèves
dans toutes matières par unité d’enseignement déjà achevée.
- Explorer les corrections détaillées des tests d’évaluation finaux de chaque trimestre
par matière d’enseignement.
 Les besoins fonctionnels pour l’administrateur :

Cette application est à la disposition de l’administrateur pour la gestion administrative,


pareil que l’élève et l’enseignant, après l’authentification il a accès aux fonctionnalités
suivantes :
- Gérer (en arrière-plan) les activités ci-dessus citées
- Gérer les espaces de travaux (session) des élèves.
- Effectuer la planification des cours, des activités, des consignes et des réclamations
des enseignants.
- Effectuer la classification et l’organisation des travaux et des comptes rendus en
lignes des élèves.
- Consacrer un volet libre de la plateforme pour les avis, réclamations et suggestions
des parents.
B. Les besoins non fonctionnels :
Pour répondre à tous ces besoins on doit se baser sur l’ergonomie des interfaces et
l’amélioration du temps de réponse :
- La sécurité : l’authentification de tous les acteurs doit être bien contrôlée par une base
de données qui sauvegarde les données nécessaires.
- La convivialité : l’application doit être facile surtout qu’on s’adresse à des élèves des
écoles primaires et qu’on doit faciliter le travail des enseignants à travers un
enchainement logique entre les interfaces
- La disponibilité : l’application doit être disponible lorsque tous les acteurs veulent
consulter ou bien exposer des données.

- Temps de réponse : Le temps de réponse doit être le plus court possible.

5. Etude de l’existant
A. Présentation et analyse de l’existant 

Après avoir consulté et bien examiner les applications nationales préexistantes qui sont
dédiées aux écoles primaires, on a pu constater que :
- Il n’existe pas une plateforme dédiée spécialement à la gestion des détails
administratifs et pédagogiques des écoles primaires de façon personnelle, spécifique
et pertinente.
- Les plates formes existantes contiennent la plupart du temps des devoirs d’évaluation
ou des documents de recherche embourbés dans un tas de spots publicitaires qui
gênent la navigation aisée.
- Le volet administratif est totalement absent d’où la non possibilité de communication
à distance entre la famille et l’école.
- Pour se rendre compte de la situation estudiantine et le suivi de son (ses) enfant(s), les
parents doivent se déplacer à l’école ou faire des coups téléphoniques aux personnes
appropriées.
- Les détails des écoles, maitres, élèves et administratifs ne sont pas répertoriés de
façon durables et facile à y accéder.
- Le site du ministère de l’éducation qui concerne les
écoles primaires s’intéresse la plupart du temps et
plus précisément à la gestion des notes des tests.
D’évaluation.
- La prise des rendez-vous n’est pas bien organisée.
- La confidentialité et la sécurité de ces plates formes sont très faibles : On peut
facilement perturber le fonctionnement des plates formes existantes.

- Les interfacesdes plates formes préexistantes manquent trop de cohérence et


d’ergonomie.
 Des exemples des applications nationales préexistantes :

Figure 3: Solution "EducaPhone"

Figure 4 : Solution "Madrassati"

B. Critique de l’existant

Le critique de l’existant doit mettre en évidence les activités fondamentales et les


informations associées, ainsi que les disfonctionnements du système actuel (applications
actuelles les plus utilisables).
Jusqu’aujourd’hui, la gestion des enseignants, élèves se fait d’une façon quasi manuelle
dans la plupart des écoles primaires ce qui nous emmène à dégager les défaillances et les
point critiques suivants :
- Sécurité : pas de confidentialités de données personnelles.
- La quasi-absence de la persistance des données dans les solutions (plates formes)
qui existent déjà.
- Mal organisation du contenu dans les plates formes préexistantes, ainsi le manque
d’interactivité et de flexibilité de navigation.
- Manque quasi-total de communication à distance entre les parents et l’école ce qui
engendre une défaillance informationnelle (avis, réclamations) sauf de bouche à
oreille ou bien à travers les élèves qui faute de non conscience peuvent ne pas
passer une information complète et consistante.
- Absence de l’archivage numériques des ressources pédagogiques et administratives
ce qui peut engendrer un gaspillage tant énorme à ce niveau.

6. Objectifs à atteindre :
L’objectif primordial de ce travail est de concevoir et développer un système
(plateforme) sécurisé et accessible en ligne assurant la gestion des détails pédagogiques et
administratifs de l’école primaire MOUHAMED BRAHMI tout en maximisant l’apport
scientifique, pédagogique et graphique.
Ce système doit être à la fois souple et sécurisé dans la limite d’assurer une navigation
aisée des personnes appropriées.
En outre, ce système doit gérer la persistance des données et assurer un volume
informationnel riche, clair et consistant.

7. Solution proposée :
L’étude déjà effectuée et en partant des besoins ci-dessus mentionnés, nous a conduit à
la décision de développer une solution Androïde accessible aisément par les personnes
appropriées via n’importe quel type de dispositif de communication intelligent
(Smartphone, Tablette, PC …).
Cette solution numérique doit répondre à tous les besoins ci-dessus cités et doit remplir
entièrement les objectifs déjà fixés.

8. Planning de réalisation
Figure 5 : Planning de réalisation

Spécification :
1. Identification des cas d’utilisation :
Le futur système d’information, doit être capable de remplir les fonctionnalités suivantes :
- La gestion des élèves.
- La gestion des enseignants.
- Planification des rendez-vous.
- La gestion des examens (dates, notes...)
- Exposition du plan d’étude.
- Exposition des éléments de renseignements.
- Consulter le plan d’étude.
- Consulter les activités.
- Consulter les éléments d’enseignements.
NB : toutes ces tâches seront accessibles après avoir été authentifié.

2. Présentation des acteurs :


- Administrateur
- Enseignant
- Parent (élève)

3. Classification des cas d’utilisations par acteur :


Chacun des acteurs ci-dessus cités, lui ait confié un ensemble de tâches bien déterminées :

 Administrateur :

 S’authentifier.
 Gérer les élèves.
 Gérer les enseignants.
 Planifier les rendez-vous.
 Contrôler le volet libre pour les avis.
 Déposer notes d’examens.
 Planifier les éléments de renseignements.

 Enseignant :

 S’authentifier.
 Explorer fiche de renseignements.
 Exposer éléments de renseignements.
 Fixer dates des examens.
 Prendre rendez-vous avec parents.
 Exposer éléments d’enseignement.

 Parent (élève) :

 S’authentifier.
 Consulter plan d’étude.
 Consulter éléments d’enseignement.
 Consulter éléments de renseignements.
 Demande de rendez-vous.

4. Diagrammes des cas d’utilisation :


Un cas d’utilisation est un classificateur qui modélise une fonctionnalité d’un système ou
d’une classe. C’est un ensemble d’actions réalisées par le système en réponse à une action
d’un acteur [B1]. Ci-dessous les diagrammes de cas d’utilisation de notre système.
Figure 6: diagramme cas d’utilisation parent (élève)
Figure 7 : diagramme cas d’utilisation (enseignant)
Figure 8 : diagramme cas d’utilisation (administrateur)

5. Relations entre les cas d’utilisation :


Il existe deux types de relations : les dépendances stéréotypées et le
généralisations/spécialisations. Les dépendances stéréotypées les plus utilisées sont
l’inclusion et l’extension. [B1]

A. La relation d’inclusion :
B est une partie obligatoire de A et on lit A INCLUT B (dans le sens de la flèche) [B1]

Figure 9 : relation inclusion

B. Relation d’extension :

B est une partie optionnelle de A et on lit B ÉTEND A(dans le sens de la flèche) [B1]

C. Relation de généralisation :

Le cas A est une généralisation du cas du cas B et on lit B EST UNE SORTE DE A.
[B1]

Figure10 : relation généralisation

Conclusion

On a essayé de présenter le projet d’une façon global et d’une façon détaillée en


analysant les fonctionnalités et les différents besoins extraire d’une étude de l’existence.
Chapitre II

CONCEPTION
Introduction
Dans cette partie on va essayer de bien présenter la réalisation du projet étape par étape
pour cela on va suivre une démarche a fin de décomposer l’application pour faire la
distinction des interactions et des scénarios suivis des ensembles de diagrammes de
séquences et des classes en utilisant les diagrammes d’UML (Unified Modeling Language).

I. Choix de la méthode de conception :


Notre choix est résultant de l’importance de la spécification de chaque étape et chaque
diagramme selon une méthodologie basée notamment sur le langage UML.

Figure 11 : Logo UML

Le langage de modélisation unifié (UML : Unified Modeling Language) a pour but de


normaliser les différentes méthodes et de donner en fin une approche simple pour mieux
comprendre le projet, une vision globale et une autre bien détaillé des composants et leurs
interactions.

II. Description des scénarios et des diagrammes de


séquence
Chaque cas d’utilisation sera bien détaillé et présentée dans cette partie en suivant des
scénarios et un ensemble des diagrammes de séquences et de classes.
- On peut distinguer 3 scénarios qui vont nous faciliter le déroulement et les cas
particulier de chaque cas d’utilisation.
- Scénario nominal 
- Scénario alternatif
- Scénario d’échec (d’erreur)
- Les diagrammes de séquence montrent des interactions entre les objets selon
un point de vue temporel. La représentation se concentre sur l’expression des
interactions.
Le diagramme de séquence est construit autour de trois éléments fondamentaux. Les objets,
leur ligne de vie et les messages.
.[B2]
- Un diagramme d'activités permet de représenter graphiquement le comportement des
objets ou le déroulement d'un cas d'utilisation Il permet de spécifier des traitements à
priori séquentiels, il offre un pouvoir d’expression très proche de langages de
programmation objet : spécification des actions de base, structures de contrôle
(conditionnels, boucles) ainsi que les traductions particulières à la programmation
orientée objet (appel d’opérations exception).
- Le diagramme d’activité est une formalisation graphique des activités qui sont reliés
par des flèches appelés transitions.
- Une activité représente une exécution d’un mécanisme, un déroulement d’étapes
séquentielles.
- Le passage d’une activité vers une autre est matérialisé par une transition[B1]

1. Administrateur :
 Scénario d’exécution du cas d’utilisation « S’authentifier »

Tableau 1 : Scénario d’exécution du cas d’utilisation « S’authentifier »


Cas « S’authentifier »
Acteur Administrateur
Pré condition L’administrateur ne s’est pas authentifié
L’administrateur fait son identification au système par ses paramètres
Description d’authentification personnels pour pouvoir accéder à son espace de
gestion personnel.
1. L’administrateur demande l’accès à son espace de gestion
personnel,
2. Le système affiche le formulaire d’authentification correspondant,
3. L’administrateur remplit le formulaire par les informations
correspondantes (login et mot de passe),
Scénario nominal
4. L’administrateur envoi le formulaire pour valider l’opération
d’authentification,
5. Le système vérifie les informations envoyées par l’administrateur,
6. Le système confirme l’opération d’authentification,
7. L’administrateur accède à son espace de gestion personnel.
Scénario alternatif Si le formulaire n’est pas bien rempli (un champ non rempli ou un
champ vide ou bien valeur de champ non valide) le cas d’utilisation
reprend à la 2ème étape du scénario nominal.
Si la reprise de l’opération d’authentification se reproduit pour la
Scénario d’erreur troisième fois sans succès, l’opération se termine par un échec et le
système se bloque pour un délai de temps bien déterminé.
Post condition Administrateur authentifié.

Figure 12 : diagramme de séquences du cas d’utilisation « S’authentifier »

 Scénario d’exécution du cas d’utilisation « gérer les élèves » (Ajouter un élève)

Tableau 2 : Scénario d’exécution du cas d’utilisation « gérer les élèves » (Ajouter un élève)


Cas « Gérer les élèves » (Ajouter un élève)
Acteur Administrateur
Pré condition L’administrateur à fait son authentification
Description L’administrateur ajoute un nouvel élève à la liste déjà existante.
Scénario nominal 1. L’administrateur choisit l’opération « Ajouter un élève » dans la
liste d’action « gérer les élèves »,
2. Le système affiche le formulaire d’ajout correspondant,
3. L’administrateur remplit le formulaire par les informations
correspondant à l’élève à ajouter,
4. L’administrateur envoi le formulaire pour valider l’opération
d’ajout,
5. Le système vérifie les informations envoyées par l’administrateur,
6. Le système confirme l’opération d’ajout effectuée.
Si le formulaire n’est pas bien rempli (un champ obligatoire n’est pas
Scénario alternatif rempli ou un champ non valide ou vide) le cas d’utilisation reprend à
la 2ème étape du scénario nominal.
Post condition Nouvel élève ajouté avec succès.
 Diagramme de séquences du cas d’utilisation « gérer les élèves » (Ajouter un élève) :

Figure 13 : diagramme de séquences du cas d’utilisation « gérer les élèves » (Ajouter un élève) 

 Scénario d’exécution du cas d’utilisation « gérer les élèves » (Modifier un élève)

Tableau 3 : Scénario d’exécution du cas d’utilisation « gérer les élèves » (Modifier un élève)


Cas « Gérer les élèves » (modifier un élève)
Acteur Administrateur
Pré condition L’administrateur à fait son authentification
Description L’administrateur modifie un élève de la liste déjà existante.
1. L’administrateur choisit l’opération « modifier un élève » dans la liste
d’action « gérer les élèves »,

2. Le système affiche la liste des élèves,

3. L’administrateur choisit l’élève à modifier,

Scénario 4. Le système charge les informations de l’élève dans un formulaire,

nominal 5. L’administrateur modifie les informations souhaitées,

6. L’administrateur envoi le formulaire pour valider l’opération de


modification,

7. Le système vérifie les informations envoyées par l’administrateur,

8. Le système confirme l’opération de modification.

Si le formulaire n’est pas bien rempli (un champ obligatoire vide ou contenu
Scénario
de champ non valide) le cas d’utilisation reprend à la 5ème étape du scénario
d’erreur
nominal.

Post
Un élève modifié avec succès.
condition

 Diagramme de séquences du cas d’utilisation « gérer les élèves » (Modifier un élève) :


Figure 14 : diagramme de séquences du cas d’utilisation « gérer les élèves » (Modifier un élève) 
 Scénario d’exécution du cas d’utilisation « gérer les élèves » (supprimer un élève)

Tableau 4 : Scénario d’exécution du cas d’utilisation « gérer les élèves » (Supprimer un élève)

Cas « Gérer les élèves » (supprimer un élève)

Acteur Administrateur

Pré condition L’administrateur à fait son authentification


Description L’administrateur supprime un élève de la liste déjà existante.

1. L’administrateur choisit l’opération « supprimer un élève » dans la


liste d’action « gérer les élèves »,
2. Le système affiche la liste des élèves,
Scénario nominal 3. L’administrateur choisit l’élève à supprimer,
4. Le système demande la confirmation du choix de suppression.
5. L’administrateur valide l’opération de suppression,
6. Le système confirme l’opération de suppression.

Post condition Un élève supprimé avec succès.

 Diagramme de séquences du cas d’utilisation « gérer les élèves » (Supprimer un élève) :

Figure 15 : diagramme de séquences du cas d’utilisation « gérer les élèves » (Supprimer un élève) 

 Scénario d’exécution du cas d’utilisation « gérer les enseignants » (Modifier un


enseignant)
Tableau 5 : Scénario d’exécution du cas d’utilisation « gérer les enseignants » (Modifier un
enseignant)

Cas « Gérer les enseignants » (modifier un enseignant)

Acteur Administrateur

Pré condition L’administrateur à fait son authentification

Description L’administrateur modifie un enseignant de la liste déjà existante.

1. L’administrateur choisit l’opération « modifier un enseignant »


dans la liste d’action « gérer les enseignants »,
2. Le système affiche la liste des enseignants,
3. L’administrateur choisit l’enseignant à modifier,
4. Le système charge les informations de l’enseignant dans un
Scénario nominal formulaire,
5. L’administrateur modifie les informations souhaitées,
6. L’administrateur envoi le formulaire pour valider l’opération de
modification,
7. Le système vérifie les informations envoyées par l’administrateur,
8. Le système confirme l’opération de modification.

Si le formulaire n’est pas bien rempli (un champ obligatoire vide ou


Scénario d’erreur contenu de champ non valide) le cas d’utilisation reprend à la 5ème
étape du scénario nominal.

Post condition Un enseignant modifié avec succès.


 Diagramme de séquences du casd’utilisation « gérer les enseignants » (Modifier un
enseignant) :
Figure 16 : diagramme de séquences du cas d’utilisation « gérer les enseignants » (Modifier un
enseignant) 
 Scénario d’exécution du cas d’utilisation « gérer les enseignants » (Ajouter un enseignant)

Tableau 6 : Scénario d’exécution du cas d’utilisation « gérer les enseignants » (Ajouter un


enseignant)
Cas « Gérer les enseignants » (Ajouter un enseignant)
Acteur Administrateur
Pré condition L’administrateur à fait son authentification
Description L’administrateur ajoute un nouvel enseignant à la liste déjà existante.

1. L’administrateur choisit l’opération « Ajouter un enseignant » dans


la liste d’action « gérer les enseignants »,
2. Le système affiche le formulaire d’ajout correspondant,
3. L’administrateur remplit le formulaire par les informations
Scénario nominal correspondant à l’enseignant à ajouter,
4. L’administrateur envoi le formulaire pour valider l’opération
d’ajout,
5. Le système vérifie les informations envoyées par l’administrateur,
6. Le système confirme l’opération d’ajout effectuée.
Si le formulaire n’est pas bien rempli (un champ obligatoire n’est pas
Scénario alternatif rempli ou un champ non valide ou vide) le cas d’utilisation reprend à
la 2ème étape du scénario nominal.
Post condition Nouvel enseignant ajouté avec succès.

 Diagramme de séquences du casd’utilisation « gérer les enseignants » (Ajouter un


enseignant) :
Figure 17 : diagramme de séquences du cas d’utilisation « gérer les enseignants » (Ajouter un
enseignant) 
 Scénario d’exécution du casd’utilisation « gérer les enseignants » (Supprimer un
enseignant)

Tableau 7 : Scénario d’exécution du cas d’utilisation « gérer les enseignants » (Supprimer un


enseignant)
Cas « Gérer les enseignants » (Supprimer un enseignant)
Acteur Administrateur
Pré condition L’administrateur à fait son authentification
Description L’administrateur supprime un enseignant de la liste déjà existante.
1. L’administrateur choisit l’opération « supprimer un enseignant »
dans la liste d’action « gérer les enseignants »,
2. Le système affiche la liste des enseignants,
3. L’administrateur choisit l’enseignant à supprimer,
Scénario nominal
4. Le système demande la confirmation du choix de suppression.
5. L’administrateur valide l’opération de suppression,

6. Le système confirme l’opération de suppression.

Post condition Un enseignant supprimé avec succès.

 Diagramme de séquences du casd’utilisation « gérer les enseignants » (Supprimer un


enseignant) :
Figure 18 : diagramme de séquences du cas d’utilisation « gérer les enseignants » (Supprimer un
enseignant) 

 Scénario d’exécution du casd’utilisation « Planifier rendez-vous »

Tableau 8 : Scénario d’exécution du cas d’utilisation « Planifier rendez-vous »

Cas « Planifier rendez-vous »

Acteur Administrateur

Pré condition L’administrateur à fait son authentification

Description L’administrateur planifie des rendez-vous entre les utilisateurs.

Scénario 1. L’administrateur reçoit une demande de rendez-vous,


nominal
2. L’administrateur choisit « planifier un rendez-vous »,
3. Le système charge un calendrier,

4. L’administrateur choisit la date de rendez-vous,

5. Le système vérifie la validité de la date,

6. Le système affiche la liste des utilisateurs,

7. L’administrateur choisit les membres concernés,

8. Le système envoie des notifications aux membres concernés par le


rendez-vous,

Post
Un rendez-vous est planifié par succès.
condition

 Diagramme de séquences du casd’utilisation « Planifier rendez-vous » :


Figure 19 : diagramme de séquences du cas d’utilisation « Planifier rendez-vous »
 Scénario d’exécution du casd’utilisation « Consacrer un volet pour les avis »

Tableau 9 : Scénario d’exécution du cas d’utilisation « Consacrer un volet pour les avis »


Cas « Consacrer un volet pour les avis »
Acteur Administrateur
Pré condition L’administrateur à fait son authentification
Description L’administrateur ouvre un volet libre pour les avis des utilisateurs

1. L’administrateur choisit « contrôler le centre de messagerie »,

Scénario nominal 2. Le système affiche le centre de messagerie pour tous les


utilisateurs,
3. L’administrateur gère l’espace (ajouter/supprimer) des membres,
Post condition Un espace de discussion est activé.
 Diagramme de séquences du casd’utilisation « Consacrer un volet pour les avis » :

Figure 20 : diagramme de séquences du cas d’utilisation « Consacrer un volet pour les avis »

 Scénario d’exécution du cas d’utilisation « Déposer notes des examens » :

Tableau 10 : Scénario d’exécution du cas d’utilisation « Déposer notes des examens »


Cas Déposer notes des examens
Acteur Administrateur
Pré condition L’administrateur à fait son authentification
Description L’administrateur dépose les notes des examens.
Scénario 1. Le système affiche une page contenant les choix des actions (travaux)
nominal possibles pour L’administrateur.
2. L’administrateur choisit dans la liste d’actions possibles, l’action :
« déposer notes des examens »,
3. Le système affiche les différentes classes d’enseignement
correspondant à L’administrateur.
4. L’administrateur choisit la classe souhaitée.
5. Le système affiche le formulaire d’affichage (de saisie = déposition)
des notes d’examen de la classe d’enseignement choisie par
L’administrateur,
6. L’administrateur remplit le formulaire.
7. L’administrateur envoi le formulaire pour valider l’opération
d’affichage des notes d’examen.
8. Le système vérifie les informations envoyées par L’administrateur.
9. Le système confirme l’opération effectuée.
- Si le formulaire n’est pas bien rempli (un champ obligatoire laissé
vider ou un champ avec contenu non valide) le cas d’utilisation
Scénario
reprend à l’étape 5 du scénario nominal.
alternatif
- L’administrateur décide de quitter la page courante sans avoir
accompli l’affichage des notes d’examen.
Post condition Les notes d’examen sont déposées avec succès.

 Diagramme de séquences du cas d’utilisation « Déposer notes des examens » :


Figure 21 : diagramme de séquences du cas d’utilisation « Déposer notes des examens »

2. Enseignant :
 Scénario d’exécution du casd’utilisation « S’authentifier » :

Tableau 11 : Scénario d’exécution du cas d’utilisation « S’authentifier » : enseignant

Cas « S’authentifier »

Acteur Enseignant

Pré condition L’Enseignant n’est pas authentifié

L’Enseignant fait son identification au système par ses paramètres


Description d’authentification personnels pour pouvoir accéder à son espace de gestion
personnel.
Scénario
1. L’Enseignant demande l’accès à son espace de gestion personnel,
nominal
2. Le système affiche le formulaire d’authentification correspondant,
3. L’Enseignant remplit le formulaire par les informations correspondantes
(login et mot de passe),

4. L’Enseignant envoi le formulaire pour valider l’opération


d’authentification,

5. Le système vérifie les informations envoyées par L’Enseignant.

6. Le système confirme l’opération d’authentification,

7. L’Enseignant accède à son espace de gestion personnel.

Si le formulaire n’est pas bien rempli (un champ non rempli ou un champ
Scénario
vide ou bien valeur de champ non valide) le cas d’utilisation reprend à la
alternatif
2ème étape du scénario nominal.

Si la reprise de l’opération d’authentification se reproduit pour la troisième


Scénario
fois sans succès, l’opération se termine par un échec et le système se bloque
d’erreur
pour un délai de temps bien déterminé.

Post condition Enseignant authentifié.

 Diagramme de séquences du casd’utilisation « S’authentifier » :


Figure 22: diagramme de séquences du cas d’utilisation « S’authentifier » : enseignant

 Scénario d’exécution du casd’utilisation « Explorer fiche de renseignement » :

Tableau 12 : Scénario d’exécution du cas d’utilisation « Explorer fiche de renseignement »


Cas Explorer fiche de renseignement.
Acteur L’enseignant
Pré condition L’enseignant à fait son authentification
Description L’enseignant explore les fiches de renseignement de ses élèves.
Scénario nominal 1. Le système affiche une page contenant les choix des actions
(travaux) possibles pour l’enseignant.
2. L’enseignant choisit dans la liste d’actions possibles, l’action :
« Explorer fiche de renseignement »,
3. Le système affiche les classes d’enseignement correspondant à
l’enseignant,
4. L’enseignant choisit la classe souhaitée,
5. Le système affiche la liste des élèves appartenant à cette classe
d’enseignement correspondant à cet enseignant,
6. L’enseignant choisit l’action « Explorer fiche de renseignement »
pour l’élève souhaité,

7. Le système affiche la fiche de renseignement correspondant à


l’élève choisi.

L’enseignant décide de quitter la page courante sans avoir explorer les


Scénario alternatif
fiches souhaitées.
La(les) fiche(s) a (ont) été bien explorée(s) et examinée(s) par
Post condition
L’enseignant.

 Diagramme de séquences du casd’utilisation « Explorer la fiche de renseignement » :


Figure 23 : diagramme de séquences du cas d’utilisation « Explorer fiche de renseignement »

 Scénario d’exécution du casd’utilisation « Exposer éléments d’enseignement »

Tableau 13 : Scénario d’exécution du cas d’utilisation « Exposer éléments d’enseignement »

Cas « Exposer éléments d’enseignement »

Acteur Enseignant

Pré condition L’Enseignant à fait son authentification

Description L’Enseignant expose les activités dans son plan d’étude.

Scénario nominal 1. L’Enseignant choisit l’opération « Exposer éléments


d’enseignement ».
2. Le système charge un formulaire à remplir.
3. L’Enseignant remplit le formulaire par les informations et les
pièces jointes nécessaires.
4. L’Enseignant envoi le formulaire pour valider l’opération.
5. Le système vérifie les informations envoyées par l’enseignant.
6. Le système confirme l’opération effectuée.

Si le formulaire n’est pas bien rempli (un champ obligatoire n’est pas
Scénario alternatif rempli ou un champ non valide ou vide) le cas d’utilisation reprend à
la 2ème étape du scénario nominal.

Les éléments d’enseignements (cours et activités)sontexposés dans le


Post condition
plan d’étude.
 Diagramme de séquences du casd’utilisation « Exposer éléments d’enseignement »:

Figure 24: diagramme de séquences du cas d’utilisation « Exposer éléments d’enseignement »


 Scénario d’exécution du cas d’utilisation « Exposer éléments de renseignement»

Tableau 14 : Scénario d’exécution du cas d’utilisation « exposer éléments de renseignement »


Cas « Exposer éléments de renseignement »
Acteur Enseignant
Pré condition L’Enseignant à fait son authentification
L’Enseignant expose des éléments de renseignement (consignes à suivre,
Description
réclamations, avertissements) à ses élèves.

1. Le système affiche une page contenant les choix des actions (travaux)
possibles pour l’enseignant,

2. L’enseignant choisit dans la liste d’actions possibles, l’action :


« Exposer éléments de renseignement »,

3. Le système affiche les types de renseignement possibles (consignes à


suivre, réclamations, avertissements),

4. L’enseignant choisit le type de renseignement souhaité,

5. Le système affiche les niveaux d’enseignement concernés,

6. L’enseignant choisit le niveau d’enseignement souhaité,


Scénario nominal

7. Le système affiche un formulaire contenant des rubriques à remplir


par les éléments de renseignement souhaités ainsi que la liste des
élèves du niveau concerné.

8. L’enseignant remplit les rubriques de renseignement

9. L’enseignant choisit la liste destination des élèves pour lesquels, il


exposera ces éléments de renseignements,

10. L’enseignant valide l’opération,

11. Le système confirme l’opération en envoyant les éléments de


renseignement aux destinataires concernés.
Scénario alternatif
- L’enseignant n’a pas bien rempli les rubriques de renseignement, le
cas d’utilisation reprend à l’étape 7 du scénario nominal.
- L’enseignant n’a pas choisi les destinataires des éléments de
renseignement, le cas d’utilisation reprend à l’étape 9 du scénario
nominal.

- L’enseignant décide de quitter la page courante sans avoir accompli


l’exposition des éléments de renseignement souhaités.
Post condition Les éléments de renseignements envoyés aux destinataires concernés.

 Diagramme de séquences du cas d’utilisation « Exposer éléments de renseignement » :


Figure 25 : diagramme de séquences du cas d’utilisation « Exposer éléments de renseignements »

 Scénario d’exécution du cas d’utilisation « Fixer date des examens »

Tableau 15 : Scénario d’exécution du cas d’utilisation « Fixer date des examens »


Cas « Fixer date des examens (Evaluations) »

Acteur Enseignant
Pré condition L’Enseignant à fait son authentification

L’Enseignant Fixe la date d’un examen (Evaluation : écrite ou orale ou


Description
travaux pratiques) à passer ultérieurement par ses élèves.

1. Le système affiche une page contenant les choix des actions


(travaux) possibles pour l’enseignant.

2. L’enseignant choisit dans la liste d’actions possibles, l’action :


« Fixer la date d’un examen (évaluation) »,

3. Le système affiche la liste des matières de l’enseignant suivi


chacune des types d’examen possibles (écrit, oral, travaux
pratiques),
Scénario nominal
4. L’enseignant choisit les matières souhaitées et pour chaque matière
le type d’examen requis,
5. Le système charge un calendrier, pour chaque examen sélectionné
6. L’Enseignant Fixe la date correspondant à l’examen sélectionné à
travers le calendrier,
7. Le système vérifie la validité de la date fixée,
8. L’Enseignant valide les choix effectués,
9. Le système confirme l’opération.

- L’enseignant a validé le travail sans avoir choisi les matières et


leurs dates d’examen, le cas d’utilisation reprend à l’étape 3 du
scénario nominal.
- Si La date fixée pour un examen est invalide (occupée par plus de
Scénario alternatif
2 autres examens ou date déjà expirée ou un il s’agit d’un jour
férié) le cas d’utilisation reprend à l’étape 5 du scénario nominal.
- L’enseignant décide de quitter la page courante sans avoir
accompli la fixation des dates d’examens souhaitées.
Post condition La date de l’examen est fixée avec succès.

 Diagramme de séquences du cas d’utilisation « Fixer date des examens »


Figure 26 : diagramme de séquences du cas d’utilisation « Fixer date des examens »

 Scénario d’exécution de cas d’utilisation « prendre rendez-vous avec parent »

Tableau 16 : Scénario d’exécution du cas d’utilisation « prendre rendez-vous avec parent »


Cas « Prendre rendez-vous avec parent »
Acteur Enseignant
Pré condition L’Enseignant à fait son authentification
Description L’Enseignant prend un rendez-vous avec un ou des parent(s).

1. Le système affiche une page contenant les choix des actions


(travaux) possibles pour l’enseignant.

2. L’enseignant choisit dans la liste d’actions possibles, l’action :


« Convocation parent élève »,

3. Le système affiche la liste des élèves faisant partie des classes


d’étude de cet enseignant,

4. L’Enseignant choisit l’élève (les) dont il souhaite convoquer l’un


de ses (leurs) parents,
Scénario nominal
5. Le système charge un calendrier pour chaque élève choisi pour
fixer la date du rendez-vous, de la convocation,

6. L’Enseignant choisit la date souhaitée pour chaque rendez-vous,

7. Le système vérifie la validité de chaque date choisie,

8. L’Enseignant valide l’opération de convocation.

9. Le système confirme l’action et envoie une convocation aux


membres spécifiés.

- L’enseignant a validé le travail sans avoir choisi les élèves dont il


souhaite convoquer leurs parents, le cas d’utilisation reprend à
l’étape 3 du scénario nominal.
- Si La date fixée pour un rendez-vous est invalide (date d’examen
Scénario alternatif
ou date déjà expirée ou un il s’agit d’un jour férié) le cas
d’utilisation reprend à l’étape 5 du scénario nominal.
- L’enseignant décide de quitter la page courante sans avoir
accompli la convocation souhaitée des parents.

Post condition Une convocation de parents (rendez-vous) est planifiée avec succès.

 Diagramme de séquences du cas d’utilisation « prendre rendez-vous avec parent » :


Figure 27 : diagramme de séquences du cas d’utilisation « prendre rendez-vous avec parent »

3. Parent :
 Scénario d’exécution de cas d’utilisation « Consulter éléments de renseignement » :
Tableau 17 : Scénario d’exécution du cas d’utilisation « Consulter éléments de renseignement »
Cas Consulter éléments de renseignement.
Acteur Parent
Pré condition Le parent a fait son authentification
Le parent consulte les éléments de renseignement souhaités qui
Description
concernent son fils (sa fille).
1. Le système affiche une page contenant les choix des actions (travaux)
possibles pour le parent.
2. Le parent choisit dans la liste d’actions possibles, l’action :
« consulter éléments de renseignement »,
Scénario
3. Le système affiche les types de renseignement possibles (consignes à
nominal
suivre, réclamations, avertissements),
4. Le parent choisit le type de renseignement souhaité,
5. Le système charge les éléments de renseignements choisis par le
parent et qui concernent son fils (sa fille).
Scénario Le parent décide de quitter la page courante sans avoir consulté les
alternatif éléments de renseignements de son fils (sa fille)
Le parent a bien, consulté les éléments de renseignements souhaités qui
Post condition
concernent son fils (sa fille).

 Diagramme de séquences du cas d’utilisation « Consulter éléments de renseignement


» :
Figure 28 : diagramme de séquences du cas d’utilisation « Consulter éléments de renseignement »

 Scénario d’exécution du cas d’utilisation « prendre rendez-vous avec enseignant »


Tableau 18 : Scénario d’exécution du cas d’utilisation « prendre rendez-vous avec un enseignant »
Cas « Prendre rendez-vous avec un enseignant »
Acteur Parent
Pré condition Le Parent a fait son authentification
Description Le Parent demande la prise d’un rendez-vous avec un enseignant.
1. Le système affiche une page contenant les choix des actions (travaux)
possibles pour le parent,
2. Le parent choisit dans la liste d’actions possibles, l’action : « Prendre
un rendez-vous avec un enseignant »,
3. Le système affiche la liste des enseignants,
Scénario 4. Le parent choisit l’enseignant concerné,
nominal 5. Le système charge un calendrier contenant les horaires de
disponibilités possibles de l’enseignant pour le rendez-vous souhaité,
6. Le parent choisit l’horaire souhaité,
7. Le parent valide l’opération,

8. Le système confirme la demande de rendez-vous effectuée.

Scénario Le parent décide de quitter la page courante sans avoir effectué la


alternatif demande de rendez-vous.
Post condition Une demande de prise de rendez-vous est planifiée avec succès.

 Diagramme de séquences du cas d’utilisation « prendre rendez-vous avec un enseignant » :


Figure 29 : diagramme de séquences du cas d’utilisation « prendre rendez-vous avec un enseignant
»

4. Parent(élève) :
 Scénario d’exécution du cas d’utilisation « Consulter éléments d’enseignement » :
Tableau 19 : Scénario d’exécution du cas d’utilisation « Consulter éléments d’enseignement »
Cas Consulter éléments d’enseignement.
Acteur Parent (élève)
Pré condition Parent (Elève) a fait son authentification
Description Parent (Elève) consulte éléments d’enseignement.
1. Le système affiche une page contenant les choix des actions
(travaux) possibles pour le parent,
2. Le parent (élève) choisit dans la liste d’actions possibles, l’action :
« Consulter éléments d’enseignement ».
3. Le système affiche la liste des niveaux,
Scénario nominal
4. L’élève (parent) choisit son niveau (le niveau de son fils/fille),
5. Le système charge les cours et les activités disponibles pour ce
niveau,

6. Le parent (élève) choisit le(s) cour(s) et le(s) activité(s) à consulter.

Le parent décide de quitter la page courante sans avoir effectué la


Scénario alternatif
consultation souhaitée.
Parent (élève) a bien consulté le(s) cour(s) et le(s) activité(s) de son
Post condition
niveau.

 Diagramme de séquences du cas d’utilisation « Consulter les éléments


d’enseignements » :
Figure 30 : diagramme de séquences du cas d’utilisation « Consulter les cours et les activités »

 Scénario d’exécution du cas d’utilisation « Consulter plan d’enseignement » :

Tableau 20 : Scénario d’exécution du cas d’utilisation « Consulter plan d’enseignement »


Cas Consulter plan d’enseignement.
Acteur Parent (élève)
Pré condition Parent (élève) a fait son authentification
Description Parent (élève) consulte le plan d’étude général de son niveau.
1. Le système affiche une page contenant les choix des actions (travaux)
possibles pour le parent,
2. Le parent (élève) choisit dans la liste d’actions possibles, l’action :
« Consulter plan d’étude »,
3. Le système affiche la liste des niveaux,
Scénario
4. L’élève (parent) choisit son niveau,
nominal
5. Le système affiche les types de consultations possibles (général ou
personnalisé),
6. L’élève (parent) choisit le type de consultation général,

7. Le système charge le plan d’étude général de ce niveau.

Scénario Le parent décide de quitter la page courante sans avoir consulté le plan
alternatif d’étude souhaité.
Post condition Parent (élève) a bien consulté son plan d’étude général.

 Diagramme de séquences du cas d’utilisation « Consulter plan d’étude » :


Figure 31: diagramme de séquences du cas d’utilisation« Consulter plan d’étude »

 Scénario d’exécution du cas d’utilisation « Consulter plan d’étude (personnalisé) » :


Tableau 21 : Scénario d’exécution du cas d’utilisation « Consulter plan d’étude (personnalisé) »
Cas Consulter plan d’étude personnalisé.
Acteur Parent (élève)
Pré condition Parent (élève) a fait son authentification
Description Parent (élève) consulte le plan d’étude personnalisé de son niveau.
1. Le système affiche une page contenant les choix des actions (travaux)
possibles pour le parent,
2. Le parent (élève) choisit dans la liste d’actions possibles, l’action :
« Consulter plan d’étude »,
3. Le système affiche la liste des niveaux
4. Le parent (élève) choisit son niveau,
Scénario 5. Le système affiche les types d’affichage possibles (général ou
nominal personnalisé),
6. Le parent (élève) choisit le type de consultation personnalisé,
7. Le système affiche les types de choix consultation possibles (par
matière / par module / par unité, trimestriel / annuel),
8. Le parent (élève) choisit le type de consultations souhaité,

9. Le système affiche le plan d’étude correspondant.

Scénario Le parent décide de quitter la page courante sans avoir consulté le plan
alternatif d’étude souhaité.
Post condition Parent (élève) a bien consulté le plan d’étude personnalisé choisi.

 Diagramme de séquences du cas d’utilisation « Consulter plan d’étude personnalisé » :


Figure 32 : diagramme de séquences du cas d’utilisation « Consulter plan du cours personnalisé »

Développement de modèle statique


Un modèle statique décrit la structure statique du système et les relations entre les
composants. Nous allons traiter le diagramme de classes qui constituent la forme de la base
des données.

1. Le dictionnaire de données

Pour la construction du diagramme de classes on dégage le dictionnaire de données suivant :

Tableau 22 :dictionnaire de donneés


Numéro Nom des variables Désignation

01 id_enseignant L’identifiant de l’enseignant

02 Nom_enseignant Le nom de l’enseignant

03 Prenom_enseignant Le prénom de l’enseignant

04 Niveau_enseigne Le niveau enseignement du l’enseignant

05 Identifiant L’identifiant de l’élève

06 Nom Nom de l’élève

07 Prenom Prenom de l’élève

08 Niveau_eleve Le niveau de l’élève

09 Date_renseignement La date du renseignement

10 Contenu_renseignement Le contenu du renseignement

11 Date-enseignement La date d’enseignement

12 Contenu_enseignement Le contenu d’enseignement

13 Code Le code de l’enseignement

14 Code_avis Le code de l’avis

15 Contenu_avis Le contenu de l’avis

16 Num_fiche Le numéro de la fiche

17 Date_mis_a_jour La date du mise-a-jour

18 Date_consultaion La date de la consultation de la fiche

19 Date_examen La date de l’examen

2. Représentation des classes :

Après la construction du dictionnaire des données, nous avons identifié la liste des classes.
Tableau 23 : Classe Enseignant

Enseignant

Attributs Méthodes

Nom Type Nom

Id_enseignat String Afficher notes examen ()

Nom_enseignant String Fixer date examen(date)

Prénom_enseignan String Exposer element enseignement(contenu-


t rensg)

String Exposer élément


Niveau_enseignant
renseignement(contenu_ensg)

Prendre rendez-vous avec parents(date)

Explorer fiche renseignement (Num_fiche)

Tableau 24 : Classe élève

Élève

Attributs Méthodes

Nom Type

Identifiant String
Nom
Niveau-eleve String

Nom String

Prenom String

Consulter plan d’étude ()

Consulter éléments
d’enseignement ()

Tableau 25 : Classe parent

Parent

Méthodes
Consulter élément de renseignement ()

Prendre rendez-vous (date)

Tableau 26 : Classe fiche de renseignement

Fiche de renseignement

Attributs Méthodes

Nom Type Nom

Num_fiche Int

Date_mis_a_jour Date ExplorerFiche()

Date_consultation Date

Tableau 27 : Classe éléments de renseignement

Éléments de renseignement

Attributs

Nom Type

Date_renseignement Date

Contenu_renseignement Texte
Tableau 28 : Classe éléments d’enseignement

Éléments d’enseignement

Attributs

Nom Type

Code String

Date_enseignement Date

Contenu_enseignement Texte

Tableau 29 : Classe avis libre

Avis libre

Attributs

Nom Type

Code_avis String

Contenu_avis Texte

Tableau 30 : Classe examen

Examen

Attributs

Nom Type

Date_examen Date

Tableau 31 : Classe date

Date

Attributs

Nom Type

Jour Int

Mois Int

Annee Int

3. Diagramme de classe
Un diagramme de classes dans le langage de modélisation unifié (UML) est un type de
diagramme de structure statique qui décrit la structure d'un système en montrant le système
des classes, leurs attributs, les opérations (ou) les méthodes et les relations entre les classes.
[B1]

Ci-dessous, le diagramme de classe de notre système :

Figure 33 : diagramme des classes

La base de données
1. Modèle logique des données
 Définition de MLD

La description conceptuelle par le model objet a permis de représenter le plus fidèlement


possible les réalités de l’univers à informatiser. Mais cette représentation ne peut pas être
directement manipulée et acceptée par un système informatique. Il est donc nécessaire de
passer d’un modèle objet à un modèle plus proche des capacités des systèmes informatiques
Ce modèle est appelé modèle logique

Le modèle logique permet de présenter les données sous forme de structures basées sur la
théorie des relations elle-même construite à partir de la théorie des ensembles. Il fait
aujourd’hui autorité dans l’industrie du moment puisqu’il constitue le bas de nombreux
systèmes et que les architectures permettant d’accéder depuis une station de travail à des
serveurs de données s’appuient en général sur lui.

Pour la conversion du modèle objet (diagramme de classe) en modèle logique (modèle


relationnel) il faut appliquer certaines règles de transformation. [B3]

 Règles de transformations

– Règle 1 :Par définition une classe est traduite en une relation. L’identifiant de la
classe devient la clé primaire de la relation.
– Règle 2 Cardinalité (1..N), (1..1) ou (1..1), (0..1).

Une telle association entraîne l’intégration de l’identifiant de l’entité but de la dépendance


fonctionnelle dans la relation associée à l’entité source de la dépendance fonctionnelle. Cet
identifiant devient clé étrangère dans la relation source, il est marqué par un #.

– Règle 3  : Cardinalité (1..N), (1..N).

Toute association se transformera en relation qui hérite des identifiants des entités
participants à la relation.

– Règle 4  : Cardinalité (M..N).

Toute généralisation/spécialisation se traduira soit en relation soit en dupliquant des données.

2. Modèle logique de données


Enseignant (id_enseignant, nom_enseignant, prénom_enseignant, niveau_enseignent).
Elève (identifiant,nom,prenom,niveau_eleve).
Élément_ renseignement (date_renseignement,contenu_renseignement).
Elément_enseignement (code,date_enseigement, contenu_enseigement).
Examen (date_examen).
Fiche de renseignement (Num_fiche, date_consultation,date-mis-a-jour).
Avis_libre(code_avis,,contenu_avis).
Date (jour,mois,annee).
Conclusion
Dans ce chapitre, nous avons donné une conception détaillée de notre application et nous
avons étudié, implicitement, les deux volets : dynamique (les scénarios possibles) et statique
(les classes).

Dans le prochain chapitre nous allons essayer de suivre cette conception dans le but de
mettre en place le système souhaité.

Chapitre III

RÉALISATION
I. Introduction :

Ce dernier chapitre a pour objet de montrer notre travail développe. Nous allons présenter
l’environnement matériel, logiciel et les techniques utilisées. Ensuite nous allons illustrer
quelques aperçus d’écrans montrant les différentes fonctionnalités mise en place.

II. Environnement de travail :


Afin de bien présenter l’environnement du notre travail nous allons bien décrire chaque
matériel et logiciel de notre travail ainsi que les raisons pour lesquelles nous avons opté
pour cet environnement.

1. Environnement matériel :

Pour la réalisation de notre projet, nous allons disposer du matériel suivant :

- Ordinateur portable HP-G70.


- Caractéristiques :

Figure 34  : Information sur système


2. Environnement logiciel :
 Android Studio :

Android Studio est un environnement de développement pour développer des applications


mobiles Android. Il est basé sur IntelliJ IDEA et utilise le moteur de production « Gradle ». Il
peut être téléchargé sous les systèmes d'exploitation Windows, MacOS, Chrome OS et
Linux16.

Android a été développé par une petite startup achetée ensuite par Google qui a créé un
IDE complet pour la création d'application mobile Android nommé Android Studio, annoncé
lors du Google I/O le 15 mai 2013.

Il est open source et disponible gratuitement, permettant de réaliser des projets sur
différents types de support, tablette ou smartphone.

Principalement utilisé pour éditer des fichiers Java étant le langage d'une application
Android native ainsi que des fichiers de mise en page XML avec la possibilité de visualiser le
rendu et les manipuler en utilisant une interface graphique.[N1]

Le langage JAVA est le langage de base pour développer une application Android, une
application Android est composée d’une l’activité « Activity ». Une activité représente
l’interface que nous voyions sur l’écran et le code JAVA qui alimente cette interface et
composée des interfaces « Fragment ». Un fragment est similaire à une activité sauf qu’il est
plus léger. Il est conseillé de toujours utiliser un fragment si c’est possible.

Figure 35 : Interface Android Studio


 StarUml :

StarUML est un logiciel de modélisation et conception orienté objet UML qui facilite le
travail pour la représentation de différents diagrammes [N2]
Figure 36 : Interface StarUml

 Xampp :

XAMPP est un ensemble de logiciels laisse lieu pour mettre en place un serveur Web
local, un serveur FTP et un serveur de messagerie électronique.

X pour cross-plateforme (LAMPP pour Linux, WAMPP pour Windows, ...)

A pour Apache

M pour MySQL

P pour PHP

P pour Perl. [N3]

Figure 37 : Lugo xampp


III. Choix techniques  :

Choix des langages :


Pour développer une application Android il est nécessaire de maitriser le langage JAVA et il faut
aussi avoir une idée sur le langage XML :

 XML : Le langage XML (eXtended Markup Language) est un format général de

documents orienté texte. Une des idées directrices de XML est la séparation entre
contenu et présentation. Il faut bien distinguer le contenu d'un document et la
présentation qui en est donnée. De nombreuses technologies se sont développées
autour de XML et enrichissent ainsi son environnement. Le langage XML dérive de
SGML (Standard Generalized Markup Language) et de HTML (HyperText Markup
Language). Comme ces derniers, il s'agit d'un langage orienté texte et formé de
balises qui permettent d'organiser les données de manière structurée.. [B4]

Figure 39 : Lugo XML

 Java :Java est un langage de programmation orienté objet et une plate-forme informatique


qui ont été créés par Sun Microsystems en 1995. Beaucoup d'applications et de sites Web ne
fonctionne pas si Java n'est pas installé et leur nombre ne cesse de croître chaque jour. Java
est rapide, sécurisé et fiable. Des ordinateurs portables aux centres de données, des consoles
de jeux aux superordinateurs scientifiques, des téléphones portables à Internet, la technologie
Java est présente sur tous les fronts. [N4]
Figure 39 : Lugo JAVA

IV. Test et validation : 

En informatique, un test désigne une procédure de vérification partielle d’un système


informatique. Le but en est de trouver un nombre maximum de comportement
problématiques de l’application, car il est impossible de prouver qu’une application
fonctionne bien dans tous les cas. Plus on trouve d’erreurs, plus il ‘y a de chance qu’il y ait
d’avantage d’erreur dans le composant application visée. Les tests de vérification ou de
validation visent à s’assurer que ce système réagit de la façon prévue par ses concepteurs
ou est conforme aux attentes d’utilisateur l’ayant commandé respectivement. Pour vérifier
la validation de notre application nous avons la mettre en ligne (héberger) et tester le
fonctionnement de ses composants.

V. Interface de notre application :


Interface application web
Figure 39 : Page de connexion d’administrateur personnel ou enseignent

Figure 39 : Page de connexion élève - parent


Figure 40 : accueil application tableaux d’administration de systèmes

Figure 41 : Page nouveaux élève


Figure 41 : Page liste élève par classe élève

Interface application mobile


 .
VI. Conclusion  :
Dans ce chapitre, nous avons étudié les différents outils qu’on a utilisé dans le
développement de notre application telque les logiciels, les langages et les
techniques. Enfin, une implémentation des imprimés écran de notre application.
Conclusion général

Ce projet de fin d'études vise à la réalisation d’une application Android pour les écoles
primaires.

Nous avons essayé de trouver une solution afin de résoudre les problèmes de gestion des
informations d’une façon simple rapide et dynamique toute en se basant sur les exemples des
applications similaires précédentes de la nôtre.

Ce projet est une grande opportunité pour nous afin de pratiquer tous qu’on a appris et acquis
durant les années d’études universitaires.

Il nous a donné l’occasion de profiter d’une bonne expérience professionnelle et


d’approfondir nos connaissances de point de vue conception avec UML et développement
avec Android.

L’application peut être considérée comme une solution satisfaisante pour les besoins actuels
et pour bien dépasser les défauts de la méthode classique de la gestion manuelle des
informations et faciliter la communication des âgées avec le monde extérieur.

Notre souhait est que cette application peut aider le maximum possible les écoles primaires
présentés par nos chers enseignants dont nous serons toujours reconnaissants pour eux et pour
toutes leurs aides tout au long nos parcours non seulement dans la classe mais par leurs
réflexions dans le quotidien de vie.

Cette dernière peut ne pas s’arrêter à ce stade, c’est une première version dont on peut
l’améliorer dans des futurs travaux.

« Tu peux tout accomplir dans la vie si tu as le courage de le rêver, l’intelligence d’en faire
un projet réaliste, et la volonté de voir ce projet mené à bien. » Sidney A. Friedman
Bibliographie

[B1] : Cours conception LFSI2.

[B2] : Merise et UML Copyright © Joseph Gabay, 3è meédition 1999.

[B3] : Cours base de données LFSI2.

[B4] : cours XMLCopyright © 2007-2014 Olivier Carton (université paris)


Néographie
[N1] : https://fr.wikipedia.org/wiki/Android_Studio(consulté le 10/06/2020)

 :
[N2] https://fr.wikipedia.org/wiki/StarUML (consultée le 15/06/2020)

[N3] :https://services.montefiore.uliege.be/verif/cours/bd/repet2014/tp7_slides.pdf(consulté le
05/05/2020)

[N4] :https://www.java.com/fr/download/faq/whatis_java.xml(consulté le01/05/2020)
Annexe A

Modélisation UML
La modélisation consiste à créer une représentation simplifiée d'un
problème :le modèle.

Grâce au modèle il est possible de représenter simplement un problème, un


concept et le simuler. La modélisation comporte deux composantes :

 L'analyse, c'est-à-dire l'étude du problème


 La conception, soit la mise au point d'une solution au problème

Le modèle constitue ainsi une représentation possible du système pour un point


de vue donné.

Le métamodèle UML fournit une panoplie d'outils permettant de représenter


l'ensemble des éléments du monde objet (classes, objets, ...) ainsi que les liens
qui les relie.

Toutefois, étant donné qu'une seule représentation est trop subjective, UML
fournit un moyen astucieux permettant de représenter diverses projections
d'une même représentation grâce aux vues.

UNE VUE EST CONSTITUÉE D'UN OU PLUSIEURS DIAGRAMMES. ON DISTINGUE DEUX


TYPES DE VUES  :

Les vues statiques :


 diagrammes de cas d'utilisation.

 diagrammes de classes.

Les vues dynamiques :

 Diagrammes de séquence
 Diagrammes de collaboration
 Diagrammes d'états-transitions
‫ وهو يشمل تصميم‬.‫أجري هذا العمل في إطار مشروع نهاية الدراسة في كلية العلوم بقفصه‬
‫تطبيق الكتروني لمدرسة علي بن صادق‬.

Ce travail a été effectué dans le cadre d’un projet de fin d’année


réalisé au FSGF.
Il ulistre la conception et la réalisation d’une application android pour
l’ecole primaire « Mouhamed Brahmi » offrant des services
administratives.

This work has been done in the setting of a project of year end
achieved to the FSGF.

it includes the conception and the configuration of an android


applicationof « Mouhamed Brahmi »school offering some
administrative services.

Vous aimerez peut-être aussi