REPUBLIQUE DE COTE D'NOIRE

Union-Discipline-Travail

,• Ministère de l'Enseignement Supérieur et de la Recherche Scientifique

Université Nangui Abrogoua

--------------------------·
Unité de Formation et de Recherche des Sciences Fondamentales et Appliquées

2016 - 2017

C'nit• de FonN1ttion •t de
l'="IVl:11.,.ITE
NANGUIABROGOUA llttherThe "·· s.1.-,
Fo1tdnm•ntnl•• •I Appli9"é••

Thème:

CONCEPTION ET REALISATION D'UNE APPLICATION DE

GESTION DES ELEVES ET DE LA DIPLOMATION

MEMOIRE POUR L'OBTENTION DU DIPLOME DE MASTER EN INFORMATIQUE

OPTION MÉTHODES INFORMATIQUES APPLIQUÉES A LA GESTION DES ENTREPRISES
(MIAGE)
Présenté par
BEDA AMANDINE SIDONIE

Le jury Directeur de mémoire :

M. AKA Boko, Professeur titulaire, UNA
Président du jury : Co-directeur:
Membre: Mr ZEZE Djédjé Sylvain, Maître-Assistant, UNA
Membre
Membre:

•
Dédicaces

Je dédie ce travail
A mon père Beda Assi.
A ma mère Atsè N'din Leontine épouse Beda.
A mon grand-frère Tah David Paul.
A ma petite sœur Beda Laurel.
A mon chéri Tian Bi Yannick pour son soutient inconditionnel.
A tous les membres de ma famille et à mes amis.

Pour tous vos sacrifices, nul mot ne saura exprimer mon amour envers vous. Que Dieu vous
protège et vous accorde une longue vie.
Remerciement

Je remercie avant tout le bon Dieu de m'avoir donné la volonté de finir ce mémoire.

Ce travail a pu voir le jour avec énormément d'aide et encouragement des personnes autour
de moi. Ce court remerciement ne sera pas suffisant pour récompenser leurs efforts mais tout
de même ...

Mes remerciements vont à l'endroit de tous ceux qui m'ont aidée et soutenue dans montra-
vail, en particulier au responsable de la filière MIAGE de l'UFR SFA, le docteur EDI Hilaire,
à mon directeur de mémoire le docteur ZEZE Djédjé Sylvain pour sa gentillesse, ses précieux
conseils et pour sa patience, à Gninatin Coulibaly et Beugré Loulou pour leur disponibilité et
leur soutien.

Je tiens aussi à remercier les membres du jury qui ont accepté d'examiner ce mémoire.

Je remercie également le professeur BOA David pour son encouragement continu et pour
ses conseils avisés.

Toute ma reconnaissance est adressée à mes parents, mes frères et mes sœurs pour leurs
sacrifices et leurs soutiens durant ces années d'études. Ce n'est que grâce à eux que tout cela a
été rendu possible.

Mes remerciements vont enfin à l'endroit de toute personne qui a contribué de près ou de
loin à l'élaboration de ce travail.
Résumé

Dans le cadre de l'obtention de notre diplôme de MASTER en Méthodes Informatiques

appliquées à la gestion et à l'économie (MIAGE) à l'Université Nangui Abrogoua, nous avons
été appelés à réaliser un projet de fin d'études afin de clôturer notre formation du second cycle
universitaire. C'est ainsi que j'ai eu l'occasion d'approfondir mes connaissances théoriques par
la conception et la réalisation d'une application de gestion des élèves et de la diplomation. Cette
application a été conçue dans le dessein de gérer les notes et les bulletins des élèves afin de
faciliter les tâches aux établissements secondaires. Ainsi, son principal objectif est d'établir les
moyennes et de générer automatiquement les bulletins de chaque élève.
Pour atteindre cet objectif, nous avons créé une application web, modélisée à partir du
langage UML (langage de modélisation unifié). Le langage de programmation choisi est le
langage PHP (Hypertext Preprocessor) et le système de gestion de base de données (SGBD)
est MySQL. Il faut noter que l'outil Umlet nous a été utile pour dessiner et gérer les différents
diagrammes UML. Ce travail a été éffectué sous le turorat du docteur ZEZE Djêdjé Sylvain.
Abstract

As part of our master's degree in Computer Methods applied to Management and Economies
(MIAGE) at the University Nangui Abrogoua, we were called to carry out a final project in order
to close our second cycle training. This is how I had the opportunity to deepen my theoretical
knowledge through the design and implementation of a student management application and
graduation. This application has been designed with the purpose of managing students' notes
and ballots to facilitate tasks at secondary schools. Thus, its main objective is to establish
averages and automatically generate the bulletin of each student.
To achieve this goal, we created a web application, modeled from UML ( unified modeling
language). The programming language chosen is the PHP (Hypertext Preprocessor) language
and the database management system (DBMS) is MySQL. It should be noted that the Umlet
tool was useful for us to draw and manage the different UML diagrams. This work was clone
under the turorat of Dr. ZEZE Djedje Sylvain.
Table des matières

Résumé 2

Abstract 3

Liste des figures ii

Liste des abréviations 1

Introduction 1

1 CONTEXTE GENERAL DU PROJET 3

1.1 Présentation de la structure d'accueil 4
1.1.1 Cadre du stage . 4
1.1.2 Objectif du Xerya IT School . 5
1.1.3 Organigramme de l'institut XITS 5
1.2 Cadre général du projet . 5
1.2.1 Contexte général du projet . 5
1.2.2 Présentation générale du projet 6
1.2.3 Objectif du projet . 6
1.3 Conclusion partielle . . . . . . ..... 7

2 ETUDE FONCTIONNELLE ET TECHNIQUE 8

2.1 Spécification des besoins . . . . . . . . . . . . . . 9
2.1.1 Spécification des besoins fonctionnels ... 9
2.1.2 Spécification des besoins non fonctionnels 9
2.2 Choix méthodologique . 10
2.2.1 Le langage UML . 10
2.2.2 La technologie orientée objet . 12
2.2.3 L'architecture MVC (Model-View-Controller 13
2.2.4 Framework Laravel 15
2.3 Conclusion partielle . . . . . . . . . . . . . . . . . . 16

3 ANALYSE ET CONCEPTION 17
3.1 Modélisation en langage UML . . . . . . 18
3.1.1 Identification des acteurs ..... 18
3.1.2 Le diagramme de cas d'utilisation 18
3.2 Mise en place de la base de donnée ... 27
3.2.1 Modèle Physique de Données .. 27
3.2.2 Description des classes métiers du système 29
3.3 Conclusion Partielle . . . . . . . . . . . . . . . . . 30

5
4 IMPLEMENTATION ET RESULTATS 31
4.1 Plate forme de développement . . . . . . 32
4.1.1 SGBD MariaDB ......... 32
4.1.2 Le langage de développement PHP 32
4.1.3 Serveur apache ....... 33
4.1.4 Le modèle MVC de Laravel 33
4.2 Les interfaces de l'application 34
4.2.1 Authentification . 34
4.2.2 Menu Principal . 34
4.2.3 Administration 35
4.2.4 Gestion des notes 36
4.2.5 Relevés de notes . 38
4.3 Conclusion Partielle . 40

Conclusion général 40

Bibliographie 42
Table des figures

1.1 Plate-forme du XITS . . . . . . . 4

1.2 Organigramme de l'institut XITS. 5

2.1 les vues du langage UML. . . . . 11

2.2 les différents diagrammes UML. . 13
2.3 Interactions entre le modèle, la vue et le contrôleur. 15

3.1 Diagramme de cas d'utilisation représentant un logiciel de partage de fichiers 19

3.2 Exemple de diagramme de cas d'utilisation. 19
3.3 Relations entre acteurs. . . . . . . . . . . . . . . . 21
3.4 Diagramme de cas d'utilisation générale. . . . . . 22
3.5 Diagramme de cas d'utilisation « s'authentifier » . 23
3.6 Diagramme de cas d'utilisation « paramétrage » . 23
3. 7 Diagramme de cas d'utilisation de « gestion des enseignants » 24
3.8 Diagramme de cas d'utilisation de « gestion des notes » . . . . 25
3.9 Diagramme de cas d'utilisation de « Gestion des élèves » . . . 26
3.10 Diagramme de cas d'utilisation de « Gestion des utilisateurs» 26
3.11 Modèles Physiques des Données . . . 28

4.1 Principe de fonctionnement de PHP 32

4.2 Structure MVC de Laravel 33
4.3 Interface d'authentification 34
4.4 Menu Principal . . . . . . . 35
4. 5 Interface "Administration 11 35
4.6 Interface 1 "Gestion des notes" 36
4. 7 Interface 2 "Gestion des notes" 36
4.8 Interface "Selectionner classe" . 37
4.9 Interface "moyennes des élèves" 37
4.10 Interface "Relevés de notes" .. 38
4.11 Interface 11 Moyennes des élèves inscrits" 38
4.12 Interface "Fiche d'un élève" 39
4.13 Interface "Générer relevé" . 39

ii
Liste des abréviations

CSS : langage informatique qui décrit la présentation des documents HTML et XML.

HTML : HyperText Markup Language, est le format de données conçu pour représenter
les pages web. C'est un langage de balisage permettant d'écrire de l'hypertexte

HTTP : Hypertext Transfer Protocol en français protocole de transfert hypertexte

MPD : Modèle Physique des Données

PHP : Hypertext Preprocessor, est un langage de programmation libre, principalement uti-

lisé pour produire des pages Web dynamiques via un serveur HTTP

POO : Programmation Orientée Objet

SG BD : Système de Gestion de Base de Données

SQL : Structured Query Language, en français langage de requête structurée est un langage
informatique normalisé servant à exploiter des bases de données relationnelles.

UML : U nified Modeling Language en français Langage de Modelisation Unifié

XML : L'Extensible Markup Language (langage de balisage extensible en français)

1
Introduction

ous évoluons dans une société de savoir où la compétence numenque est devenue une
valeur de base. Les technologies de l'information et de la communication (TIC) constituent
désormais des ressources importantes, voire incontournables dans le domaine éducatif.
Le défi de l'intégration des TIC consiste à exploiter efficacement ces techniques afin qu'elles
servent les intérêts du système éducatif.
L'essor des espaces numériques et des outils ne traduit pas simplement une modernisa-
tion technologique des établissements pédagogiques, il conduit également à des transformations
profondes de son organisation, de son environnement.
Le principal objectif de ce projet est de mettre en place un nouveau système de gestion des
élèves facilitant la saisie et le partage des informations.
Notre application consiste à établir un travail complet dédié aux établissements scolaires à
savoir : enregistrer les notes, calculer les moyennes, établir des bulletins et états à imprimer.
Le présent rapport comporte quatre chapitres.
Le premier chapitre présente le contexte général du projet.
Le second, intitulé « Étude technique et fonctionnelle » définit le projet ainsi que le travail
demandé.
Ensuite, le troisième chapitre « Analyse et conception » détaille les besoins fonctionnels et
les besoins non fonctionnels nécessaire au développement du système.
Et enfin un dernier chapitre, intitulé « Implémentation et résultat » est consacré à la concep-
tion des données et des traitements, à l'environnement de développement, à l'architecture de
déploiement ainsi que les interfaces réalisées.
Ce rapport sera clôturé par une conclusion dans laquelle je présenterai les acquis retenus au
cours de ce projet ainsi que les perspectives à envisager en vue d'améliorer ses fonctionnalités.

2
Chapitre 1

CONTEXTE GENERAL DU PROJET

3
1.1 Présentation de la structure d'accueil
1.1.1 Cadre du stage
Mon stage s'est déroulé au sein de l'entreprise Xerya. Xerya était une entreprise de formation
technologique qui met à la disposition de ses clients des applications ITEC conçues selon leurs
attentes. Fondée en 2007 à Paris, cette institution a ouvert une filiale à Abidjan en 2013.
Pour son expansion en Côte d'Ivoire, Xerya est en train de développer une plate-forme de
formation en informatique et de gestion des établissements du secondaire appeler Xerya IT
school (XITS). Elle comprend plusieurs modules qui sont :

• L'intranet.

• Les sites web.

• Les emails.

• Les projets et documentations sur les matières.

• La préparation des examens.

• Les documents administratifs.

• La gestion des contenus IT.

• La bibliothèque virtuelle.

• La gestion des élèves et de la diplomation.

Mon stage a porté sur la gestion des élèves et de la diplomation.

erya

-
,/ ---
&wto;•~..com ,.GETI C(l0..l7MS 09U9ms V,7,lll f2/ll6lOJS)

FIGURE 1.1 - Plate-forme du XITS

4
1.1.2 Objectif du Xerya IT School
Les principaux objectifs Du Xerya IT School sont les suivants :

• Effectuer des formations IT.

• Produire et diffuser des connaissances technologiques dans de nombreux domaines.

• Concevoir des innovations et des savoir-faire pour la société à savoir des plates-formes de
gestions.

1.1.3 Organigramme de l'institut XITS

Le XITS est constitué d'un directeur général, d'un directeur des opérations, d'un secrétariat
de direction, de commerciaux et de consultants. Nous avons entre autres dix (10) enseignants,
cinq (5) consultants et dix (10) commerciaux ainsi que quelques stagiaires.

xrrs

Direction Générale et Commerciale

Direction des opérations Sécrétar1at de direction

Consultants Enseignants Commerciaux Stagiaires

FIGURE 1.2 - Organigramme de l'institut XITS.

1.2 Cadre général du projet

1.2.1 Contexte général du projet
Le ministère de l'éducation nationale demande des rapports périodiques aux établissements,
ce sont des rapports trimestriels, semestriels ou annuels établis par les enseignants, les éduca-
teurs ou l'administrateur. Ils comprennent le nom, les prénoms, la date de naissance, le matricule
ainsi que les moyennes respectives des élèves dans différentes matières. Ce rapport se fait à en-
viron une à deux semaines de la fin du trimestre /semestre. les responsables ne disposent pas
d'assez de temps pour l'établir. Cette tâche est assurée manuellement et elle n'est pas sécurisée.
Aussi, imaginons le nombre important de rapports que nos différents établissements font
parvenir au ministère sachant que la gestion des moyennes par élève fait intervenir la gestion
des bulletins et l'établissement des diplômes. Une mauvaise organisation de ces documents et
on assisterait à une catastrophe.
On observe également que l'ensemble des activités de l'établissement est géré par traite-
ment manuel tout en utilisant des supports papiers. La gestion du papier ne rassure pas car il

5
est vulnérable (perte de document, dégradation du papier, difficulté de classement, recherche
difficile .... ) .
Le contexte général nous permet d'affirmer que nos établissements manquent de système
optimisé pour organiser et gérer leurs données.

1.2.2 Présentation générale du projet

Ce projet de fin d'études s'inscrit dans le cadre d'une solution pour la gestion des élèves et
de la diplomation. Cette solution doit être adaptée au système éducatif de nos lycées et collèges

La répartition des classes, des élèves, des matières, des départements, des filières, des spé-
cialités, le calcul des moyennes et l'établissement des résultats se faisant de manière semi-
automatique.
Nos établissements ne disposent d'aucune base de données permettant l'enregistrement et
la consultation des résultats, statistiques de réussites, historiques des promotions de l'établis-
sement. Les notes sont traitées manuellement, le traitement des relevés de notes prend assez de
temps. Ces méthodes constituent un risque car un simple mélange de documents pourrait être
fatal.
Une application étant définie comme un programme (ou un ensemble logiciel) directement
utilisé par l'utilisateur pour réaliser une tâche, ou un ensemble de tâches élémentaires d'un
même domaine ou formant un tout, sa conception dans notre cas consisterait à mettre en place
une application web pour la gestion des écoles.

1.2.3 Objectif du projet

L'objectif de ce projet est de remédier aux défaillances déjà évoquées. Pour cela, nous
proposons une solution qui nous a paru adéquate. Nous allons développer une application de
gestion des élèves qui comprendra en outre un volet pour la gestion des résultats et des bulletins
scolaires. Cette application permettra de :

• enregistrer les élèves.

• Saisir des notes.

• Calculer la moyenne par matière et par module pour chaque élève.

• Calculer la moyenne générale et le résultat de chaque élève.

• Imprimer les relevés de notes.

• Gérer les utilisateurs ( enseignants, administrateurs, élèves).

6
1.3 Conclusion partielle
En somme, nous avons présenté succinctement la structure Xerya, ensuite le contexte gé-
néral du projet ainsi que ses objectifs ce qui nous a permi de recenser toutes les informations
nécessaires et indispensables dans la réalisation de notre projet.Ces informations nous permet-
tront de cerner les principaux objectifs et de choisir la technique à adopter, le contexte dans
lequel nous réalisons ce projet et la solution retenue pour atteindre notre objectif. Nous pouvons
dès lors passer à la deuxième partie qui est l'étude technique et fonctionnelle de notre projet.

7
Chapitre 2

ETUDE FONCTIONNELLE ET
TECHNIQUE

Dans ce chapitre, nous allons décrire la méthodologie de conception et les besoins spécifiques,
par la suite nous allons les analyser en utilisant le formalisme UML.

8
2.1 Spécification des besoins
La spécification de besoins constitue la phase de départ de toute application à développer
dans laquelle nous allons identifier les différents besoins. Elle doit décrire sans ambiguïté le
logiciel à développer. Elle est constituée d'un ensemble de documents et de modèles.
Toutes les personnes impliquées dans le projet doivent avoir accès à la spécification des
besoins. Nous distinguons les besoins fonctionnels qui présentent les fonctionnalités attendues
de notre application des besoins non fonctionnels qui quant à eux permettent d'éviter le déve-
loppement d'une application non satisfaisante.

2.1.1 Spécification des besoins fonctionnels

Les besoins fonctionnels ou besoin métiers représentent les actions que le système doit
exécuter, il ne devient opérationnel que s'il les satisfait. Ils expriment une action que doit
éffectuer le système en réponse à une demande (sorties qui sont produites pour un ensemble
donné d'entrées).
L'application que nous allons développer devra regrouper les fonctionnalités qui permettront
à l'utilisateur de :

• Gérer les élèves

• Gérer les classes

• Gérer les matières

• Gérer les enseignants

• Gérer les éducateurs

• Entrer les notes des élèves des matières correspondantes

• Calculer les moyennes des élèves dans différentes matières

• Générer les bulletins

• Imprimer les bulletins

2.1.2 Spécification des besoins non fonctionnels

Les besoins non fonctionnels sont des exigences qui ne concernent pas spécifiquement le
comportement du système mais plutôt ils identifient les contraintes internes et externes du
système. Les principaux besoins non fonctionnels de notre application sont les suivants :

• Besoins de sécurité
Ils définissent les niveaux d'accès possibles au système pour les utilisateurs. Dans notre
cas, cette application doit avoir un niveau de sécurité assez élevé, les comptes des utilisa-
teurs devront être sécurisés par des mots de passe. Ces mots de passe seront individuels
et devront respecter certaines conditions (la longueur du code; le code système, l'expi-
ration de session, etc.). Les besoins de sécurités sont satisfaits par Laravel qui utilise un
algorithme de cryptage évolué.

9
 • Besoins de disponibilité
Ils concernent le niveau de disponibilité qui doit être explicitement défini pour les appli-
cations critiques (Exemple : exigence de disponibilité 24h/24, 7j/7 sauf période de main-
tenance, à spécifier). Cette application devra fonctionner de manière efficace et ceux, sans
défaillance. Les utilisateurs pourront compter sur sa fiabilité. Ce besoin de disponibilité
est satisfait grâce à l'hebergeur.

• Besoins de performance
Ils décrivent les performances d'exécution du système, généralement en matière de temps
de réponse (l'exemple d'une application Web), temps de chargement d'une page: le char-
gement d'une page Web dans le navigateur ne devrait pas prendre plus de 15 secondes
en condition normale. Cette application devra répondre aux exigences des utilisateurs de
façon optimale c'est-à-dire effectuer des opérations dans un laps de temps très court. Ce
besoin est garanti par le framework.

• Besoins de portabilité
Cette application sera multiplate-forme. Elle fonctionnera sur tous les systèmes d'exploi-
tation et tout type de terminal puisqu'il s'agit d'une application web, elle sera disponible
sur tout support où il existe un naviguateur. Aussi, cette application sera responsive c'est-
à-dire qu'elle s'adaptera à la taille de l'écran. Cette responsivité est assuré par bootstrap.
On peut affirmer que ce besoin est déjà satisfait par la définition d'une applacation web.

• Une solution ouverte et évoluée

L'application pourra être améliorée par l'ajout d'autres modules pour garantir sa sou-
plesse, l'évolutivité et l'ouverture de la solution. Xerya IT School est un ensemble d'ap-
plication constituée en module, chaque module représente une application à part entière.
Mon stage ayant porté sur un module de ce ensemble, on peut affirmer que notre appli-
cation reponds au critère d'une solution ouverte et évoluée.

2. 2 Choix méthodologique
Pour mener à bien notre projet, nos choix se sont portés sur les méthodologies et technologies
suivantes :

• Le langage UML.

• La technologie Orienté Objet.

• Le modèle MVC.

• Framework Laravel

2.2.1 Le langage UML

Uml (Unified modeling Langage) est un langage de modélisation unifié qui permet de mo-
déliser une application logicielle d'une façon standard dans le cadre de conception orientée
objet.
UML permet de couvrir le cycle de vie d'un logiciel depuis la spécification des besoins
jusqu'au codage en offrant plusieurs moyens de description et de modélisation des acteurs et

10
des utilisations du système, du comportement des objets, du flot de contrôles internes aux
opérations, des composants d'implémentation et leurs relations, de la structure matérielle et de
la distribution des objets et des composants indépendamment des techniques d'implémentation
et peut-être mise à jour selon les besoins.

2.2.1.1 Les différentes vue du langage UML

Une façon de mettre en œuvre UML est de considérer différentes vues qui peuvent se su-
perposer pour collaborer à la définition du système. Ainsi on a :

• La vue des cas d'utilisation : c'est la description du modèle vu par les acteurs du
système. Elle correspond aux besoins attendus par chaque acteur (c'est le QUOI et le
QUI).

• La vue logique : c'est la définition du système vu de l'intérieur. Elle explique comment

satisfaire les besoins des acteurs ( c'est le COMMENT).

• La vue d'implémentation : cette vue définit les dépendances entre les modules.

• La vue des processus : c'est la vue temporelle et technique, qui met en œuvre les
notions de tâches concurrentes, stimuli, contrôle, synchronisation, etc.

• La vue de déploiement : cette vue décrit la position géographique et l'architecture

physique de chaque élément du système (c'est le OÙ).
Ci-dessous une figure qui représente ces différentes vues :

Utilisateur final Pro grammeurs

Fonctionnalité Gestion du logiciel

Vue
Vue logique
.-J..---.J....d ' imp 1 ément ati on

Analystes/Testeurs
Comportement

Vue des Vue de

processus déploiement

Intégrateurs système Ingénieurs système

Performance Topologie du système
Capacité à grandir Livraison, installation
Débit d'information Communication

FIGURE 2.1 - les vues du langage UML.

11
2.2.1.2 Les principaux diagrammes UML
On distingue 9 principaux diagrammes UML qui sont dépendants hiérarchiquement et qui
se complètent, de façon à permettre la modélisation d'un projet tout au long de son cycle de
vie. On distingue :

• Le diagramme de cas d'utilisation qui représente les fonctions du système du point

de vue de l'utilisateur ;

• Le diagramme d'objets qui représente les objets et leurs relations;

• Le diagramme de classes qui représente la structure statique en termes de classes et

de relations ;
• Le diagramme de composants qui représente les composants physiques d'une appli-
cation;
• Le diagramme de déploiement qui décrit le déploiement des composants sur les dis-
positifs matériels;

• Le diagramme de collaboration qui est une représentation spatiale des objets, des
liens et des interactions ;

• Le diagramme de séquence qui représente temporellement les objets et leurs interac-

tions;

• Le diagramme d'états-transition qui décrit le comportement d'une classe d'objet en

termes d'états ;

• Le diagramme d'activités montre les enchaînements des activités d'un cas d'utilisation
ou d'une opération.

Ces diagrammes sont regroupés dans la figure ci-après :

2.2.2 La technologie orientée objet

La programmation orientée objet (POO), ou programmation par objet, est un paradigme
de programmation informatique, Il consiste en la définition et l'interaction de briques logicielles
appelées objets; un objet représente un concept, une idée ou toute entité du monde physique,
comme une voiture, une personne ou encore une page d'un livre. Il possède une structure interne
et un comportement, et il sait interagir avec ses pairs. Il s'agit donc de représenter ces objets
et leurs relations ;
L'interaction entre les objets via leurs relations permet de concevoir et réaliser les fonc-
tionnalités attendues, de mieux résoudre le ou les problèmes. Dès lors, l'étape de modélisation
revêt une importance majeure et nécessaire pour la POO. C'est elle qui permet de transcrire
les éléments du réel sous forme virtuelle.
Orthogonalement à la programmation par objet, afin de faciliter le processus d'élaboration
d'un programme, existent des méthodologies de développement logiciel objet dont la plus connue
est le Unified Software Development Process (UP) qui utilisent des langages de modélisation
tels que le Unified Modeling Language (UML). Même s'il est possible de concevoir par objets
une application informatique sans utiliser des outils logiciels dédiés, ces derniers facilitent la
conception, la maintenance, et la productivité.
On en distingue plusieurs sortes :

12
 Diagramme,s

Cas Classas Etats .• Déploiement

d'utilisation Transmons

Obëets Séquences Collaboration Composants

FIGURE 2.2 - les différents diagrammes UML.

• les langages de programmation (Java, YB.NET, Vala, Objective C, Eiffel, Python, Ruby,
Ada, PHP, Smalltalk, LOGO, AS3, Haxe ... );
• les outils de modélisation qui permettent de concevoir sous forme de schémas semi-formels
la structure d'un programme (Objecteering, UMLDraw, Rhapsody, DBDesigner. .. );
• les bus distribués (DCOM, CORBA, RMI, Pyro ... ) ;
• les ateliers de génie logiciel ou AGL (Visual Studio pour des langages Dotnet, NetBeans
ou Eclipse pour le langage Java).
• La technologie objet est la voie la plus prometteuse pour déployer des systèmes basés sur
des composants qui peuvent être adaptés et changés sans avoir à examiner la totalité du
code.

2.2.3 L'architecture MVC (Model-View-Controller

L'architecture Modèle/Vue/Contrôleur (MVC) est une façon d'organiser une interface gra-
phique d'un programme. Elle consiste à distinguer trois entités distinctes qui sont, le modèle,
la vue et le contrôleur ayant chacun un rôle précis dans l'interface.
L'organisation globale d'une interface graphique est souvent délicate. Bien que la façon
MVC d'organiser une interface ne soit pas la solution miracle, elle fournit souvent une première
approche qui peut ensuite être adaptée. Elle offre aussi un cadre pour structurer une application.
Dans l'architecture MVC, les rôles des trois entités sont les suivants.
• Modèle : données ( accès et mise à jour)
• Vue : interface utilisateur ( entrées et sorties)
• Contrôleur : gestion des événements et synchronisation

13
2.2.3.1 Rôle du modèle
Le modèle contient les données manipulées par le programme. Il assure la gestion de ces
données et garantit leur intégrité. Dans le cas typique d'une base de données, c'est le modèle
qui la contient.
Le modèle offre des méthodes pour mettre à jour ces données (insertion suppression, change-
ment de valeur). Il offre aussi des méthodes pour récupérer ses données. Dans le cas de données
importantes, le modèle peut autoriser plusieurs vues partielles des données. Si par exemple le
programme manipule une base de données pour la gestion des effectifs, le modèle peut avoir des
méthodes pour avoir l'effectif total, toutes les notes des élèves ainsi que leur différent bulletin.

2.2.3.2 Rôle de la vue

La vue fait l'interface avec l'utilisateur. Sa première tâche est d'afficher les données qu'elle a
récupérées auprès du modèle. Sa seconde tâche est de recevoir toutes les actions de l'utilisateur
(clic de souris, sélection d'une entrée, boutons, ... ). Ses différents événements sont envoyés au
contrôleur.
La vue peut aussi donner plusieurs vues, partielles ou non, des mêmes données. Par exemple,
l'application de conversion de bases a un entier comme unique donnée. Ce même entier est affiché
de multiples façons (en texte dans différentes bases, bit par bit avec des boutons à cocher, avec
des curseurs). La vue peut aussi offrir la possibilité à l'utilisateur de changer de vue.

2.2.3.3 Rôle du contrôleur

Le contrôleur est chargé de la synchronisation du modèle et de la vue. Il reçoit tous les
événements de l'utilisateur et enclenche les actions à effectuer. Si une action nécessite un chan-
gement des données, le contrôleur demande la modification des données au modèle et ensuite
avertit la vue que les données ont changé pour que celle-ci se mette à jour. Certains événements
de l'utilisateur ne concernent pas les données mais la vue. Dans ce cas, le contrôleur demande
à la vue de se modifier.
Dans le cas d'une base de données des emplois du temps. Une action de l'utilisateur peut
être l'entrée (saisie) d'un nouveau cours. Le contrôleur ajoute ce cours au modèle et demande
sa prise en compte par la vue. Une action de l'utilisateur peut aussi être de sélectionner une
nouvelle personne pour visualiser tous ses cours. Ceci ne modifie pas la base des cours mais
nécessite simplement que la vue s'adapte et offre à l'utilisateur une vision des cours de cette
personne.
Le contrôleur est souvent scindé en plusieurs parties dont chacune reçoit les événements
d'une partie des composants. En effet si un même objet reçoit les événements de tous les com-
posants, il lui faut déterminer quelle est l'origine de chaque événement. Ce tri des événements
peut s'avérer fastidieux et peut conduire à un code pas très élégant (un énorme switch). C'est
pour éviter ce problème que le contrôleur est réparti en plusieurs objets.

2.2.3.4 Les interactions

Les différentes interactions entre le modèle, la vue et le contrôleur sont résumées par le
schéma de la figure suivante.

14
 données
M cx :lè lo v •.•••

sy ne hoh;s.a..1.i on
J.ocx:lif;c.nti on

.n:,iac, .à.jouL·
é"'léne.1.nc,n\s
deus d.o nnéea

Contrôleur

FIGURE 2.3 - Interactions entre le modèle, la vue et le contrôleur.

2.2.4 Framework Laravel

2.2.4.1 Définition d'un framework
En programmation informatique, un framework (appelé aussi cadre applicatif, cadre d'ap-
plications ou encore infrastructure de développement ) désigne un ensemble cohérent de com-
posants logiciels structurels, qui sert à créer les fondations ainsi que les grandes lignes de tout
ou d'une partie d'un logiciel (architecture).
Les frameworks sont conçus et utilisés pour modeler l'architecture des logiciels applicatifs,
des applications web, des middlewares et des composants logiciels. Les frameworks sont acquis
par les informaticiens, puis incorporés dans des logiciels applicatifs mis sur le marché, ils sont
par conséquent rarement achetés et installés séparément par un utilisateur final.

2.2.4.2 Constitution de Laravel

Laravel a été créé par Taylor Otwell en juin 2011. Le référentiel Laravel/laravel présent
sur le site GitHub contient le code source des premières versions de Laravel. A partir de la
cinquième version, le Framework est développé au sein du référentiel Laravel/framework.
En peu de temps, une communauté d'utilisateurs du Framework s'est constituée. Laravel,
initie une nouvelle façon de concevoir un Framework en utilisant ce qui existe de mieux pour
chaque fonctionnalité. Par exemple toute application web a besoin d'un système qui gère les
requêtes HTTP. Plutôt que de réinventer quelque chose, le concepteur de Laravel a tout sim-
plement utilisé celui de Symfony en l'étendant pour créer un système de routage efficace.
En quelque sorte Otwel a fait son marché parmi toutes les bibliothèques disponibles. Laravel
ce n'est pas seulement le regroupement de bibliothèques existantes, c'est aussi de nombreux
composants originaux et surtout une orchestration de tout ça. Laravel est constitué de :
• un système de routage perfectionné (RESTFul et ressources)
• un créateur de requêtes SQL (langage de requête structurée) et un ORM (object-relational
mapping) performants

• un moteur de template efficace

• un système d'authentification pour les connexions
• un système de validation, de pagination, de migration pour les bases de données, d'envoi
d'emails
• un système d'autorisations
• une gestion des sessions ...

15
2.3 Conclusion partielle
L'étude technique et fonctionnelle nous a permis de passer en revue les besoins fonctionnels
et non fonctionnels de notre projet ainsi que les méthodes et technique choisies pour l'élabora-
tion de notre application. Maintenant, nous allons passer à l'analyse et la conception de notre
projet avec le langage UML.

16
Chapitre 3

ANALYSE ET CONCEPTION

Dans ce chapitre, nous allons exprimer les besoins sous forme de diagrammes de cas
d'utilisations.

17
3.1 Modélisation en langage UML
UML (Unified modeling Langage) se définit comme des langages de modélisation graphique
et textuelle destinés à comprendre et décrire des besoins, spécifier, concevoir des solutions et
communiquer des points de vue. Il unifie à la fois les notations et les concepts orientés objet.
UML propose un ensemble de diagrammes, en voici quelques-uns :

3.1.1 Identification des acteurs

Les acteurs sont des entités externes qui interagissent avec le système, comme une personne
humaine ou un robot. Une même personne (ou robot, ... ) peut-être plusieurs acteurs pour un
système, c'est pourquoi les acteurs doivent surtout être décrits par leur rôle, ce rôle décrit les
besoins et les capacités de l'acteur. Un acteur agit sur le système (accès de lecture/écriture).
L'activité du système a pour objectif de satisfaire les besoins de l'acteur. Les acteurs sont repré-
sentés par un pictogramme humanoïde sous-titré par le nom de l'acteur. Dans notre application,
nous avons défini trois acteurs qui sont :

• Elève
Rôle : consulter son relevé de note

• Enseignant
Rôle : gérer les moyennes des élèves, consulter sa fiche de matières

• Administrateur
Rôle : valider les moyennes, générer les bulletins des élèves, gérer les enseignants et les
élèves, gérer les données de base ( école, filières, niveau, classe, élèves, enseignants, ma-
tières ... )

• Administrateur principal
Rôle : gérer les utilisateurs

3.1.2 Le diagramme de cas d'utilisation

Le diagramme de cas d'utilisation a pour but de donner une vision globale sur les interfaces
de notre future application. C'est le premier diagramme UML constitué d'un ensemble d'ac-
teurs qui agit sur des cas d'utilisations et qui décrit sous la forme d'actions et de réactions, le
comportement d'un système du point de vue utilisateur.
Un acteur est un utilisateur qui communique et interagit avec les cas d'utilisation du
système. C'est une entité ayant un comportement comme une personne, système ou une entre-
prise.
Le système fixe les limites en relation avec les acteurs qui l'utilisent (en dehors du système)
et les fonctions qu'il doit fournir (à l'intérieur du système).
Un cas d'utilisation représente un ensemble de séquences d'actions à réaliser par le
système et produisant un résultat observable intéressant pour un acteur particulier représenté
par des ellipses et limité par un rectangle pour représenter le système.

18
3.1.2.1 Relations dans les diagrammes de cas d'utilisation
• Relations entre acteurs et cas d'utilisation

Logkiel de partage de fichier

* «stconaarv»

Internaute Ordinateur connecté

FIGURE 3.1 - Diagramme de cas d'utilisation représentant un logiciel de partage de fichiers

Une relation d'association est chemin de communication entre un acteur et un cas d'utilisation
et est représenté un trait continu. Lorsqu'un acteur peut interagir plusieurs fois avec un cas
d'utilisation, il est possible d'ajouter une multiplicité sur l'association du côté du cas d'utilisa-
tion

• Relations entre cas d'utilisation

Borne interactive d'une banque

--- ---
\
\
\
\ <<include>>
\

Internaute

Condition : si montant> 20€

extension point : vérification_solde

,
, 1 <<include>>

FIGURE 3.2 - Exemple de diagramme de cas d'utilisation.

Il existe principalement deux types de relations :

Les dépendances stéréotypées, qui sont explicitées par un stéréotype (les plus utilisés sont
l'inclusion et l'extension) et la généralisation/spécialisation.

19
 Une dépendance se représente par une flèche avec un trait pointillé (voir figure ci-dessus).
Si le cas A inclut ou étend le cas B, la flèche est dirigée de A vers B.
Le symbole utilisé pour la généralisation est un flèche avec un trait plein dont la pointe est
un triangle fermé désignant le cas le plus général.

Relation d'inclusion

Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement du

cas B : le cas A dépend de B. Lorsque A est sollicité, B l'est obligatoirement, comme une partie
de A. Cette dépendance est symbolisée par le stéréotype « include ». Par exemple, l'accès aux
informations d'un compte bancaire inclut nécessairement une phase d'authentification avec un
identifiant et un mot de passe ( figure ) .
Les inclusions permettent essentiellement de factoriser une partie de la description d'un cas
d'utilisation qui serait commune à d'autres cas d'utilisation .
Les inclusions permettent également de décomposer un cas complexe en sous-cas plus
simples.

Relation d'extension

La relation d'extension est probablement la plus utile, car elle a une sémantique qui a un sens
du point de vue métier au contraire des deux autres qui sont plus des artifices d'informaticiens.
On dit qu'un cas d'utilisation A étend un cas d'utilisation B lorsque le cas d'utilisation A
peut être appelé au cours de l'exécution du cas d'utilisation B. Exécuter B peut éventuelle-
ment entraîner l'exécution de A : contrairement à l'inclusion, l'extension est optionnelle. Cette
dépendance est symbolisée par le stéréotype « extend ».
L'extension peut intervenir à un point précis du cas étendu. Ce point s'appelle le point
d'extension. Il porte un nom, qui figure dans un compartiment du cas étendu sous la rubrique
point d'extension, et est éventuellement associé à une contrainte indiquant le moment où l'ex-
tension intervient. Une extension est souvent soumise à condition. Graphiquement, la condition
est exprimée sous la forme d'une note. La figure 3.2 présente l'exemple d'une banque où la
vérification du solde du compte n'intervient que si la demande de retrait dépasse 20 euros.

Relation de généralisation

Un cas A est une généralisation d'un cas B si B est un cas particulier de A. Dans la figure
3.2, la consultation d'un compte via Internet est un cas particulier de la consultation. Cette
relation de généralisation/spécialisation est présente dans la plupart des diagrammes UML et
se traduit par le concept d'héritage dans les langages orientés objet.

20
 • Relations entre acteurs

La seule relation possible entre deux acteurs est la généralisation : un acteur A est une
généralisation d'un acteur B si l'acteur A peut être substitué par l'acteur B. Dans ce cas, tous
les cas d'utilisation accessibles à A le sont aussi à B, mais l'inverse n'est pas vrai.
Le symbole utilisé pour la généralisation entre acteurs est une flèche avec un trait plein dont
la pointe est un triangle fermé désignant l'acteur le plus général (comme nous l'avons déjà vu
pour la relation de généralisation entre cas d'utilisation).
Par exemple, la figure ci-dessous montre que le directeur des ventes est un préposé aux
commandes avec un pouvoir supplémentaire : en plus de pouvoir passer et suivre une commande,
il peut gérer le stock. Par contre, le préposé aux commandes ne peut pas gérer le stock.

Système de vente par correspondance

A,,
1

Préposé aux
commandes

A
Directeur
des ventes

FIGURE 3.3 - Relations entre acteurs.

3.1.2.2 Le diagramme de cas d'utilisation générale

Chaque usage que les acteurs font du système est représenté par un cas d'utilisation. Chaque
cas d'utilisation représente une fonctionnalité qui leur est offerte afin de produire le résultat
attendu. Ci-après le diagramme de cas d'utilisation général de notre projet :

21
 System

c o n s u lte r tes m o y e n n e s
~~x!_eil<!S!,

''
''
élève
''
' ',
''
entrer les moyennes
' 'i!includes•
'
''
''
''
' ',
~ consulter fiche de m atières
'

enseignant
~
«inc!l!,d e's• /,·, ;1 ,
, I / 1
1
,,,." / I I 1
/ I I 1
valider les moyennes
./«incl)fdes-,' :
I I I I
I I I 1

1
1 /«includes• ,
I / I 1
/ 1 1
génération des buUetlns I / 1
/ ,'«incl~des•
I 1 1
/ ,' 1
:
,'
1
«lnclude$•
1 1 1
I 1 1
, , 1 «lncludes»
1 1 1
1 1 1
1 I 1
1 1
gestion des él~es
1' 11
1 1
1 1
1 1
t 1
1
1
1

paramétrages

administrateur
principal

gérer les utilsateurs

FIGURE 3.4 - Diagramme de cas d'utilisation générale.

3.1.2.3 Description des cas d'utilisation

Les différents cas d'utilisations de notre application ont été décrits dans les tableaux ci-après
en fonction de l'intitulé du cas.

• S'authentifier

Objectif : Permet l'identification de chaque utilisateur lui donnant accès aux fonctionna-
lités propices.

Acteurs principaux : l'administrateur, les enseignants

Pré condition : L'utilisateur dispose d'un compte d'accès au système.

Description : L'utilisateur saisi son identifiant et son mot de passe. Il est reconnu par le
système. Il peut accéder en fonction de son profil utilisateur.

22
 system

s'authentifier

utilisateur

FIGURE 3.5 - Diagramme de cas d'utilisation « s'authentifier »

• Paramétrage

Objectif : Ajouter, modifier et supprimer certaines informations concernant les classes, les
matières, les niveaux et les filières. Permettre la réconduite de toutes les données à la création
d'une nouvelle année universitaire. Permettre également la gestion des utilisateurs de l'appli-
cation.

Acteurs principaux : l'administrateur

Pré condition : l'utilisateur doit être connecté au système

Description : A la création d'une nouvelle année académique, les matières, les classes et
les niveaux de l'année clôturée sont recopier automatiquement pour la nouvelle année. Une
vérification manuelle est faite par le l'administrateur pour reconduire ou supprimer certaines
données qui ne sont pas autorisées pour la nouvelle année. L'administrateur peut créer un
nouveau compte utilisateur, consulter, modifier et supprimer un utilisateur. En plus d'une liste
de tous les classes autorisés pendant une année académique, il a également la possibilité de les
modifier et les supprimer.

System

Administrateur

Gestion des utilisateurs Gestion des classes

FIGURE 3.6 - Diagramme de cas d'utilisation « paramétrage »

23
 • Gestion des enseignants

Objectif :Ajouter, modifier et supprimer un enseignant

Acteurs principaux : l'administrateur

Pré condition :L'utilisateur doit être connecté au système

Description : L'utilisateur dispose d'un formulaire pour créer de nouveaux enseignants.

Sur ce formulaire, il devra remplir les informations nécessaires des enseingnants. L'utilisateur
pourra modifier et supprimer ces informations. En plus d'une liste de tous les enseignants
autorisés pendant une année universitaire, il a également la possibilité de modifier cette liste.

System

1
1
\ « includes»
\

/ \ «e):~nds»
/

/
/ \ ',~
Administrateur I
/«extends»
'1,«extends» ~
I \
I \
/ 1

~ ~

FIGURE 3.7 - Diagramme de cas d'utilisation de « gestion des enseignants»

• Gestion des notes

Objectif :Attribuer des notes aux élèves, calculer leurs moyennes et générer leur relevé de
note. Avoir la possibillité de modifier les notes après reclamation, et ceux avant l'établissement
du bulletin définitif. l'utilisateur peut consulter les notes également.

Acteurs principaux : l'administrateur, les enseignants

Pré condition :L'utilisateur dispose d'un compte d'accès au système.

Description : L'utilisateur clique sur gestion des notes, il dispose de la liste des inscris
pour une année académique rangé par classe et il renseigne les notes respectives de chacun. La
moyenne de chaque matière est calculée de façon automatique par le système. Après le calcul
des moyennes, ils peuvent être consulter par matière ou par classe.

24
 System

s'authentifier

~
\
\ /
,«includes,. /
\ ,,"«extends»
\ /
~/
1 ~ondes~-
1 ---~ ..-ex~nds»

Administrateur
/ \ ',, ---~
I \ ' ~
/«extends» 1 «e~~nds»
~ \"extends» ',,,

~ ~ ~
~

FIGURE 3.8 - Diagramme de cas d'utilisation de « gestion des notes »

• Gestion des élèves

Objectif : La gestion des élèves permet à l'administrateur de vérifier et de faire la mise à

jour des éffectifs par classe, il Confirme ainsi les inscriptions des élèves.

Acteurs principaux : l'administrateur

Pré condition :L'utilisateur dispose d'un compte d'accès au système.

Description : L'utilisateur organise les effectifs par classes. Il dispose d'un formulaire d'ins-
cription groupée des élèves par classe pour valider les inscriptions. Il peut également valider les
résultats définitifs.

25
 System

S'authentifier

~
1
1 ,<includes» ,.~
1
1 «extejld~»
,. ,.
,."
Gestion des élèves
- *&X!_ends,.

Administrateur ,'
1
\
1
1
----~
\
•«extends» 1

,'' '"extends»
1
\
Ajouter élèves ~
Inscrits
~

FIGURE 3.9 - Diagramme de cas d'utilisation de « Gestion des élèves »

• Gestion des utilisateurs

Objectif : La gestion des utilisateurs permet à l'administrateur principal de vérifier et de

faire la mise à jour des utilisateurs de l'application par école.

Acteurs principaux : l'administrateur principal

Pré condition :L'utilisateur dispose d'un compte d'accès au système.

Description : L'utilisateur organise les utilisateurs par école. Il dispose d'un formulaire
d'inscription des utilisateurs comprenant leurs informations personnelles ainsi que le delai de
validité de chaque compte d'utilisateur.

------+----\Gestion des utlllsateurs

, -..-ext~~ds,. ~
Administrateur
principal
•«extends»
''' - -~
'-..,icextends»

,,
1
''

FIGURE 3.10 - Diagramme de cas d'utilisation de « Gestion des utilisateurs»

26
3.2 Mise en place de la base de donnée
3.2.1 Modèle Physique de Données
Dans la méthode Merise, le modèle physique des données (MPD) consiste à implanter une
base de données dans un SGBDR (Système de Gestion de Base de Données Relationnelles).
Le langage utilisé pour ce type d'opération est le SQL. On peut également faire usage
d'un AGL (PowerAMC, \i\TinDesign, etc.) qui permet de générer automatiquement la base de
données.
Un modèle Physique de Données est une étape de définition des données à l'intérieur de
la structure physique de l'ordinateur c'est-à-dire le résultat de la décision technique qui a été
prise en fonction des objets et des contraintes techniques. C'est un formalisme qui permet de
préciser le système de stockage employé pour un système de gestion de base de données.

Comment créer un MPD ?

Dans un MPD, on crée les tables dont on met le nom dans l'en-tête, ensuite à l'intérieur
de ces tables on répertorie l'ensemble des champs qu'elles contiennent. Dans un second temps,
il faut souligner les champs qui sont des clés primaires et mettre un "" devant les champs qui
sont des clés étrangères.
Pour les clés étrangères ce n'est pas tout, il faut montrer, à l'aide d'une flèche vers quel
champ fait référence la clé étrangère. La flèche commençant de la clé étrangère et l'extrémité
de la flèche quant à elle pointe vers le champ référence.
Ce qui donne pour la base de données décrite ci-dessus, le MPD suivant :

27
 , • .,..111
"-~<Ili .
, .,. ..,
·--
••11t11n)
O.,._ Tl'ffllf fll)
•••• Nfllll
--~Q-TN'l"lfftll
Ï- __ .J..,_ T-CII lo..,..•• ra.n.,.,
••• lffllll
. ....._..,...u.w
·~TMSJ~

1 ,,_nt«:11'_,
11---~
•-fHl'Wll11
1 • .,,.__ WT{II)

'•"'fi!) 1 .--- ----- -------1 •--'TWl"Nfl•)

'!":
1 1
"- Wlf lCtWlll- 1 1 T
1 1 1
o.,._ffifl'Nrtll 1
~--J 1 ':
O ••• TWl'lfff11

J,.....ncsr_ :
1
::--~ ~4 1
1
1
•....ua- Nf{III
'' 1
1
•-NTllll
': 1
1
'•Ml") 1
' 1
·-"""
·- _--.-""' Ill I'------------- : i J
r------1:=.-::;-~111 1
1
1
1
p<---------- 1 1
1 ~------------~t"-~
fiill""IIII 1 1 1
1 1
1 1 1
1 1

.1.. . . .. .,_~ L .:
1 1
1 1 1 1

••••.._0,.1'1
1 1
1 : 1
:
.>-.w~lfllasit I
1
: :
1
1
1
1
!
:
1
1
"-'""""rll 1

...-
1
.;i-TM'NT!II
·---n,et- :: 1••.nt111 '

··--
1
.,. ·-~4')
•.•..•. ... ,
·--
1

·- fllUlrf'".V')
'
1
1
_'
·----""1111 r--- ----- ---- -·-------- --- --i·- .••.., ,

-----Ml·-""''' ·.__.--~-
_.,....~
'
·-~-. ,
._,
"-OUI!:~
1,..----,
1
·- Nfflll
~--------- :
1
1
r----------4•......_,.TMS_
••..-....-..,IIHT'IUI ._ .....,
·~·,...lAW
1
1
1
1
1
1
1
1
1
1
1
1
·-~,
•••••••••.• nc t'TAl9' 1
1
1
1
1
1
1 1
1
:
1
1
1
1
1

·•.•.-..-..,
.,•• ,,.111 1
!
• ••••..••••• N fllll
•..•.. .....•...•.... ,,,
_
~------1----·
1
1
1 1

,....,,,. r-------
•-NT(UI ••""1111

·-- .- o_,_..,,,
\)- 1,1 .w:tW 114 1
1

·--
••••• ,11

"·-·---
•--TUT
1 --------
·--"'"''
••••••• •..• ff,ID_

15:2 'f1 ·----~Ml"

\)--TW'tllffll)

