Structurer notre application avec pattern MVC

SCHEMA DE LA BASE DE DONNEES

CONCEPTION ET REALISATION

Architecture de l’application

Pour structurer notre application, nous avons utilisé une architecture 3 tiers qui consiste à séparer l’application en trois couches:  La couche client : Elle correspond à l’interface utilisateur. C’est la partie visible de l’application qui interagit avec les utilisateurs. Elle peut être réalisée en HTML, en WML etc. Pour obtenir une interface ergonomique, conviviale et facile à utiliser, nous avons utilisé le framework LARAVEL 5.2
 La couche de traitement : Elle correspond à la partie fonctionnelle de l’application, celle qui implémente la « logique métier», et qui décrit les opérations que l’application opère sur les données en fonction des requêtes des utilisateurs, effectuées au travers de la couche présentation. Les différentes règles de gestion et de contrôle du système sont mises en œuvre dans cette couche. La couche métier offre des services applicatifs et métier à la couche présentation à travers un serveur d’application. Dans notre projet, nous avons utilisé le serveur Apache.

 La couche de gestion des données : Elle correspond à la partie qui gère l’accès aux données du système. Les données peuvent être stockées indifféremment dans des fichiers de type texte, XML, ou encore dans une base de données gérée par un SGBD. Dans notre projet, nous avons utilisé le SGBD MySQL.

Conception de la logique applicative

Pour structurer notre application nous avons utilisé le pattern MVC qui permet de bien organiser l’application. Le but de MVC est justement de séparer la logique du code en trois parties que l’on retrouve dans des fichiers distincts, comme l’explique la description suivante :  Modèle : cette partie gère les données de l’application. Son rôle est de récupérer les informations « brutes » dans la base de données, de les organiser et de les assembler pour qu’elles puissent ensuite être traitées par le contrôleur. On y trouve donc les requêtes SQL. Parfois, les données ne sont pas stockées dans une base de données. C’est plus rare, mais on peut être amené à aller chercher des données dans des fichiers. Dans ce cas, le rôle du modèle est de faire les opérations d’ouverture, de lecture et d’écriture de fichiers.  Vue : cette partie se concentre sur l’ affich age . Elle ne fait presque aucun traitement et se contente de récupérer des variables pour savoir ce qu’elle doit afficher. On y trouve essentiellement du code HTML.  Contrôleur : cette partie gère la logique du code qui prend des décisions . C’est en quelque sorte l’intermédiaire entre le modèle et la vue : le contrôleur va demander au modèle les données, les analyser, prendre des décisions et renvoyer le texte à afficher à la vue. Le contrôleur contient exclusivement du PHP. C’est notamment lui qui détermine si le visiteur a le droit de voir la page ou non (gestion des droits d’accès).Ainsi, pour chaque d’utilisation nous avons développé des digrammes de séquences en se basant sur le MVC. Dans la suite nous présentons les digrammes de séquence de quelque cas d’utilisation.

Table des matières

CHAPITRE I : CONTEXTE GENERALE DU PROJET
1. ORGANISME D’ACCUEIL
2. CADRE DU PROJET
3. PROBLEMATIQUE ET OBJECTIFS DU PROJET
4. CAHIER DE CHARGES
CHAPITRE 2 : ANALYSE ET CONCEPTION
1. METHODOLOGIES DE DEVELOPPEMENT
2. ANALYSE DES BESOINS
2.1- IDENTIFICATION DES ACTEURS
2.2. IDENTIFICATION DES CAS D’UTILISATION
2.3- DESCRIPTION DES CAS D’UTILISATION
2.4- DIAGRAMME DE CLASSES
3. CONCEPTION DE L’APPLICATION
3.1- ARCHITECTURE DE L’APPLICATION
3.2. CONCEPTION DE LA LOGIQUE APPLICATIVE
3.3. SCHEMA DE LA BASE DE DONNEES
CHAPITRE 3 :REALISATION
1-OUTILS DE REALISATION
2-PRESENTATION DE L’APPLICATION
2.1- PRESENTATION DE L’AUTHENTIFICATION
2.2- PRESENTATION DE L’ESPACE COORDONNATEUR
2.3- PRESENTATION DE L’ESPACE ADMIN
2.4- PRESENTATION DE L’ESPACE ETUDIANT
CONCLUSION
WEBOGRAPHIE ET BIBLIOGRAPHIE :

Télécharger le rapport complet