CONCEPTION ET REALISATION D'UNE APPLICATION DE …

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

l'="IVl:11.,.ITE NANGUIABROGOUA

C' nit• de FonN1ttion •t de 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

Président du jury : Membre: Membre Membre:

Directeur de mémoire : M. AKA Boko, Professeur titulaire, UNA

Co-directeur: Mr ZEZE Djédjé Sylvain, Maître-Assistant, UNA

•

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é

Abstract

Liste des figures

Liste des abréviations

Introduction

2

3

ii

1 CONTEXTE GENERAL DU PROJET 1.1 Présentation de la structure d'accueil

1.1.1 Cadre du stage . 1.1.2 Objectif du Xerya IT School . 1.1.3 Organigramme de l'institut XITS

1.2 Cadre général du projet . 1.2.1 Contexte général du projet . 1.2.2 Présentation générale du projet 1.2.3 Objectif du projet .

1.3 Conclusion partielle . . . . . . .....

2 ETUDE FONCTIONNELLE ET TECHNIQUE 2.1 Spécification des besoins . . . . . . . . . . . . . .

2.1.1 Spécification des besoins fonctionnels ... 2.1.2 Spécification des besoins non fonctionnels

2.2 Choix méthodologique . 2.2.1 Le langage UML . 2.2.2 La technologie orientée objet . 2.2.3 L'architecture MVC (Model-View-Controller 2.2.4 Framework Laravel

2.3 Conclusion partielle . . . . . . . . . . . . . . . . . .

3 ANALYSE ET CONCEPTION 3.1 Modélisation en langage UML . . . . . .

3.1.1 Identification des acteurs ..... 3.1.2 Le diagramme de cas d'utilisation

3.2 Mise en place de la base de donnée ... 3.2.1 Modèle Physique de Données .. 3.2.2 Description des classes métiers du système

3.3 Conclusion Partielle . . . . . . . . . . . . . . . . .

1

1

3 4 4 5 5 5 5 6 6 7

8 9 9 9

10 10 12 13 15 16

17 18 18 18 27 27 29 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 . . . . . . . 4. 5 Interface "Administration 11 4.6 Interface 1 "Gestion des notes" 4. 7 Interface 2 "Gestion des notes" 4.8 Interface "Selectionner classe" . 4.9 Interface "moyennes des élèves" 4.10 Interface "Relevés de notes" .. 4.11 Interface 11 Moyennes des élèves inscrits" 4.12 Interface "Fiche d'un élève" 4.13 Interface "Générer relevé" .

35 35 36 36 37 37 38 38 39 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 Fonctionnalité

Pro grammeurs Gestion du logiciel

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

Analystes/Testeurs Comportement

Vue des processus

Vue de déploiement

Intégrateurs système Performance Capacité à grandir Débit d'information

Ingénieurs système Topologie du système Livraison, installation

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 d'utilisation

Classas Etats .• Transmons

Obëets Séquences

Déploiement

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

Mcx:lèlo données v •.•••

sy ne hoh;s.a..1.i on

J.ocx:lif;c.nti on

.n:,iac, .à.jouL· deus d.onnéea

é"'léne.1.nc,n\s

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.

1 Système de vente par correspondance A,, J

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

élève

~ consulter fiche de matières

enseignant

consulter tes moyennes

entrer les moyennes

System

~~x!_eil<!S!,

' ' ' ' ' ' ' ', ' ' ' 'i!includes•

' ' ' ' ' ' ' ' ', '

~ «inc!l!,de's• /,·, ;1 , , I / 1

,,,." /1 I I 1 / I I 1

./«incl)fdes-,' : I I I I I I I 1

11 /«includes• ,

I / I 1 / 1 1 I / 1 / ,'«incl~des• I 1 1

/ ,' : ,'

11 «lnclude$•

1 1 1 I 1 1 , , 1 «lncludes» 1 1 1 1 1 1

1 I 1 1 1 ' 1 1 1

1 1 1 1 1 1 t 1 1 1 1

valider les moyennes

génération des buUetlns

gestion des él~es

administrateur principal

paramétrages

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


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» \

Administrateur

/ / / /

I /«extends» I I /

~

\ «e):~nds» \ ',~ '1 ~ ,«extends» \ \ 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

Administrateur

s'authentifier

~ \ \ ,«includes,. \ \

/ /

,,"«extends» / ~ /

1 ~ondes~- 1 ---~ ..-ex~nds» / \ ',, ---~

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.



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 11,<includes» 1

Gestion des élèves

Administrateur ' , 1 •«extends»

' ' ,

,.~ «extejld~» ,. ,. ,."

- *&X!_ends,. ----~

Ajouter élèves Inscrits

\ 1 1 \ 1 '"extends»

1 \

~ ~

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


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

Administrateur principal

•«extends» 1 , ,

, -..-ext~~ds,. ~

''' - - ~ '-..,icextends» ' '

~

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

'•"'fi!) "-WlflCtWlll

o.,._ffifl'Nrtll O ••• TWl'lfff11

J,.....ncsr_ •....ua-Nf{III

•-NTllll

Ï- __ 1 .J..,_ T-CII 1 ,,_nt«:11'_, 1 1 1 1

~--J

, • ..,..111 "-~<Ili O.,._Tl'ffllffll)

--~Q-TN'l"lfftll

11---~ lo..,.. •• ra.n.,., • .,,. __ WT{II)

'•Ml")

·-""" ·-_--.-""'Ill

r------1:=.-::;-~111 1 1 1 1 1 1 1 1

••••.. _0,.1'1 L . ..1...........,_~ : .>-.w~lfllasit I

fiill""IIII

"-'""""rll .;i-TM'NT!II

·---n,et •.•..•.... , ... - ·-fllUlrf'".V')

, . .,. .. , •••• Nfllll

••• lffllll

•-fHl'Wll11 .--- ----- -------1 •--'TWl"Nfl•) 1 1 1 1 1 : 1

' ' ' : '

I'------------- :

·----""1111 -----Ml·-""'''

