developpement d'une applivcation web pour le reapprovisionnement de station station-service ceci contient les Besoins fonctionnels et non fonctionnels d'une application de gestion de gestion de station-service
1. Introduction
L’étape de conception définit généralement les structures et les modèles à suivre lors de la
phase d’implémentions de l’application en utilisant le langage UML. C’est la phase où nous
préparons l’architecture du projet, et où nous définissons la structure de l’application, nous
allons premièrement citer les besoins fonctionnels et non fonctionnels de cette application
Deuxièmement, nous décrirons la phase de réalisation et les outils utilisés pour le
développement de l’application, nous décrirons le travail effectué à travers des captures
d’écran et nous finissons par une conclusion.
1. Besoins fonctionnels
Il s’agit de fonctionnalités de système. Ce sont les exigences pour spécifier le
comportement d’entrée/sortie du système. Les services proposés par notre application
peuvent être résumés en :
Gestion des stocks :
Suivre les niveaux de stock de différents types de carburants dans les entrepôts et les stations-
service.
Permettre l'ajustement des stocks en fonction des livraisons et des ventes.
Gestion des livraisons :
Enregistrer les détails des livraisons de carburant effectuées aux stations-service.
Planifier les livraisons en fonction des niveaux de stock actuels et des prévisions de
demande.
Gestion des ventes :
Enregistrer les transactions de vente de carburant dans les stations-service.
Fournir des rapports sur les ventes quotidiennes, hebdomadaires et mensuelles.
Outil d'aide à la décision :
Analyser les données historiques pour prédire la demande future de carburant.
Proposer des recommandations de livraison basées sur les prévisions de demande et
les niveaux de stock actuels.
Gestion des utilisateurs :
Authentifier les utilisateurs et attribuer des rôles appropriés (administrateur,
gestionnaire, employé, etc.).
Gérer les autorisations d'accès aux différentes fonctionnalités de l'application.
2. Besoins non fonctionnels :
Les besoins non fonctionnels forment l’ensemble des contraintes techniques auxquelles notre
système doit répondre.
2. Sécurité :
Mettre en place des mesures de sécurité robustes pour protéger les données sensibles
des utilisateurs, y compris les informations sur les stocks, les commandes et les
livraisons.
Utiliser des mécanismes d'authentification et de cryptage pour garantir l'intégrité et la
confidentialité des données transitant par l'application.
Performance :
Assurer des temps de réponse rapides et une disponibilité élevée de l'application,
même lors de l'accès simultané de plusieurs utilisateurs.
Optimiser les requêtes et les opérations de traitement pour minimiser les temps de
latence et maximiser l'efficacité de l'application.
Fiabilité :
Le système doit être disponible à la demande par l’utilisateur, ainsi qu’assurer une
gestion exhaustive des erreurs.
La rapidité :
Le temps de traitement doit être suffisamment court pour garantir l’accès souhaitable
aux informations.
3. Conception
Nous utiliserons UML pour créer les diagrammes nécessaires pour définir la structure
générale de l’application. UML (Unified Modeling Langage) est une approche oriente objet
de modélisation qui permet de modéliser un problème d’une manière standard. Le langage
définit neufs diagrammes pour représenter les différents points de vue de la modélisation. Ils
permettent de visualiser et de manipuler les éléments de la modélisation, ces diagrammes
seront classifiés selon leur but en deux vues.
- Vue Statique : Représenter par des diagrammes qui définissent l’avis statique de conception
(les diagrammes des cas d’utilisations, les diagrammes de classes, les diagrammes d’objet).
- Vue Dynamique : La vue dynamique est orientée algorithme et traitement, elle vise à
décrire l’évolution (la dynamique) des objets complexes du programme tout au long de leur
cycle de vie. De leur naissance à leur mort, les objets voient leurs états changés et ce à cause
de leur interaction avec d’autres objets du programme.
3.1 Vue statique de l’application
3.1.1 Modèle cas d’utilisation
La vue de cas d’utilisation joue un rôle particulier en ce qui concerne l’architecture. Elle
contient quelques scénarios ou des cas d’utilisation qui sont utilisés initialement pour la
découverte et la conception de l’architecture lors de la création et l’élaboration des phases,
3. mais plus tard, ils seront utilisés pour valider les différentes vues du système. Un scénario est
un chemin particulier à travers la description abstraite et générale fournie par le cas
d’utilisation. Les cas d’utilisation donnent une vue d’altitude des interactions visibles d’un
système, ils ne fournissent pas d’informations sur la structure interne. Ils mettent en évidence
les rôles de ses utilisateurs, et contribuent à catégoriser ces derniers, définir leurs attentes
(objectifs du système) et leurs obligations (pilotage du système). La recherche des cas
d’utilisation permet, en particulier, de formaliser les réponses aux questions : "Pourquoi" (les
intentions du système) et "Pour qui" (les acteurs).
Les acteurs : Un acteur représente l’abstraction d’un rôle joué par des entités externes qui
interagissent directement avec le système. Pour notre application, il y aura
4. Acteur Description Rôles et Responsabilités
Acteurs Principaux
Administrateur Responsable de la
gestion globale du
système.
- Crée, modifie et supprime
des comptes utilisateur. -
Gère les informations des
stations-service et des
camions-citernes. - Accède
aux rapports et statistiques
sur les ventes et les stocks.
station-service Responsable de la
gestion opérationnelle
d'une ou plusieurs
stations-service.
- Gère les stocks de
carburant. - Enregistre les
ventes de carburant. -
Planifie les livraisons de
carburant. - Coordonne les
activités des chauffeurs de
camion-citerne.
Acteurs Secondaires
Conducteur de Camion-Citerne Livraison des carburants
aux stations-services
selon les ordres de
réapprovisionnement.
Recevoir les ordres de
livraison, suivre les
itinéraires, effectuer les
livraisons, mettre à jour les
informations de livraison
dans le système.
Personnel de Maintenance Maintenance préventive
et corrective des
équipements de stockage
et de distribution de
carburants.
Effectuer la maintenance
préventive, diagnostiquer et
réparer les pannes, assurer le
bon fonctionnement des
équipements.
Responsable de la Sécurité et de
la Conformité
Veiller au respect des
normes de sécurité et de
réglementation dans les
opérations de
réapprovisionnement.
Effectuer des inspections de
sécurité, assurer la
conformité réglementaire,
mettre en œuvre des mesures
de prévention des risques.
Planificateur : Employé chargé de planifier les réapprovisionnements en carburants pour les
stations-services du réseau.
Gestionnaire de Station-Service : Responsable d'une station-service, chargé de formuler les
requêtes de réapprovisionnement.
Système de Gestion de Stock : Système informatique qui enregistre et surveille les niveaux
de stock de carburant dans les cuves des stations-services.
5. Scenario de l’application
Le gestionnaire de la station-service observe que le niveau de remplissage des cuves
atteint le seuil de sécurité.
Le gestionnaire se connecte à l'application de gestion des réapprovisionnements.
Le système affiche les informations sur la station-service, y compris les niveaux de
stock actuels et les historiques de consommation.
Le gestionnaire vérifie les informations et confirme la requête de
réapprovisionnement.
Le système enregistre la requête et la transmission au préalable.
Le instantanément reçoit la requête de réapprovisionnement dans le tableau de bord de
l'application.
Le analyser soigneusement les différentes requêtes de réapprovisionnement en cours et
spécifiquement les besoins de chaque station-service en tenant compte des facteurs tels
que les niveaux de stock actuels, les historiques de consommation, les prévisions
météorologiques et les contraintes de livraison.
Le privilégier utilise des algorithmes d'optimisation intégrés dans l'application pour
déterminer les quantités optimales de carburants à livrer à chaque station-service.
Le confirmer confirmer les ordres de réapprovisionnement générés par le système.
Le système envoie automatiquement les ordres de réapprovisionnement aux camions
citernes pour la livraison.
Les camions citernes reçoivent les ordres de réapprovisionnement et se dirigent vers
les stations-services pour effectuer les livraisons.
Les conducteurs des camions citernes utilisent des applications mobiles connectées au
système pour suivre les itinéraires, les quantités de carburants à livrer et les mises à
jour en temps réel.
Les livraisons sont effectuées selon les ordres de réapprovisionnement confirmés.
Les niveaux de stock des stations-services sont mis à jour dans le système après
chaque livraison.
Le système génère des rapports périodiques sur les réapprovisionnements effectués,
les niveaux de stock actuels, les tendances de consommation et les performances des
livraisons.
Le surveiller utiliser ces rapports pour ajuster les prévisions de réapprovisionnement,
optimiser les itinéraires de livraison, et améliorer les processus de gestion des stocks.
Le cycle de planification et de livraison continue de manière itérative pour assurer un
approvisionnement efficace et flexible en carburants.
Diagramme de Ca d’Utilisation
7. Dans ce diagramme :
Une StationService peut être associée à un seul GestionnaireStock (1-1).
Un GestionnaireStock peut gérer plusieurs StationService (1-*).
Un GestionnaireStock est associé à un SystemeGestionStock (1-1).
Un SystemeGestionStock surveille et met à jour les niveaux de stock.
Une StationService peut formuler une CommandeStock (1-*) pour un
réapprovisionnement.
Chaque Commande Stock comprend un identifiant et une quantité de carburant à
commander.
Ce diagramme illustre clairement les associations entre les différentes classes de l'application
de gestion des réapprovisionnements en carburants. Chaque association est indiquée par une
ligne reliant les classes concernées, avec des multiplicateurs indiquant les cardinalités de
l'association.