o....._.T1C1,,...
~-------- ---- -- - •l•-oaTWUr.,,,w,
• ....._.T"a,l(S,_ --.--~..
•..........-. ..10ri11
1
1
1
1
1
:
1
:
•• .... .,.M '(,11
.
1-----, 1
:
i 1
1

l 1
:
1
••11n1111 : ·-----Ml,111
..,_ '#lf'C tWII_

0 ••• '111nWîrtl
1--------- 1 .-----------~·----~9f1
' l•-....r-..:sr.. w
1111
·-..-nr.s- ~-------------- --- ---
1

·---
',)- 11JtlW'III)
1
··"""'
.• ..
;)·--•...-~
1 0-lllMCH""I•

., ~
• __..._N'q111
~-----:: J·••--
!
-
....,_.ni-.11
1
·- IHl'(111
._.,,,rn :
'
1 ••••• lff{,1) ~------------: 1
: _, •·---. ...:Oi\ff 1
l1 __•• o,.n.
:
1
1
1 ~--------------------, 1 •-..-..-Wll••t
1
:
1
: : •-...--..-1wr1111 1

__
1 1
1 1 1
1
1
1
1
1
1
. ...,.-"'f••1 .,..,,,
1:____________________ J•...
·----'!PT li,... .---------------:
1
1

-'

·--·-· 1·.....•. , ...

•-,rwnu,w,

----..•- -
• .......__ NTJIII

... . •..
:=.=: .. ,•------------------------------------ J''"""' .
tl•l
••___,,_,.....__.Nflll)
• __ .,..,...,.1,1
::::;::l
•••••••..• TM:aT •••••

•--c..•n.in JAW
••••••••• #11111

FIGURE 3.11 - Modèles Physiques des Données

28
3.2.2 Description des classes métiers du système
ous avons les classes métiers de notre application. Voici la desciption de quelques une :

ets _ annee _ academiques: Nous pouvons observer la relation de cette entité avec presque
les autres du diagramme de classe. Cela se justifie par le faite que le fonctionnement de l'appli-
cation est fondamentalement lié à une année académique.

ets eleves : Cette entité concerne les élèves inscrits dans une année académique, elle
représente l'effectif que l'application va gérer. Elle récolte tous les attributs (informations per-
sonnelles) concernant l'élève.

ets _ eleves _inscrits_ classes : L'inscription des étudiants dans les classes est réalisée par
cette classe. Elle est fondamentale pour le système car elle permet de determiner les élèves ap-
partenant à une classe.

ets contact eleves : cette entité contient les contacts des différents élèves.

ets type .. contact : cette classe se charge de classer les contact par type

ets _ matieres _ enseignees : Cette classe réalise la gestion des matières de l'etablissement.
Elle insère, modifie et supprime des matières.

ets _ moyennes : Une classe pour prendre en compte les moyennes et la gestion de celles-ci.
Les moyennes des différentes matières sont stockées et l'etablissement des bulletins est réalisé
par cette classe.

