Modélisation et conception de la solution proposée

Modélisation et conception de la solution proposée

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.

Méthodologie d’analyse

Le langage UML

UML[2] ou Langage de Modélisation Unifié, est un langage de modélisation graphique à base de pictogrammes. Il est utilisé pour spécifier, visualiser, modifier et construire les documents nécessaires au bon développement d’un logiciel orienté objet. UML est couramment utilisé dans les projets logiciels. Les différents éléments sont :
• Activité d’un objet/logiciel.
• Acteurs.
• Processus.
• Schéma.
• Composants logiciels.
• Réutilisation de composants.
Grâce aux outils de modélisation UML, il est également possible de générer automatiquement une partie code, par exemple en langage Java, à partir des divers documents réalisés.

Le Modèle Incrémental et Itératif

La phase d’étude est la partie la plus importante pour tout projet réussi. On s’est basé durant la réalisation de notre application à des normes universelles durant la conception, en particulier le respect des principes du Modèle Incrémental.
Figure 4: Cycle de vie Modèle Incrémental et Itératif
Figure 5: Les incréments du Modèle Incrémental et Itératif
 Le projet de développement est découpé en plusieurs petits projets.
 Chaque projet représente une itération qui:
 Donne lieu à un incrément (version du produit).
 Prend en charge une partie des besoins.
 Répond à un ensemble de risques.
• Le développement se déroule en plusieurs itérations.
• Le projet est décomposé en un noyau et plusieurs incréments.
• Chaque incrément est développé séparément ou en parallèle

Les avantages du Modèle Incrémental et Itératif

• Flexibilité (agilité) vis à vis de nouveaux besoins ou des changements.
• Pas de blocage en cas de spécifications incomplètes.
• Meilleure testabilité.
• Découverte de malentendu assez tôt pour les corriger.
• Répartition de l’effort dans le temps.
• Objectifs réduits et clairs.
• Utilisation de l’approche «diviser pour régner».
• Le client rentre en relation avec le produit très tôt.

Les inconvénients du Modèle Incrémental et Itératif

• Difficultés de gestion du projet.
• Difficultés de contrôle qualité.
• Exigence d’une bonne planification et d’une bonne conception.
• Exigence d’une vision sur le produit fini pour bien diviser en incréments.

Les incréments principaux du projet

Notre projet est constitué des incréments principaux suivants:
• Incrément gestion d’inventaire
 Gestion des matériels
 Gestion des logiciels
 Gestion des périphériques
 Gestion de réseau
• Incrément gestion d’utilisateurs.
• Incrément gestion de techniciens.
• Incrément gestion de postes.
• Incrément gestion de tickets.

Le Modèle MVC (Modèle-Vue-Contrôleur)

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.
Figure 6: Architecture du modèle MVC

Définition MVC (Modèle-Vue-Contrôleur)

Le modèle :

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.

Le 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

• Une conception claire et efficace grâce à la séparation des données de la vue et du contrôleur.
• Un gain de temps de maintenance et d’évolution du site.
• Une plus grande souplesse pour organiser le développement du site entre différents développeurs
(indépendance des données, de l’affichage et des actions

Modélisation du contexte

Description des acteurs

C’est l’étape initiale qui consiste { faire un recensement sur les différents acteurs qui vont interagir de prés ou de loin avec le système. Mais avant d’aller plus loin, il est important de définir certains termes importants pour la suite.
• acteurs : constitue une entité physique capable d’interagir avec le système .Notons juste que cette entité peut être humaine ou matérielle
• système : c’est l’entité { concevoir, dans notre cas il s’agit de l’application en elle-même.
Cette section a pour objet de présenter les acteurs et leurs fonctionnalités à lesquelles doit répondre notre application. Nous commençons notre analyse par identifier les acteurs qui agissent sur ce système à savoir :
Figure 7: Les acteurs de l’application
L’administrateur : Joue un rôle primordial dans l’assurance du bon fonctionnement du système.
C’est la personne qui prend en charge la gestion de tous les incréments de l’application.
L’utilisateur : A le droit de visualiser les composants de son poste au niveau du matériel , logiciel et réseau ainsi de créer des tickets et visualiser leurs suivis .
Le technicien : Prends en charge le traitement des tickets.
La figure ci-dessous illustre parfaitement ces différents acteurs ainsi leurs interactions avec le système qui se représente sous forme de trait reliant les acteurs concernés au système.
Figure 8: Interaction des acteurs avec le système
Cette représentation est incomplète car le système ainsi représenté constitue une sorte de « boite noire » dont on ne connait en rien le fonctionnement. Il est donc nécessaire de passer par une représentation plus détaillé, c’est ce qui fait l’objet de la partie suivante.

 La branche fonctionnelle

Besoins fonctionnels

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.

Besoins non fonctionnels

Après avoir déterminé les besoins fonctionnels, nous présentons ci-dessous l’ensemble des contraintes { respecter pour garantir le bon fonctionnement du système. Il est { noter cependant qu’ils peuvent être exprimés en matière de performance, de type de matériel ou le type de conception. Dans le cadre de notre travail,

Analyse et Conception

Nous parvenons { une étape clé du processus. C’est elle qui grâce { l’étude réalisée dans la partie précédente mettra en valeur le rôle de chaque acteur du système ainsi que les fonctionnalités présentées en haut.

Diagramme de package

C’est un moyen pour regrouper les différents éléments de la modélisation. Il permet de représenter les relations entre les différents profils de l’application. Il rassemble les cas d’utilisations propre { chaque acteur de façon cohérente.

Diagramme 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 ».

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport gratuit propose le téléchargement des modèles gratuits de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie ?avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Abréviations
Introduction générale
Chapitre1 : Contexte du projet
1. Présentation de l’organisme d’accueil
1.1. Présentation d’Inventis
2. Présentation du projet
2.1. Cahier de charge
2.2. Problématique
2.3. Etude de l’existant
2.3.1. Clarilog
2.3.2. H-Inventory
2.4. Critique de l’existant
2.5. Solution proposée
3. Conclusion
Chapitre 2 : Modélisation et conception de la solution proposée
1. Introduction
2. Méthodologie d’analyse
2.1. le langage UML
2.2. le modèle incrémental et itératif
2.2.1. les avantages du modèle incrémental et itératif
2.2.2. les inconvénients modèle incrémental et itératif
2.2.3. les incréments principaux du projet
2.3. Le modèle MVC
2.3.1. Définition
2.3.1.1. Le modèle
2.3.1.2. La contrôleur
2.3.1.3. La vue
2.3.2. Avantages du MVC
3. Modélisation du contexte
3.1. Description des acteurs
3.2. Branche fonctionnelle
3.2.1. Besoins fonctionnels
3.2.2. Besoins non fonctionnels
4. Analyse et conception
4.1. Diagramme de package
4.2. Diagramme de cas d’utilisation
4.3. Diagramme de séquence
4.4. Diagramme de classe
5. Conclusion
Chapitre 3 : Réalisation
1. Introduction
2. Outils et technologies de développement
3. Présentation de l’application
3.1. Schéma principal de l’application
3.2. Authentification
3.3. Gestion de tickets
3.4. Fonctionnalités générales
4. Conclusion
Conclusion et perspectives
Bibliographe et Webographie

Rapport PFE, mémoire et thèse PDFTélécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *