Architecture logique MVC

Analyse de l’application et spécification des besoins

CONCEPTION GENERALE

Dans cette partie nous abordons la définition de l’architecture technique qui consiste à faire les choix de technologies et d’organisation de composants logiciels les plus adaptés aux besoins et aux contraintes de l’organisation d’accueil. Ces choix sont ensuite relayés au sein de notre projet, guidant la conception et permettant la transformation d’un modèle fonctionnel en application performante et robuste.

Architecture logique MVC 

L’architecture MVC (modèle, vue et contrôleur) c’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 : rassemble des données du domaine, des connaissances du système. Contient les classes dont les instances doivent être vues et manipulées.
• Vue : utilisé pour présenter/afficher les données du modèle dans l’interface .
• Contrôleur : contient les fonctionnalités nécessaires pour gérer et contrôler les interactions de l’utilisateur avec la vue et le modèle .

Le principal avantage de choisir cette architecture c’est la séparation de la couche interface utilisateur des autres parties du système (car les interfaces utilisateurs sont beaucoup plus susceptibles de changer que la base de connaissances du système).

Architecture physique 3-tiers 

L’architecture adoptée pour notre application est l’architecture 3-tiers client /application /ressource à fin de permettre le développement et la modification de différentes interfaces utilisateurs pour la même logique applicative.

Partie cliente : consiste à la réalisation des différentes interfaces de l’application mobile et leur affichage.

Partie serveur : elle permet l’insertion, la consultation des données et la mise à jour de l’application cliente.

Partie interconnexion client-serveur : permet de mettre en correspondance l’interaction entre les différents intervenants de l’application et assure la communication entre eux.

CONCEPTION DETAILLEE

Dans cette partie nous présentons le diagramme de classes ainsi de séquences constituant le système et les associations entre elles à fin de mieux structurer les différentes classes prise en compte dans notre application.

Diagramme de classes 

Les diagrammes de classes expriment de manière générale la structure statique d’un système, en termes de classes et de relations entre elles. De même qu’une classe décrit un ensemble d’objets, une association décrit un ensemble de liens ; les objets sont des instances de classes et les liens sont des instances de relations.

Les principales classes de notre application sont :
• Classe Agent : C’est la classe qui contient toutes les actions prises en charge par l’agent CNAM :
➢ Notifier les erreurs et pannes
• Classe intervenant: C’est la classe qui contient toutes les actions prises en charge par l’intervenant :
➢ Consulter documentation ➢ Notifier les réclamations ➢ Réparer panne ➢ Intervenir si nécessaire
• Classe administrateur: C’est la classe qui contient toutes les actions prises en charge par l’administrateur :
➢ Gérer utilisateurs ➢ Gérer droits ➢ Gérer statistiques ➢ Gérer documentation ➢ Gérer erreurs ➢ Gérer Notification
• Classe Utilisateurs : elle contient tous les utilisateurs du CNAM selon leur :
➢ Id-CNAM ➢ Nom et prénom ➢ Rôle et affectation
• Classe authentification : C’est la classe qui gère les connexions à l’application (contient les login CNAM et mot de passe), qui servent à la phase authentification.
• Classe erreurs : C’est la classe qui contient les erreurs et pannes soft, hard ou bug.
• Classe Notification : elle contient les réclamations des pannes et erreurs à notifier ainsi l’affectation des taches correspondantes.
• Classe Documentation : ca englobe toute documentation technique, manuel de procédure et les solutions adéquates.
• Classe Droits : c’est la classe qui contient les droits attribués aux agents par l’administrateur ainsi la suppression ou l’ajout de certains privilèges.
• Classe Statistiques : elle contient les états des problèmes techniques et interventions.
• Classe Solutions : Elle contient les solutions des erreurs Soft et Hard.

Table des matières

Introduction Générale
Chapitre 1 : Présentation générale du projet
Introduction
1. Thématique du stage
1.1. Contexte du travail
1.2. Présentation de l’organisme d’accueil
1.3. Organigramme de la CNAM
1.4. La DRSMI
2. Problématique
3. Etude de l’existant
Conclusion
Chapitre 2 : Analyse de l’application et spécification des besoins
Introduction
1. Présentation des acteurs
2. Identification des acteurs de l’application
2.1 Administrateur
2.2 Intervenant
3. Spécification des besoins fonctionnels
3.1 Analyse du cas d’utilisation
3.1.1 Description
3.2 Analyse de cas d’utilisation
3.2.1 Description
3.3 Analyse de cas d’utilisation
3.3.1 Description
3.2 Analyse de cas d’utilisation
3.2.1 Description
3.3 Diagramme de cas d’utilisation général
3.4 Diagramme de séquences
4. Spécification des besoins non fonctionnels
Conclusion
Chapitre 3 : Conception
Introduction
1. Conception générale
1.2. Architecture logique MVC
1.3. Architecture physique 3-tiers
2. Conception détaillée
2.1. Diagramme de classes
Conclusion
Chapitre 4 : Réalisation
Introduction
1. Environnement de travail
1.2 Configuration matérielle
1.3 Configuration logicielle
2. Description de l’application
2.1 Interface authentification
2.2 Interface administrateur
2.2.1 Gestion des utilisateurs
2.2.2 Gestion erreurs
2.2.3 Gestion documentation
2.2.4 Statistiques
2.3 Interface intervenant
2.4 Interface Agent CNAM
Conclusion générale et perspectives
Bibliographie et références

Télécharger le rapport complet