ets _ classes : Cette classe insère, et modifie les classes en fonction des l'etablissement.

ets _ users _ ecoles : Cette entité est chargée de la gestion des utilisateurs du système. Elle
est chargée de la création d'un utilisateur et de l'attribution des droits à celui-ci.

ets _ evaluations: Cette entité va permettre d'etablir le calendrier des évaluations de l'ecole
durant une année académique.

ets _ enseignants : cette classe recense tous les enseignants de l'etablissement, elle insère,
modifie et supprime les enseignants.

ets niveaus : cette entité regroupe tous les niveaus de l'école.

29
3.3 Conclusion Partielle
Dans ce chapitre , nous avons présenté les différents diagrammes de cas d'utilisations définis
qui ont permis de bien comprendre les besoins du système à développer ainsi que les différentes
interactions entre les objets participant à son fonctionnement, chose qui facilitera la phase
d'implémentation.

30
Chapitre 4

IMPLEMENTATION ET RESULTATS

31
4.1 Plate forme de développement
4.1.1 SGBD MariaDB
MariaDB est un système de gestion de base de données édité sous licence GPL. Il s'agit
d'un fork communautaire de MySQL : la gouvernance du projet est assurée par la fondation
MariaDB, et sa maintenance par la société Monty Program AB, créateur du projet. Cette
gouvernance confère au logiciel l'assurance de rester libre. Les différentes versions de MariaDB
s'articulent sur le code source de MySQL de la version 5.1 aux versions plus récentes (comme
la 5.6 fin 2012). Un serveur de base de données stocke les données dans des tables séparées
plutôt que de tout rassembler dans une seule table. Cela améliore la rapidité et la souplesse de
l'ensemble. Les tables sont reliées par des relations définies, qui rendent possible la combinaison
de données entre plusieurs tables durant une requête.

4.1.2 Le langage de développement PHP

4.1.2.1 Definition
PHP (Hypertext Preprocessor) est un langage de programmation informatique essentiel-
lement utilisé pour produire des pages web dynamiques via un serveur HTTP. Lerésultat est
envoyé vers le client sans ce que celui-ci ne puisse avoir accès à la source.

4.1.2.2 Principe de fonctionnement

Avant de commencer à coder en PHP, il est très important de comprendre comment cela
fonctionne. Il faut savoir que lorsque vous tapez une URL (adresse de site internet) depuis votre
navigateur (appelé client) vous demandez en fait à un serveur (un logiciel tournant généralement
sur une machine distante) de vous retourner une page. S'il s'agit d'un page HTML alors cette
page sera retournée telle quelle (telle qu'elle a été ecrite par le "programmeur" ou "designer").
Dans le cas d'une page PHP, cela est un poil plus complexe. Comme l'explique le schéma
suivant :

FIGURE 4.1 - Principe de fonctionnement de PHP

32
4.1.3 Serveur apache
Apache HTTP Server, souvent appelé Apache, est un logiciel de serveur HTTP produit
par l' Apache Software Fondations. C'est le serveur HTTP le plus populaire du Web. C'est un
logiciel libre avec un type spécifique de licence, nommée licence Apache.

4.1.4 Le modèle MVC de Laravel

Laravel se base effectivement sur le patron de conception MVC, cest-à-dire modèle-vue-
contrôleur. Le modèle interagit avec la base de données, les regroupe, traite et gère les données.
La vue soccupe principalement de faire afficher ce que le modèle renvoie. Ensuite, elle soccupe
de recevoir toute interaction de lutilisateur. Ce sont ces actions-là que le contrôleur gère. Celui-
ci prend en charge de synchroniser le modèle et la vue. Il capte toutes les activités de utilisa-
teur et, en fonction de ces activités, il actionne les changements à effectuer sur l'application.
La séparation des composants dune application en ces trois catégories permet une clarté de
larchitecture des dossiers et simplifie grandement la tâche aux développeurs. Ainsi la figure ci
dessous nous décris l'architecture MVC de Laravel.

View

6 5

Dispatcher 2 Controller

FIGURE 4.2 - Structure MVC de Laravel

Les fichiers sont organisés comme suit :

• Routes (Dispatcher)
Il contient les définitions des chemins dentrées pour lutilisateur, autrement dit les URI
possibles et les dirige sur la classe définit dans le contrôleur qui doit traiter linforrnation.
ous vous présentant quelque ligne de code du fichier route.php de notre application.
• Modèle Pour chaque table de notre base de données que Ion veut utiliser pour notre
application, il faut créer un modèle pour chacun.Ainsi nous avons ici un modèle de notre
application.Il permet de décrire la méthode daccès aux données de la base, tous cela à
travers un objet définit par ORM Eloquent(Object-Relational Mapping).

• Contrôleur
Il permet de récupérer les informations du modèle et de lenvoyer vers la vue pour la mise
en forme.

33
 • Vue La vue receptionne la reponse et qui est envoyée par le contrôleur

4.2 Les interfaces de l'application

L'application se compose de plusieurs interfaces qui guident l'administrateur, l'enseignant
et l'élève vers les différentes fonctions de l'application après son authentification.

4.2.1 Authentification

FIGURE 4.3 - Interface d'authentification

Cet interface (figure 4.2) permet à l'utilisateur de s'authentifier et de se connecter au tableau

de bord de l'application. L'utilisateur doit entrer son identifiant et son mot de passe pour accéder
à l'application. En cas d'échec un message d'alerte s'affiche. En cas de succès, l'utilisateur accède
à la page d'accueil de l'application. Cet interface est la page d'accueil de notre application, Il
propose tous les modules et les liens de navigation rapides à l'utilisateur connecté .

4.2.2 Menu Principal

L'application se compose de plusieurs interfaces qui guident l'utilisateur vers différents mo-
dules. En fonction du choix de l'utilisateur, d'autres interfaces seront affichées par le système,
ce qui permettra l'ajout, la modification, la suppression ou la consultation pour ces gestions.
voir la figure ci dessous :

34
 FIGURE 4.4 - Menu Principal

4.2.3 Administration

Oashboord / Moo Tobleau de bord

Reglster
Nom et Pranom Email

Name E-Mail Address

Profil Mot de passe

d Posswool

a Activer comple
O~ATE) AU(OATE)

2017-12-21 2017-12-21
r- r-
Soumettre

FIGURE 4.5 - Interface "Administration"

Cette section consiste à gérer les utilisateurs de notre application, dans notre cas il s'agit
des enseignants. Chaque enseignant devra disposer d'un login et un mot de passe ce qui lui
permettra d'acceder à sa partition. cette étape est éffectuer par l'administrateur.

