TG-LL
MODELISATION ET CONCEPTION
Introduction
La phase modélisation et conception présente une étape primordiale dans le cycle de développement d’un projet. On présente d’abord la méthodologie d’analyse puis il sera question de présenter les principaux acteurs et leurs rôles .Ensuite dans la branche fonctionnelle, on va définir les besoins fonctionnels et non fonctionnels, puis présenter les différents diagrammes d’UML.
Modèle MVC
L’architecture MVC (modèle, vue et contrôleur) [3] est un concept très puissant qui intervient dans la réalisation d’une application. Son principal intérêt est la séparation des données (modèle), de l’affichage (vue) et des actions (contrôleur), ce qui assure la clarté de l’architecture et simplifie la tâche du développeur responsable de la maintenance et de l’amélioration du projet. 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..
Model
Le modèle représente le cœur de l’application traitements des données, interactions avec la base de données. Il décrit les données manipulées par l’application. Il regroupe la gestion de ces données et est responsable de leur intégrité. La base de données sera l’un de ses composants. Le modèle comporte des méthodes standards pour mettre à jour ces données (insertion, suppression, changement de valeur). Il offre aussi des méthodes pour récupérer ces données. Les résultats renvoyés par le modèle ne s’occupent pas de la présentation, Le modèle ne contient aucun lien direct vers la vue.
Contrôleur
Le contrôleur prend en charge la gestion des événements de synchronisation pour mettre à jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de l’utilisateur et déclenche les actions à effectuer. Si une action nécessite un changement des données, le contrôleur demande la modification des données au modèle et ce dernier notifie la vue que les données ont changée pour qu’elle se mette à jour. D’après le patron de conception observateur/observable, la vue est un « observateur » du modèle qui est « observable ». 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. Le contrôleur n’effectue aucun traitement, ne modifie aucune donnée, il analyse la requête du client et se contente d’appeler le modèle adéquat et de renvoyer la vue correspondant à la demande.
La Vue
C’est avec quoi l’utilisateur interagit se nomme précisément la vue. Sa première tâche est de présenter les résultats renvoyés par le modèle, sa seconde tâche est de recevoir toute action de l’utilisateur (clic de souris, sélection d’un bouton radio, coche d’une case, entrée de texte, de mouvements, de voix, etc.). Ces différents événements sont envoyés au contrôleur.
La vue n’effectue pas de traitement, elle se contente d’afficher les résultats des traitements effectués par le modèle et d’interagir avec l’utilisateur.
Avantages du MVC
Efficace grâce à la séparation des données de la vue et du contrôleur.
Besoin fonctionnel
Cette étape décrira ce que nous attendons de notre application, puis tous ceci sera modélisé sous forme de diagramme à l’aide du langage de modélisation UML.
Diagrammes de cas d’utilisation
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. Ainsi, « le diagramme de cas d’utilisation décrit l’interaction entre le système et l’acteur en déterminant les besoins de l’utilisateur et tout ce que doit faire le système pour l’acteur ».
Acteur Administrateur
Le schéma ci-dessous représente le diagramme de cas d’utilisation de l’administrateur.
Figure 4 Diagramme de cas d’utilisation Administrateur
Acteur Client
Le schéma ci-dessous représente le diagramme de cas d’utilisation du client.
Figure 5 Diagramme de cas d’utilisation Client
Acteur Technicien
Le schéma ci-dessous représente les différents cas d’utilisation chez le technicien.
Figure 6 Diagramme de cas d’utilisation Technicien
Acteur Réceptionniste
Le schéma ci-dessous représente l’ensemble des cas d’utilisation chez le Réceptionniste.
Figure 7 Diagramme de cas d’utilisation Réceptionniste
|
Table des matières
INTRODUCTION
CHAPITRE I CONTEXTE DE PROJET
1. PRESENTATION DE L’ORGANISME D’ACCUEIL
1.1. Présentation
1.2. Organigramme
2. PRESENTATION DE PROJET
2.1. Cahier des charges
2.2. Aspect et qualité de l’application
2.3. Besoin technique
CHAPITRE II MODELISATION ET CONCEPTION
1. INTRODUCTION
2. MODELE MVC
2.1. MODEL
2.2. CONTROLEUR
2.3. LA VUE
2.4. AVANTAGES DU MVC
2.5. BESOIN FONCTIONNEL
2.6. DIAGRAMME D’ACTIVITÉ
3. DIAGRAMMES DE CAS D’UTILISATION
3.1. Acteur Administrateur
3.2. Acteur Client
3.3. Acteur Technicien
3.4. Acteur Réceptionniste
4. DIAGRAMMES DE SÉQUENCE
4.1. Cas authentification
4.2. Cas demande client
4.3. Cas affectation demande
5. DIAGRAMME DE CLASSE
Description du diagramme de classe
6. ARCHITECTURE 3-TIERS
CHAPITRE III PRESENTATION DE L’APPLICATION
1. INTRODUCTION
2. TECHNOLOGIE ET OUTILS UTILISÉES
3. REALISATION
3.1. AUTHENTIFICATION
3.2. GESTION DEMANDES
CONCLUSION
WEBOGRAPHIE
BIBLIOGRAPHIE
Télécharger le rapport complet
