1. 1
Rapport d’un projet de conception
Spécialité : Génie des Systèmes industriels et logistique
Réalise par :
HACHED NESRINE
Année Universitaire : 2017-2018
2. 2
Table des matières
Introductiongénérale
Chapitre I: Analyse et spécificationdes besoins
Introduction
I-Méthodologie
II- Analyse des besoins
1) Besoins fonctionnels
2) Besoins nonfonctionnels
3) Besoins technique
III- Spécificationdes besoins
1) Diagramme de cas d’utilisationgénérale
2) Diagramme de cas d’utilisationraffinés
3) diagramme de séquence
Conclusion
Chapitre II : Conception
Introduction
I -Diagramme de classe
II-Diagramme d’activité
Conclusion
Conclusiongénérale
Bibliographie
3. 3
Table des figures
Figure 1 : Modèle ducycle de vie enV………………………………………………………………………………………………8
Figure 2 : digramme de cas d’utilisation 1……………………………………………………………………………12
Figure 3 : digramme de cas d’utilisation 2……………………………………………………………………………12
Figure 4 : diagramme de cas d’utilisation 3………………………………………………………………………….13
Figure 5 : diagramme de cas d’utilisation 4………………………………………………………………………….13
Figure 6 : diagramme de cas d’utilisation 5………………………………………………………………………….14
Figure 7 :Diagramme de cas d’utilisation raffiné <<gestion des achats >>…………………….…….14
Figure 8 : l’interface de gestion des produits……………………………………………………………………….15
Figure 9 : l’interface de page d’authenfication ……………………………………………………………………18
Figure 10 : l’interface de passer la commande ………………………………………………………………….19
Figure 11 : l’interface de la gestion des clients ……………………………………..…………………………….19
Figure 12 : diagramme de séquence <<s’authentifier >>……………………………………………………..22
Figure 13 : diagramme de séquence << Pomper de l’essence>>………………………………………….23
Figure 14 : diagramme de séquence << acheter produit>>………………………………………..………..23
Figure 15 : Diagramme de séquence « ajouter des achats »……………………………………………….……24
Figure 16 : Diagramme de séquence « modifier des achats »………………………………..……………25
Figure 17 : Diagramme de séquence « supprimer des achats »………………………………………….26
Figure 18 : diagramme de classe……………………………………………………………………28
Figure 19 : diagramme d’activité <<acheter produits >>………………………………….…………………….…….29
Figure 20 : diagramme d’activité de <<s’authentifier >>………………………………………………….…………29
Figure 21 : diagramme d’activité de <<ajouterdes achats >>…………………………………………………...30
Figure 22 : diagramme d’activité de <<modifier des achats >>………………………………………………….30
Figure 23: diagramme d’activité de <<supprimer desachats >>………………………………………………31
4. 4
Liste des tableaux
Tableau 1 : tableau des besoins fonctionnels……………………………………….…………………….……..10
Tableau 2 : description du cas d’utilisation <<pomper de l’essence>>…………………………….….15
Tableau 3 : description du cas d’utilisation <<acheter des pneumatiques>>…………………….…16
Tableau 4 : description du cas d’utilisation <<ajouter des achats >>……………………………………16
Tableau 5: description du cas d’utilisation <<modifier les achats >>……………………………………17
Tableau 6 : description du cas d’utilisation <<supprimer un achat >>………………………………….17
Tableau 7 : description du cas d’utilisation <<consulter des achats >>……………………………….17
Tableau 8 : description du cas d’utilisation <<acheter des produits >>………………………….…….18
Tableau 9 : description du cas d’utilisation <<prendre un café >>………………………………………20
Tableau 10 : description du cas d’utilisation <<commander un repas >>…….……………………..20
Tableau 11: description du cas d’utilisation <<s’authentifier >>…………………………………………21
5. 5
Introductiongénérale :
Grâce aux privilèges de l'informatique, le monde se transforme de plus en plus en petit
village.
L'informatique est devenue un élément indispensable pour l'évolution de l'univers dont
l'homme a toujours cherché à mieux donner et cela à travers plusieurs inventions des
différentes machines depuis l'antiquité.
Aujourd'hui, l'homme est parvenu au delà de sa conception à créer une machine pouvant lui
permettre le traitement automatique et rationnel des informations à l'aide des programmes
enregistrés dans son outil précieux appelé ordinateur.
A présent, toutes les entreprises sont intéressées par cet outil, pour assouplir leurs gestions,
d'où, c'est avec ce même moyen de traitement des informations que nous allons réaliser une
conception qui permettra d’informatiser le système d’une station de service.
Ce travail est organisé en deux chapitres :
Le premier chapitre intitulé Analyse et spécification des besoins porte sur l’analyse
des besoins fonctionnels, non fonctionnels et les besoins techniques.
Le deuxième chapitre intitule Conception est consacre diagramme de classe ainsi que la mise
en ouvre des diagrammes d’activités.
Enfin, une conclusion générale, qui synthétise mon rapport.
7. 7
Introduction
Dans le présent chapitre nous entamons la phase d’analyse et de spécification des besoins
nécessaires qui nous permet de comprendre le système.
Afin d’assurer une solution de qualité pour notre système, répondant aux standards et aux
normes de développement, nous devons suivre une méthodologie de développement pour
mieux cerner nos besoins et assurer une progression selon les délais.
A ce titre, nous allons présenter les différents outils que nous avons utilisés.
I-Méthodologie
Les systèmes de nos jours sont de plus en plus complexes. Les concepteurs tentent à remédier
à cette complexité en offrant des démarches à suivre des étapes bien précises.
Pour faire ce faire, nous avons opté le cycle de vie en v pour le développement de notre
système, tout en nous appuyant sur les outils du langage uml.
La représentation en V tient d'avantage compte de la réalité, le processus de développement
n'est pas réduit à un enchaînement de tâches séquentielles. Elle montre que:
- c'est en phase de spécification que l'on se préoccupe des procédures de qualification.
- c'est en phase de conception globale que l'on se préoccupe des procédures d'intégration.
- c'est en phase de conception détaillée que l'on prépare les tests unitaires.
Le modèle de cycle de vie en V permet d'anticiper sur les phases ultérieures de
développement du produit.
En particulier le modèle en V permet de commencer plus tôt: - Plan de tests de qualification,
- Plan d'évaluation des performances.
Ce modèle permet de développer parallèlement différents modules lorsque la phase de
conception globale est validée.
8. 8
Figure 1: Modèle du cycle de vie en V
II - Analyse des besoins
1-Les besoins fonctionnels
Les besoins fonctionnels représentent les fonctionnalités d’un système.
Ce sont les besoins spécifiant un comportement d’entrée/sortie du système, ces besoins sont
classés par acteurs :
Le client : c’est un acteur qui a beaucoup des services à choisir selon son besoin.
Le pompiste : c’est employé de station-service qui est préposé au fonctionnement d'un
appareil de distribution de carburant.
Agent d’entretien : L'agent d'entretien de service réalise les travaux de nettoyage ou toute
autre tâche d'exécution simple liée à la véhicule.
Agent de maintenance : c’est une personne qui a pour mission d’assurer le bon
fonctionnement des machines.
9. 9
Responsable boutique : c’est une personne qui travaille quotidiennement au développement
de la clientèle de son magasin.
Manager de la station : c’est un acteur qui doit gérer la station.
les acteurs Besoins fonctionnelles
Client *pomper de l’essence
*presser la gâchette
*détacher le pistolet de l’étui
*ranger le pistolet dans l’étui
*laver la voiture : (lavage a rouleau c'est-à-
dire automatiquement ou bien lavage a
haute pression)
*faire la vidange de sa voiture
*acheter des pneumatiques pour sa voiture
*acheter des produits (alimentaire,
d’hygiène, lubrifiant ou les produits
d’entretien)
*commander un repas dans le restaurant
*prendre un café
*payer le type de carburant (*payer par la
carte,*payer par carte bancaire,*payer
espèces, *payer par cheque,* par carte
fidélité)
Le pompiste *armer la pompe
*vérifier les cuves
Agentde maintenance *contrôler le distributeur
*nettoyer le distributeur
Agentd’entretien *poser les pneumatiques pour toutes types
de véhicules
*vérifier le niveau d’eau
*vérifier le niveau d’huile
*vérifier l’état de système de freinage
Responsable boutique *organiser l’accueil de la clientèle
*participer a la vente
*s’assurer de la bonne tenu du boutique
(rangement, propreté, présentation etc..)
*réaliser les ouvertures et les fermetures
*consulter stock
*effectuer la gestion administrative du
magasin (=passer les commandes, suivre les
10. 10
facturations etc..)
*contrôler la caisse
Manager de la station *payer les commandes
*gérer les stocks du carburant
*gérer les achats
*gérer les clients
*saisir les factures
Tableau 1 : tableau des besoins fonctionnels
2-les besoins non fonctionnels
Le système doit répondre a un certains besoins qui ne sont pas indispensable pour son
fonctionnement mais qui sont importants pour la qualité de ses services.
Les besoins non fonctionnels sont importants car ils agissent de façon indirecte sur le
résultat et sur le rendement de l’utilisateur.
Donc les besoins non fonctionnels sont :
Besoin de performance : le système devra répondre rapidement aux besoins de
l’utilisateur. Le temps de réponse de l’application doit être minimal.
Besoin de précision : le système doit être très précis.
Il doit fonctionner correctement lors de la demande de l’utilisateur.
Besoin de sécurité : le système doit être sécurisé, les informations de chaque
utilisateur doivent donc être protégées. C’est pour cela chaque utilisateur a un
identifiant et un mot de passe.
L’agronomie de l’application : l’interface de l’application doit être simple, facile et
accessible à tout les gens intéressé de la station de service.
3-les besoins techniques
J’ai utilisé le logiciel d’uml agro pour modéliser les diagrammes des cas d’utilisations,
les diagrammes de séquences, les digrammes d’activités et le diagramme de classe.
11. 11
J’ai utilisé le logiciel Balsamiq pour produire des maquettes IHM.
II- Spécificationdes besoins
1- Digrammede cas d’utilisation
Les cas d’utilisations et les acteurs du système sont schématises dans les
diagrammes ci-dessous ainsi que l’interaction entre les cas d’utilisation et les acteurs.
On a au total 5 diagrammes :
Les diagrammes de cas d’utilisation généralisé
12. 12
Figure 2 : digramme de cas d’utilisation 1
Figure 3 : digramme de cas d’utilisation 2
13. 13
Figure 4 : diagramme de cas d’utilisation 3
Figure 5 : diagramme de cas d’utilisation 4
14. 14
Figure 6: diagramme de cas d’utilisation 5
2-diagrammeraffinede cas d’utilisation
Le diagramme raffiné est ci-dessous :
Figure 7 :Diagramme de cas d’utilisation raffiné <<gestion des achats >>
15. 15
Cette vue représente l’interface de gestion des produits
Figure 8 : l’interface de gestion des produits
Description textuelle des cas d’utilisation :
Cas d’utilisation Pomper de l’essence
Acteur Client
Pré_condition Client authentifié
Post-condition Client servi
Scénarionominal 1-prendre le pistolet
2- choisir le type de carburant
3-saisir le montant
4-montant valide
5-appuyer sur la gâchette
6-Pomper essence
7-rendre le pistolet
8-choisir le mode de paiement
9-payer
Tableau 2 : description du cas d’utilisation <<pomper de l’essence>>
16. 16
Cas d’utilisation Acheter des pneumatiques
Acteur Client
Pré_condition Client authentifié
Post-condition Pneumatique acheté
Scénarionominal 1-consulter le catalogue des pneumatiques
2-choisir le type de pneumatiques
3-choisir le nombre de pneumatiques
4-choisir le mode de paiement
5-passer la commande
6-payer
Tableau 3 : description du cas d’utilisation <<acheter des pneumatiques>>
Cas d’utilisation Ajouter des achats
Acteur Manager de station
Pré_condition Manager authentifié
Post-condition Achat ajouté
Scénarionominal 1-le manager choisit l’ajout d’un nouvel
achat.
2- Le système affiche le formulaire à remplir.
3-le manager saisit les coordonnées du
nouvel achat.
4-Le système vérifie les données.
5- Le système enregistre l’utilisateur dans la
base des données.
Tableau 4 : description du cas d’utilisation <<ajouter des achats >>
17. 17
Cas d’utilisation Modifier des achats
Acteur Manager de station
Pré_condition Manager authentifié
Post-condition Achat modifie
Scénarionominal 1-le manager choisit la « liste des achats ».
2- Le système affiche la liste.
3-le manager choisit la modification d’un
achat.
4-Le système affiche le formulaire de
modification.
5-le manager modifie les coordonnées des
achats .
6-Le système demande la validation de
modification.
7-le manager valide la modification.
8- Le système vérifie les données.
9-Le système enregistre les modifications .
Tableau 5: description du cas d’utilisation <<modifier les achats >>
Cas d’utilisation Supprimer un achat
Acteur Manager de station
Pré_condition Manager authentifié
Post-condition Achat supprime
Scénarionominal 1-le manager choisit la « liste des achats».
2-Le système affiche la liste.
3-le manager choisit la suppression d’un
achat.
4-Le système demande la validation de
suppression.
5- le manager valide la suppression.
6-Le système effectue la suppression.
Tableau 6 : description du cas d’utilisation <<supprimer un achat >>
Cas d’utilisation Consulter des achats
Acteur Manager de station
Pré_condition Manager authentifié
Post-condition Les achats affichés
Scénarionominal 1-le manager choisit les achats à visualiser et
clique sur le bouton consulter
2-Le système affiche les achats
Tableau 7 : description du cas d’utilisation <<consulter des achats >>
18. 18
Cas d’utilisation Acheter des produits
Acteur Client
Pré_condition Client authentifié
Post-condition Produit acheté
Scénarionominal 1-consulter le catalogue des produits
2-choisir le catégorie de produit
3-choisir le produit
4-choisir la quantité a acheté
5-choisir le mode de paiement
6-passer la commande
7-payer
Tableau 8 : description du cas d’utilisation <<acheter des produits >>
Cette vue représente l’interface de l’authentification de l’utilisateur
Figure 9 : l’interface de page d’authenfication
19. 19
Cette vue représente l’interface de passer la commande
Figure 10 : l’interface de passer la commande
Cette vue représente l’interface de la gestion des clients
Figure 11 : l’interface de la gestion des clients
20. 20
Cas d’utilisation Prendre un café
Acteur Client
Pré_condition Client authentifié
Post-condition Café acheté
Scénarionominal 1-consulter le catalogue du café
2-choisir le type de café
3-choisir la quantité
4-choisir le mode de paiement
5-passer la commande
6-payer
Tableau 9 : description du cas d’utilisation <<prendre un café >>
Cas d’utilisation Commander un repas
Acteur Client
Pré_condition Client authentifié
Post-condition Repas commande
Scénarionominal 1-consulter le catalogue des repas
2-sélectionner un repas
3-choisir la quantité
4-fournir des informations sur le paiement
5-passer la commande
6-payer
Tableau 10 : description du cas d’utilisation <<commander un repas >>
21. 21
Cas d’utilisation S’authentifier
Acteur Manager de station
Pré_condition Le système doit être lancé
Post-condition Manager authentifié
Scénarionominal 1-le système affiche le formulaire
d’authentification
2-le manager saisit son login et son mot
de passe
3-le système vérifie la conformité des
informations
4-le système donne l’accès a l’interface
correspondante
Tableau 11: description du cas d’utilisation <<s’authentifier >>
22. 22
3-diagrammede séquence
L’objet du diagramme de séquence est de représenter les interactions entre les
objets en indiquant la chronologie des échanges. Cette représentation peut se
réaliser par un cas d’utilisation en considérant les différents scenarios associés.
Figure 12 : diagramme de séquence <<s’authentifier >>
23. 23
Ce diagramme décrit l’enchainement d’exécution du cas <<pomper l’essence >>
Figure 13 : diagramme de séquence << Pomper de l’essence>>
Ce diagramme décrit l’enchainement d’exécution du cas << acheter produit >>
Figure 14 : diagramme de séquence << acheter produit>>
24. 24
Ce diagramme décrit l’enchainement d’exécution du cas << ajouter des achats >>
Figure 15 : Diagramme de séquence « ajouter des achats »
25. 25
Ce diagramme décrit l’enchainement d’exécution du cas << modifier les achats >>
Figure 16 : Diagramme de séquence « modifier des achats »
26. 26
Ce diagramme décrit l’enchainement d’exécution du cas << supprimer des achats >>
Figure 17 : Diagramme de séquence « supprimer des achats »
Conclusion
L'objectif de ce chapitre est de mettre l'application dans son cadre conceptuel. Elle doit
fournir des indications précises pour ce projet : les besoins fonctionnels et non fonctionnels,
et les besoins techniques permettant l'avancement de projet dans le temps.
C’est cela nous allons modéliser le système à travers la partie conceptuelle dans le chapitre
prochain.
28. 28
Introduction
Dans ce chapitre nous allons présenter en détail la conception du projet a travers les
diagrammes uml suivants les diagrammes de cas d’utilisation, le diagramme de classe et
enfin les diagrammes d’activité.
I -Diagramme de classe
Le diagramme de classes est considéré comme le plus important de la modélisation orientée
objet.
Il permet de fournir une représentation abstraite des objets du système qui vont interagir
ensemble pour réaliser les cas d’utilisation.
Figure 18 : diagramme de classe
29. 29
II-Diagramme d’activité
Le diagramme d’activité permet de représenter le déclenchement d’événement en fonction
des états de système et de modéliser des comportements pouvant être parallèle.
Figure 19 : diagramme d’activité <<acheter produits >>
Ce diagramme décrit l’enchainement de la vérification de l’identité de l’utilisateur avant de lui
donner l’accès a l’interface correspondante .
Figure 20 : diagramme d’activité de <<s’authentifier >>
30. 30
Apres l’authentification le manager de station peut ajouter des nouveaux achats d’après
l’enchainement suivant :
Figure 21 : diagramme d’activité de <<ajouter des achats >>
Figure 22 : diagramme d’activité de <<modifier des achats >>
31. 31
Figure 23: diagramme d’activité de <<supprimer des achats >>
Conclusion
Dans ce chapitre, on a pu modéliser le système de gestion d’une station de service et déduire
le modèle relationnel qui constitue la base de données pour la réalisation de notre
application.
32. 32
Conclusiongénérale :
Afin de répondre aux problèmes des utilisateurs pour gérer une station de service, Nous
avons besoin d’un système de gestion qui facilite les tâches exécutés et qui permet de gagner
le temps.
C’est mon objectif durant ce projet. Dans lequel nous avons présenté les différentes étapes de
réalisation d’une application de gestion de station de service.
En premier lieu nous avons mené la spécification des besoins accompagné des diagrammes
de cas d’utilisation nous avons utilisé le langage uml (unified modeling language) vu sa
richesse, puissance et la dynamique qu’il offre via ses différentes diagrammes.
Ce dernier permet de décrire les fonctionnalités complètes du système ensuite la conception
des diagrammes de classes et d’activités.
Enfin, Ces étapes m’ont aident à améliorer mes compétences au niveau d'analyse et de
conception.
