Soutenance mémoire
Langage de modélisation UML
CONCEPTION
Après avoir établie une vision claire des besoins, et spécifié le langage de modélisation UML et la méthodologie de conception, nous détaillons durant ce chapitre la phase de conception. Ainsi, nous nous concentrons sur la conception d’une structuration appropriée pour l’application. Cette étape est fondamentale au bon déroulement du projet, et vise à détailler les tâches à exécuter et de préparer le terrain pour l’étape de réalisation. Dans une première partie, nous commençons par la conception globale de notre projet. Ensuite, dans une deuxième partie, nous détaillons la conception en utilisant les diagrammes UML appropriés. 1. Conception Architecturale
Il est primordiale à la conception de tout système informatique de choisir le modèle d’architecture qui lui sera adéquat pouvant assurer un bon fonctionnement, des meilleurs performances ainsi que la réutilisation et l’interconnexion fiable de ce système avec d’autres.
C’est à cet effet que nous optons pour le modèle MVC qui sera également très pratique pour gérer l’interaction entre les différents composants de notre application.
Architecture logique
Le model MVC (Figure N° :12) (modèle, vue, contrôleur) est le concept choisi dans la réalisation de notre application. Son principal intérêt est la séparation des données (modèle), de l’affichage (vue) et des actions (contrôleur)
Modèle : gère le logique métier et l’accès aux données. Vue : son rôle est de gérer les interactions avec l’utilisateur : présentation, saisie et validation des données. Contrôleur : renferme les fonctionnalités nécessaires pour coordonner et contrôler les interactions de l’utilisateur avec la vue et le modèle.
Architecture physique de l‘application
Architecture Client/serveur
L’architecture client-serveur (Figure N° :13) comme son nom l’indique est une architecture où toutes les données sont centralisées sur un seul serveur et tous les postes clients y accèdent, ce qui simplifie les contrôles de sécurité, l’administration, la mise à jour des données et des logiciels.
Architecture distribuée
Une architecture est appelée distribuée (Figure N° :14) dans le cas où toutes les ressources ne se trouvent pas au même endroit ou sur la même machine. Cette architecture repose sur la possibilité d’utiliser des objets qui s’exécutent sur des machines réparties, sur le réseau, et communiquent par des messages à travers ce réseau.
Son principe est de permettre l’évolutivité du système sous plusieurs aspects : le volume des données stockées, la disponibilité du serveur, le nombre d’utilisateurs.
Architecture trois-tiers
Dans cette architecture (Figure N° :15), un niveau supplémentaire est ajouté :
Un client (l’ordinateur demandeur de ressources) équipé d’une interface utilisateur chargée de la présentation. Un serveur d’application qui fournit la ressource, mais en faisant appel à un autre serveur. Un serveur de données qui fournit au serveur d’application les données requises pour répondre au client.
Architecture physique choisie
Architecture du Backoffice Web
Pour notre application Back office, l’architecture que nous avons choisie est l’architecture à trois niveaux. Cette architecture est un modèle logiciel d’architecture applicative qui vise à séparer les trois couches (Client, Serveur et le système de gestion de base de données (SGBD)). Elle permet de présenter cette application comme un empilement de trois niveaux de couches :
La présentation des données correspondant à l’affichage. Le traitement métier des données correspondant à la mise en œuvre des règles de gestion et de la logique applicative. L’accès aux données persistantes.
Architecture des applications mobiles
Notre system se compose de deux applications mobiles (Figure N° :16) qui communiquent avec la base donnée centrale via un « Web Service REST » :
Une application mobile pour l’adhérent qui lui permet de consulter son mode d’affiliation, son plafond, annoncer la perte de carte et consulter l’historique de ses transactions.
La deuxième application mobile est destinée au contractant pour lui permettre d’exécuter l’ordonnance fournie par l’adhérent, de scanner les codes à barres des médicaments prescrits,d’effectuer la transaction de paiement, de consulter ses factures, de consulter son compte et consulter l’historique de ses transactions.
Les Transactions de paiement sont transmises à la base de données centrale via un serveur transactionnel.
Présentation globale du système
Notre nouveau système est composé de trois applications. :
Le BackOffice web destiné au gestionnaire de Mutuelle des PTT à fin de faciliter toutes manipulations d’informations concernant les adhérents et les contractants et toutes autres informations incluses dans notre système.Une application mobile pour l’adhérent qui permet de consulter son mode d’affiliation, son plafond, annoncer la perte de son badge et consulter l’historique de ses transactions.Une deuxième application mobile est destinée au contractant qui lui permet d’exécuter l’ordonnance fournie par l’adhérent, de scanner les codes à barres des médicaments prescrits, d’effectuer la transaction de paiement, de consulter ses factures, de consulter son compte et de consulter l’historique de ses transactions. 3. Conception de l’Aspect Statique
Identification des classes
La classe Adhérent : Représente les agents des établissements affiliés à la mutuelle des PTT, et qui adhérent au service de cette dernière. La classe Contractant : Représente le contractant avec la mutuelle (exemple Pharmacies conventionnées). La classe Terminal: représente le TPE (terminal de payement électronique SMART) affecté au pharmacien. La classe Transaction : Représente tous les transactions faites par l’adhérent/ Contractant. La classe Solde d’adhérent : Représente le Solde personnel d’un adhérent (consommations – dépassement). La classe Suivi dépassement : Représente le suivi des autorisations de dépassement pour un adhérent. La classe Compte de contractant : Représente le compte personnel de chaque contractant.
La classe Facture : Représente les factures édité pour un contractant et alimente son compte. La classe Utilisateur: Représente la personne qui peut utiliser l’application en mode Gestionnaire / Administrateur. La classe Badges : Représente les badges de chaque Adhérent. La classe Suivi Badges : Représente l’historique de tous stratus de badges de chaque Adhérent La classe Exercice : représente la date début et fin d’un exercice comptable. La classe Mode d’affiliation : Représente les modes d’affiliations que l’adhérent peut avoir au sein de la Mutuelle. La classe Suivi Mode affiliation : Représente l’archive de mode d’affiliation d’adhérent. La classe Remboursement : Représente le taux de remboursement par activité / mode affiliation La classe Activité : Les types d’activité exercée par les contractants La classe Activité du contractant : Représente les différentes activités d’un contractant. La classe Prescription : représente les différents médicaments présents dans le marché. La classe Etablissement : Représente l’établissement de l’adhérent. La classe Situation administrative : Représente l’état administratif de l’adhérent que ce soit en activité, décédé ou retraité. La classe Suivi Situation administrative : Représente l’historique des Situations administratives d’un Adhèrent. La classe Suivi Situation familiale : Représente l’historique des Situation familiale d’un adhèrent. La classe Situation familiale : Représente l’état civil d’un adhérent que ce soit célibataire, marié. La classe Ayant droit : Représente le suivi des membres de famille de l’adhèrent ayant droit au service de la mutuelle. La classe Membre Famille : Représente les membres de famille de l’adhèrent. La classe Profile : Représente les profile dynamique des utilisateurs. La classe Menu : Représente les menus, boutons, options du backoffice web.
Diagramme de classe
Dans la vision de bien comprendre le système, délimiter le périmètre du Project et d’avoir une idée claire et logique de ses fonctionnalités, nous dressons le diagramme de classes (Figure N° :17) qui nous donne une vue globale du système en présentant ses classes, ses interfaces, ses collaborations, et les relations entre elles.
|
Guide du mémoire de fin d’études avec la catégorie Langage de modélisation UML |
|
Étudiant en université, dans une école supérieur ou d’ingénieur, et que vous cherchez des ressources pédagogiques entièrement gratuites, il est jamais trop tard pour commencer à apprendre et consulter une liste des projets proposées cette année, vous trouverez ici des centaines de rapports pfe spécialement conçu pour vous aider à rédiger votre rapport de stage, vous prouvez les télécharger librement en divers formats (DOC, RAR, PDF).. Tout ce que vous devez faire est de télécharger le pfe et ouvrir le fichier PDF ou DOC. Ce rapport complet, pour aider les autres étudiants dans leurs propres travaux, est classé dans la catégorie Critique de l’existant de la mutuelle des PTT où vous pouvez trouver aussi quelques autres mémoires de fin d’études similaires.
|
Table des matières
Introduction générale
Chapitre 1 : Etude de préalable
Introduction
1. Présentation de la mutuelle des PTT
2. Etude de l’existant
2.1. Service de la mutuelle des PTT
2.2. Description du système actuel
3. Critique de l’existant de la mutuelle des PTT
4. Solutions similaires existantes
4.1. Prestations en Tunisie
4.2. Prestations en France
4.3. Synthèse des solutions similaires
5. Solution Proposée
5.1. Description du nouveau système
Conclusion
Chapitre 2 : Analyse et spécification des besoins
Introduction
1. Identification des besoins
1.1. Analyse des besoins fonctionnels
1.2. Analyse des besoins non fonctionnels
2. Démarche et méthodologie de travail
2.1. Langage de modélisation UML
2.2. Les méthodes de conception
3. Les diagrammes de cas d’utilisation
3.1. Identification des acteurs
3.2. Diagramme de cas d’utilisation global
3.3. Diagramme de cas d’utilisation « Authentification »
3.4. Diagramme de cas d’utilisation « Gestion adhérents »
3.5. Diagramme de cas d’utilisation « Gestion Contractant »
3.6. Diagramme de cas d’utilisation « Gestion des badges »
3.7. Diagramme de cas d’utilisation « gestion des comptes »
3.8. Diagramme de cas d’utilisation « Exécuter L’ordonnance par mobile »
3.9. Diagramme de cas d’utilisation « Annoncer Perte de badge »
Conclusion
Chapitre 4 : Conception
Introduction
1. Conception Architecturale
1.1. Architecture logique
1.2. Architecture physique de l‘application
1.3. Architecture physique choisie
2. Présentation globale du système
3. Conception de l’Aspect Statique
3.1. Identification des classes
3.2. Diagramme de classe
4. Conception de l’Aspect Dynamique
4.1. Diagramme des séquences
4.2. Diagramme de déploiement
Conclusion
Chapitre 5 : Réalisation
Introduction
1. L’environnement de travail
1.1. L’environnement matériel
1.2. L’environnement logiciel
2. Choix technique
2.1. HTML5
2.2. Bootstrap
2.3. JavaScript
2.4. AJAX
2.5. PHP
2.6. JQUERY
2.7. NotePad++
2.8. NetBeans IDE 8.0.2
2.9. PL/SQL
2.10. Xampp
2.11. Subversion
2.12. Tortoise SVN
2.13. Ionic Framework
2.14. CodeIgniter Framework
2.15. Node.js et les dépôts NPM
3. Présentation des interfaces
3.1. Application web
3.2. Serveur Transactionnel
3.3. Application mobiles
4. Chronogramme du projet
Conclusion
Conclusion Général
Bibliographie
Télécharger le rapport complet