·-Nfflll

T 1

' : 1 1 1 1 1 1 1 1 1 i J

1 1 1 1 1 1 1 : : 1 !

::--~ ~4

p<---------- 1 1 1 1 1 1 1 1 : 1 1 1

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

••11t11n) ·- ·~TMSJ~ . ....._..,...u.w '!":

~--------- : 1 1 1 1 1 1 1 1 1 1 : 1 1 1 1 1 1 ~------1----· 1 1 --------

··-- r--- ----- ---- -·-------- --- --i·- .••.. , ·--~-

., •• ,,.111 ·- •••••..••••• Nfllll •.•... ,....,,,. .. , •--TUT ·--- ••••••••..• ff,ID_

15:2

r------- •..•.. _ .....•...•..... ,,, •-NT(UI

.__._.,....~ r----------4•......_,.TMS_

••..-....-..,IIHT'IUI

~------------~t"-~ 1 1 1 1 1 : 1 1 1 : 1

' 1 1

' 1 1

' ' , _ ·-- ·-~ "-OUI!:~ ._,.., ._ ..... , ·~·,...lAW •••••••••.• nct'TAl9' ·-~,

'f 1 : 1 : 1 : 1 1 1 : 1 :

1--------- 1

1,..----, 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 !

. 1 1 1 1 1 1-----,

i l

·--"'"''

••11n1111 ..,_'#lf'CtWII_

0 ••• '111nWîrtl

',)-11JtlW'III) ·-..-nr.s- ·-- • _ _..._N'q111 ·-IHl'(111 ._.,,,rn

1 ••••• lff{,1)

~-------------- --- ---

~-----: J·-- .. : •• ....,_.ni-111 : _, ·---....:Oi\ff • __ •• o,.n.

\)--TW'tllffll) ·----~Ml" o....._.T1C1,,... •• .....,.M'(,11 .

••••• ,11 ·- ~-------- ---- -- - •l•-oaTWUr.,,,w, • ....._.T"a,l(S,_

••""1111 \)- 1,1.w:tW1141 o_,_..,,, ·- "·----.--~ .. •..........-....10ri11

l 1 1 1 1 : 1 1 1 1 1 1 -'

·-----Ml,111 .-----------~·----~9f11111 ' l•-....r-..:sr...w 1 1 1

! 1 : ' ~------------:

··"""' 0-lllMCH""I•

., •.....• ~ .. ·- ;)--~

• __ .,..,...,.1,1 •••••••..• TM:aT •••••

•--c..•n.inJAW ••••••••• #11111

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

·--·-· .. , J''"""' :=.=: •------------------------------------ ::::;::l

•-..-..-Wll••t •-...--..-1wr1111

1 1 : 1 1 : 1 1 1 1 1

li,.....---------------: • .......__NTJIII

•-,rwnu,w, .....•..• , ... - 1·----.-..... •... tl•l •• ___,,_,.....__.Nflll) .

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)

2017-12-21 r- AU(OATE)

2017-12-21 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 .. ~, 0Mml2 05tml1 05tmt2 O..,,. &3-ne 02ndtA 02ncfilC OUn.\ OUreO 0TIIA1

OTitA2 on.Al er1eo

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

(1711Mn&.l

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

~~00GJ~~GQ G!JGJ0GJ~~~GQ ~~00~Ci.Q~GQ G!JB000~~~ GJB0GJGJ~BGQ ~~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 OIWO 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,.,..

...,_, .•..... , ... 10.00 11.00 1 ••• 15,00 1 •••• ,, ... •... 12.00 a -- ........... 12.00 15,00 , •... 16.DO , ... ••• 14.00 13.00 li.DO a _ ..... ..., 5,00 ••• .... •... 10.00 1 ••• 11.00 12.00 11.00 ·- &wiMl--'-~C- ,.c;sf..-.,0,.C.,...___. CIIU,_ C,tO~ f/t7112 •••. 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.~ .• --- .•••• ,~

~ .•.••.. - Coof Moy.co,f - RWICAIS 12 1 12 ,. .... •..•...... ,. 1 ,. ,. .... HISTOIRE-GEOGRAPHIE 1~33 1 nll 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 _, ~)-:OlolOl,:ZCO,a

a«a: x. ..__ - •.•••• Wlll(..,:NDn AJf9dqe):Hon _1,

t2 .. EW.taNOL. ,,_, '...l. 1,-.,

1 ••••• lD'111911 -- • u.-

--- f'HYSCUE!~ ... ..,

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

•

··- ,..._ 22-

:=.i ·-· 22=-t ,.._

J ··- ,..._ .,.,.T-..a:: 1&1>.2'9Mltcl: ,~_., • ~-- .... --0

OISTINCTIOH SANCTION -------:rt•• ----..---·~· _.,.... __ ,,;s~ -ic·-- cr---.---. c,-- .•...•.••... c-

0---- .. -- 0-- .. -- c--·--- c--r---- .. __.._.e.-.. ..... MJD.l •••.• 21•122017

Ull llllll lllllllllllllllllll 1 1 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

CONCEPTION ET REALISATION D'UNE APPLICATION DE …

Documents

Transcript of CONCEPTION ET REALISATION D'UNE APPLICATION DE …