35
4.2.4 Gestion des notes
Lorsqu'on clique sur l'onglet "gestion des notes", on nous demande de selectionner une école
vue que on s'est connecter en tant que administrateur principal et que cette application est dédié
à plusieurs établissement. Pour l'administrateur de l'etablissement, dès son authentification il
accède directement à son école (l'école correspondante). Voir figure ci dessous :

~ a.'

Oashboard Mon Tableau de bord

Veuillez choisir une ecole! X

FIGURE 4.6 - Interface 1 "Gestion des notes"

Ensuite on a la possibilité d'acceder à la gestion des notes de l'etablissement choisi. On

selectionne le trimestre ou semestre de l'ecole

Oashboard / Mon Tableau de bord

Veuillez choisir le Trimestre ou le semestre X

Trimesteou Semestre

2eme TRIMESTRE
Jerne TRIMESTRE
1er SEMESTRE
2eme SEMESTRE

FIGURE 4.7 - Interface 2 "Gestion des notes"

36
Après avoir choisi le trimestre, nous devons selectionner la classe concerner. Ici, nous avons
selectionner la classe 6ème 1.

1• TRIMESTRE
'.:J
. ~,
OTitA2
0Mml2
on.Al
05tml1
er1eo
05tmt2 O..,,. &3-ne 02ndtA 02ncfilC OUn .\ OUreO 0TIIA1

a.-~, ••••• ,.,,., ,.m_,.,l\9K"°"",.._ c11t1MB 01, ••.••• fh71.tJ .,. •

FIGURE 4.8 - Interface 11Selectionner classe"

Une liste des élèves de le 6ème 1 ainsi que les moyennes obtenus dans les différentes matières.
Les notes inférieures à dix (10) sont dans les cases oranges tandis que celles supérieures ou
égales à dix (10) sont dans les cases vertes.

Ofeebfa:36

~~00GJ~~GQ
G!JGJ0GJ~~~GQ
~~00~Ci.Q~GQ
G!JB000~~~
(1711Mn&.l

:~ŒJ1,u,j0 GJB0GJGJ~BGQ
-
•...•...••
(11St2'N'lt'I

(lffl--0
~~0~~~8
a • a • • a

FIGURE 4.9 - Interface "moyennes des élèves"

37
4.2.5 Relevés de notes

Lorsqu'on clique sur l'onglet "Relevés de notes", on nous demande de selectionner une classe.
Voir figure ci dessous :

11 ~IT'I~• G •.••••••• .,. C.,u,,•.,~. JXu1_,_. • +

"""""
1• TIUMESTRE

06inw1 0Nml2 05Wnt1 OSWntl o..-r. O:Mme OlndeA 02ndlC OUnA OIW O Olld.1
0TltA2 OTitA3 OTltD

FIGURE 4.10 - Interface "Relevés de notes"

Après la selection de la classe 6ème 1, nous pouvons accéder à la liste des élèves inscrits ainsi
que leurs différentes moyennes par matière (figure 4.)
11.ryalT'tPbl•--·~Jtr•ln
_,.m.,..,_,.. 1 J:l;ut- 1ac•:•. +

OTioA2 OTidl on.o

LISTE DES ELEVES INSCRITS EN 6èME 1

Efflelifs·36

..,,_
...,.,._, 12.00 15,00 12.33 1'50 1 ••• 11.00 .... 12.00 15,00
Il
.,,_,...,..,__ 17,55 , ... 15,00 10.00 15,00 1 ••• 12.00
••• 12.00 a'llwlll,.,..
...,_, .•..... , ... ,,. . •... a
-- 10.00 11.00 1 ••• 15,00

...
1 •••• 12.00

·-
, •...

--·~-~~-.,·-
_..... ...,........... 12.00

5,00
15,00

••• ....
&wiMl--'-~C-
16.DO

•...
,
10.00
•••
1 •••

,.c;sf..-.,0,.C.,...___.
14.00

11.00
13.00

12.00
li.DO

11.00

CIIU,_ C,tO~ f/t7112 •••.

a
a
• -., •• • 2 • •.:; G • • • • l'J •. Q 0 C • ••os1;:;. •

FIGURE 4.11 - Interface "Moyennes des élèves inscrits"

38
Voir la fiche d'un élève
•.,.,.m.~.•--- .•••• ,~

.•.••..
RWICAIS

•..•......
-
12

,.
~
Coof

1
Moy.co,f

12

,.
-,.....
,. ....
HISTOIRE-GEOGRAPHIE 1~33 1 n ll 22-

••••• GNOI. 14.5 1 ,., ,, ....

W.ntEMATIQUE 18 1 11 , ....
Plfl'SIQUE-QIMI( 11 1 11 22-

,., ,., ,. ....

,. ....
SCIEHΠDEU Y1E ET DE U TtRRf 1

EDUCATION PWYSH)IJE ET SPOA'TIYE 12 1 12

&_., ~Uffl ,.G€T-*"~·~1.,_ll(dbu} C 1~ ""u- fh7.tll •,. •

• -. •.••• • • • • •• • i,;.J ri:, a • a a ci • 11 a a a • ••ot1 c;. ..,

FIGURE 4.12 - Interface "Fiche d'un élève"

Nous pouvons générer le relevé de l'élève Abouya Emmanuella

_,
c,-,-..1
e-..:F
a«a: x.
_1,
•.•••• Wlll(..,:NDn
..__ -
AJf9dqe):Hon

---
~)-:OlolOl,:ZCO,a

..
t2
,·.·.._
-
22-

'...l.
1
EW.taNOL.
••••• lD'111911
,,_,
u.- :=.i
1,-.,

,.·.-_ ·
-- •

f'HYSCUE!~

.....,;. ~.- .., 22=-t

,uo
-r:;--,---;---:;-
....,. __. ,_..._..• ,·.·.._- J
=·~f'HWIOUI ET

~
---- ~--
•
a

. ...,.--,.T-0..a::
+-

1&1>.2'9Mltcl: ,~_., •

----..---·~·•• -iccr---.---.
-------:rt ·-- 0----
0--
c--·. --- . --
OISTINCTIOH

- ---
SANCTION

_ .,.... _ _ ,,;s~

.. __.._.e.-.. ..... c--r----

c,-- .•...•.••...
c-

MJD.l •••.• 21•122017

Ull
1
llllll
1
lllllllllllllllllll
1 1 1

FIGURE 4.13 - Interface "Générer relevé"

39
4.3 Conclusion Partielle
A travers ce chapitre, nous avons présenté la réalisation de l'application en justifiant nos
choix technologiques, en représentant quelques interfaces graphiques que nous avons jugé les
plus importantes.

40
Conclusion général

L'objectif de notre projet de fin d'études était de concevoir et implémenter une applica-
tion web de gestion des élèves et de la diplomation. Cette phase pratique de notre formation
consacrée à l'analyse, à la conception et à la programmation nous a conduits à partir des pro-
blèmes constatés, à satisfaire les besoins réels en adéquation avec les objectifs prescrits et les
contraintes rencontrées.
Lors de mon stage j'ai rencontré quelques difficultés. Je n'avais aucune connaissance de
la technologie orienté objet avec le framework laravel. Laravel étant un framework novateur,
complet, qui utilise les possibilités les plus récentes de PHP et qui adopte le patron MVC mais
ne l'impose pas. Ainsi, Je me suis familiarisé avec ces outils et langages informatiques.
J'ai appliqué au maximum les règles de base permettant d'avoir une application performante.
J'ai utilisé le langage UML pour modéliser le système en suivant les différentes étapes, MySQL
comme SGBD et le langage PHP pour implémenter notre application. Du fait que PHP est
un langage flexible, l'application sera portable et opérationnelle indépendamment de toute
plateforme.
La réalisation d'un tel projet, m'a permis d'apprendre et de toucher du doigt divers aspects
du métier de développeur et de celui de concepteur.
Le bilan de ce stage est dans l'ensemble positif, les principaux buts du projet étant accomplis.
La plus grande partie du travail qui m'a été demandée a été réalisée. Les quelques modifications
ou améliorations qui restent à apporter aux différents programmes développés seront effectuées.
ous n'avons pas la prétention d'avoir réalisé un travail parfait. C'est pourquoi, nous vou-
drions au-delà des imperfections et insuffisances que vous constaterez et rencontrerez, tenir
compte de vos remarques, critiques, et suggestions afin de rendre possible la perfection de ce
projet.

41
Bibliographie

Mémoire de fin d'études « Vers une université électronique : un environnement numérique

de travail (E.N.T) destiné aux usagers de l'université Kasdi Merbah Ouargla » Benguenane
Messsaoud, Selatina Ismahane, Université UKMO 2011.

Maurice Chavelli. Découvrez le framework php laravel, 2016

Mémoire de fin d'étude « conception et développement d'une application web de gestion des
remboursement à TUNISAIR » : Souhayla CHAOUI, à IHEC

Mémoire de fin d'étude « Gestion des effectifs et des notes » de l'etudiant Coulibaly Gni-
natin, Université Nangui Abrogoua, 2016

42