Stan Bruyere

Projet 4

Analysez les besoins de votre client pour son groupe de pizzerias

Table des matières
I.Le contexte.................................................................................................4
1)Les acteurs ...................................................................................................................................4
2)Les interactions possibles.............................................................................................................5
Diagramme de contexte...............................................................................................................6
II.Les fonctionnalités...................................................................................7
1)Les packages.................................................................................................................................7
Diagramme de package...............................................................................................................8
2)Les cas d'utilisation....................................................................................................................10
Cas d'utilisation principale........................................................................................................11
Cas d’utilisation détaillés .........................................................................................................11
III.Les règles de gestion fonctionnelles......................................................13
Cas d'utilisation : Consulter la carte .........................................................................................13
Cas d'utilisation : Valider une commande.................................................................................16
IV.Processus détaillé de prise de commande.............................................19
Diagramme d'activité................................................................................................................22
Diagramme d’état-transition ....................................................................................................23
V. Déploiement de la solution....................................................................24
Diagramme de déploiement......................................................................................................24
VI. Description du domaine fonctionnel...................................................24
Diagramme de classes...............................................................................................................24
Définition des objets.................................................................................................................26
Modèle physique de données....................................................................................................27
 La demande

« OC Pizza » est un jeune groupe de pizzeria en plein essor et spécialisé dans les pizzas
livrées ou à emporter. Il compte déjà 5 points de vente et prévoit d’en ouvrir au moins 3
de plus d’ici la fin de l’année. Un des responsables du groupe a pris contact avec vous
afin de mettre en place un système informatique, déployé dans toutes ses pizzerias et
qui lui permettrait notamment :

• d’être plus efficace dans la gestion des commandes, de leur réception à

leur livraison en passant par leur préparation ;
• de suivre en temps réel les commandes passées et en préparation ;
• de suivre en temps réel le stock d’ingrédients restants pour savoir quelles
pizzas sont encore réalisables ;
• de proposer un site Internet pour que les clients puissent :
◦ passer leurs commandes, en plus de la prise de commande par
téléphone ou sur place,
◦ payer en ligne leur commande s’ils le souhaitent – sinon, ils paieront
directement à la livraison
◦ modifier ou annuler leur commande tant que celle-ci n’a pas été
préparée
• de proposer un aide mémoire aux pizzaïolos indiquant la recette de
chaque pizza

Notre proposition

Pour répondre à vos besoins, nous allons réaliser une solution, composée de trois
systèmes répondant aux spécifications fonctionnelles étudiées dans ce document.
• Le site internet,( le Front-End) sera à développer en HTML/CSS
• L'application ou progiciel (le Back-End) sera à développer en
Python/Django
• Une base de données de type MySQL pour stocker nos différentes
données .

Le site internet permettra d'être plus efficace dans la gestion des commandes , il
permettra aux clients de passer commande et de suivre en temps réel le statut de leurs
commandes, le progiciel permettra aux employés de passer commande , de suivre
l'avancé de chaque commande, de gérer le stock, et de proposer une aide mémoire aux
pizzaïolos, la base de données hébergera des informations sur les clients, le stock, et
les commandes, qui pourront être consultées en temps réel.
 I. Le contexte

1) Les acteurs
Un acteur correspond à une entité qui aura une interaction avec le système.

2) Les interactions possibles

• Client
◦ Peut consulter la carte
◦ Peut constituer un panier
◦ Doit se créer un compte
◦ Peut passer commande (en ligne, par téléphone ou sur place)
◦ Peut suivre le statut de sa commande
◦ Peut modifier ou annuler sa commande tant que celle ci n'est pas en
préparation
◦ Peut payer en ligne ou à la réception (en ligne en CB ou par chèque et
espèces)

• Manager/Équipier
 ◦ Peut consulter la carte
◦ Peut constituer un panier
◦ Peut choisir un client existant ou créer un compte
◦ Peut passer une commande
◦ Peut suivre le statut des commandes
◦ Peut modifier ou annuler une commande tant que celle ci n'est pas en
préparation
◦ Peut prendre un règlement par téléphone (pour les CB) ou sur place (CB,
chèque, espèces)
◦ Peut consulter et modifier le stock

• Pizzaïolo
◦ Peut consulter les commandes entrantes et leurs statuts
◦ Peut consulter et modifier le stock
◦ Peut consulter une aide mémoire avec les recettes des pizzas
◦ Peut modifier le statut des commandes (passage de «en préparation» à
«prête»)

• Livreurs
◦ Peut modifier le statut des commandes (passage de «prête» à «en
livraison»)
◦ Peut consulter les informations des clients
◦ Peu effectuer une transaction par CB

• Système bancaire (<<système>>)

◦ Peut encaisser un paiement CB en ligne (sur le site ou via le progiciel)
◦ Peut encaisser un paiement CB sur place (via le progiciel)
◦ Peut encaisser un paiement par le livreur (via un terminal de paiement
CB)

La solution bancaire est identifiée : <<Système>>. Cela signifie qu'il s'agit d'un acteur
non humain.
Il est identifié comme acteur secondaire car il n'aura pas besoin d'utiliser directement
notre futur système mais pourra être consulté par le futur système et sera récepteur des
informations de paiement.

Diagramme de contexte
 II. Les fonctionnalités

1) Les packages
Les packages sont des familles de fonctionnalités qui nous permettent de simplifier
notre analyse.

Nous avons identifié les packages suivants pour notre système:

 Diagramme de package

Ici le package Authentification regroupera l'ensemble des actions d'identification

nécessaire à chaque acteur,
Le package gestion du statut ne sera utilisé que par les livreurs et les cuisiniers mais
sera sollicité par le package gestion des commandes et dépendant du package
Authentification.

2) Les cas d'utilisation

 Cas d'utilisation principale

Ces cas d’utilisations sont directement liés à un acteur. Nous y avons décrit ce qu’un
utilisateur doit pouvoir faire grâce au logiciel à développer. Ce sont les fonctionnalités
principales.
 Cas d’utilisation détaillés

Package Gestion de commande :

Package Authentification:
 III. Les règles de gestion fonctionnelles

Cas d'utilisation : Consulter la carte

Identification

Numéro 1
Nom Consulter la carte (package « Gestion des commande »)
Auteur(s) Acheteur (client ou manager)
La consultation de la carte doit être possible pour tout utilisateur
Description
sur le site ainsi que pour l'équipe (manager/équipier) de la
succincte
pizzeria.
Auteur Stan Bruyere
Date(s) 07/05/2018 (première rédaction)
Pré-conditions Aucune
Démarrage L’utilisateur a demandé la page « Voir la carte »

scénario nominal

Étape du scéna
Utilisateur Système
rio
Il affiche une page contenant trois
1. catégories différentes bases de pizza:
Tomate, crème fraîche, barbecue,
Il sélectionne une
2.
des catégories
Il affiche un tableau des pizzas
3.
de cette catégories
Il affiche les ingrédients et une photo
4.
pour chaque pizzas trouvées.
Il sélectionne une pizza
5.
parmi celles affichées.
Il affiche les informations détaillées, le
6. choix parmi les différentes tailles et les
prix
Il quitte la description
7.
détaillée du produit.
Il retourne à l’affichage des pizzas de la
8.
catégorie (retour à l’étape 4).
 Les scénarios alternatifs

Étape du
Utilisateur Système
scénario
Il peut décider de quitter la consultation
2.a
de la catégorie choisie
Il peut décider de quitter la consultation
2.b
de la carte
Il peut décider de quitter la consultation
5.a
des pizzas de la catégorie
Il peut décider de quitter la consultation
5.b
de la carte
Il peut décider de quitter la consultation
7.a
des pizzas de la catégorie
Il peut décider de quitter la consultation
7.b
de la carte

Fin Scénario nominal : aux points 2, 5 ou 7, sur décision de l’acheteur

Post-
Aucun
conditions

Compléments

Afin de permettre à l'acheteur de faire son choix sans changer de page

Ergonomie
les pizzas devront être affichée sous forme de tableau sur une page
Performance La recherche des pizzas, après sélection de la catégorie, doit se faire de
attendue façon à afficher la page en moins de 10 secondes.
Est-ce que l'affichage de la carte nécessite une authentification ?

Est-ce que la consultation de la carte doit être possible uniquement par

catégorie ou est-ce que l’on doit prévoir d’autres critères de recherche
Problèmes de pizza?
non résolus
Doit-on prévoir un affichage trié sur des critères choisis par l'acheteur
(par exemple : par ingrédient, par base...etc) ?

Doit-on prévoir d'autres catégories de base de pizzas ?

 Cas d'utilisation : Valider une commande
Identification

Numéro 2
Nom Valider une commande (package « Gestion des commande »)
Auteur(s) Acheteur (client ou manager)
Description L'acheteur doit pouvoir finaliser l'achat d'une commande. La
succincte validation comprend le choix des pizzas et le règlement de l’achat.
Auteur Stan Bruyere
Date(s) 21/05/2018 (première rédaction)
L’utilisateur doit avoir consulté la carte
Pré-conditions
(package « Gestion des commande »)
Démarrage L'utilisateur constitue un panier

scénario nominal

Étape du scénari
Utilisateur Système
o
Il fait appel au cas d'utilisation
1. « constituer un panier » (package
« gestion de commande »)
Il fait appel au cas d'utilisation
2. « Identification » (package
« Authentification»)
3. Il vérifie le type d’utilisateur connecté
Si l’utilisateur est le manager, il fait appel
4. au cas d’utilisation interne « choisir un
client »
Il affiche les informations concernant le
5.
client
Il fait appel au cas d’utilisation interne «
6.
Saisir information de livraison»
Il fait appel au cas d’utilisation interne «
7.
Enregistrer le règlement»
8. Il enregistre définitivement l’achat
9 Il affiche le récapitulatif de l’achat.

Le dialogue : les scénarios alternatifs

 Étape du
Utilisateur Système
scénario
Il n’affiche aucun utilisateur sélectionné.
Il affiche « Veuillez sélectionner ou créer
4.a
le client concerné par l’achat » (retour à
l’étape 4)
L’enregistrement du règlement n’a pas
réussi. Il récapitule les informations
7.a
dans un message qui est envoyé au
manager. (Arrêt du cas d’utilisation)
L’enregistrement définitif de l’achat n’a
pas réussi.
8.a Il récapitule les informations dans un
message qui est envoyé au manager.
(Arrêt du cas d’utilisation)

• Scénario nominal : sur décision de l’utilisateur, après le point 8

(affichage du récapitulatif de l’achat)
Fin
• Scénario d’exception : après le point 7 ou 8, si l’enregistrement
du règlement ou de l’achat définitif ne réussit pas.
Post-
Aucun
conditions

Compléments

Ergonomie La validation d'une commande doit se faire sur quatre pages minimum
Performance L'utilisateur doit pouvoir modifier ou supprimer sa commande tant que
attendue l'enregistrement définitif n'est pas terminé (étape 8)
Nous supposons que la création d'un panier ne nécessite pas de
Problèmes d'identification. Est-ce que l'affichage de la carte nécessite une
non résolus authentification ?
IV. Processus détaillé de prise de commande

Diagramme d'activité
 Diagramme d’état-transition
permet de décrire le cycle de vie d'une commande
 V. Déploiement de la solution

La solution comportera une application web et un site internet tout deux créés a l'aide
du frameworks Django qui sera la passerelle vers notre base de données
La base de données utilisée pour le fonctionnement de l’application utilisera le SGBD :
MySQL.

Le diagramme suivant récapitule ces informations et présente l’agencement des

différents composants entre eux :

Diagramme de déploiement

VI. Description du domaine fonctionnel

La mise en place de la solution telle que présenté précédemment ainsi que dans
le document détaillant les spécifications fonctionnelles, nécessite de déterminer
les « Objets » (donc les données) qui seront manipulés par le programme.

Diagramme de classes
 Définition des objets
– Pizza : Chaque pizza sera matérialisée par un nom et un prix.

– Ingrédient : La classe ingrédient comprendra comme informations le nom de

l’ingrédient ainsi que le poids d’une « unité ». Cette notion de d'unité sera par la
suite utilisée dans la classe « composition ». Pour chaque pizza, la recette sera
un nombre de d'unité de chaque ingrédient. Le stock sera géré également en
nombre de d'unité .

– Recette : Cette classe aura pour but de contenir le nom de chaque pizza ainsi
qu'un commentaire pour chaque pizza qui pourra être des conseils de
préparation pour chaque pizzas

– Stock : Le Stock sera géré par établissement. La classe stock permettra donc
d’obtenir pour chaque ingrédient, sa quantité pour un établissement donné.
Cette gestion permettra à la fois de gérer les pizzas disponibles pour une
commande dans un établissement donné, mais également par la suite
d’organiser éventuellement des prêts d’ingrédients entre établissements.

– Client : La classe client comprendra toutes les informations nécessaires à

l’identification du client ainsi qu’à la préparation de sa commande,

– Commande : La classe commande est la classe autour de laquelle toute

l’application est tournée. Elle contient les informations nécessaires pour la
gestion des commandes et de ce fait, elle fait le lien avec la quasi-totalité des
autres classes.

– Facture : La facture reprend les éléments essentiels de la commande et y ajoute

des informations qui serviront la gestion administrative des ventes.

– Employé : Tous les types d’employés (préparateur, livreur, vendeur) découleront

d’une même classe abstraite « Employé ». Une classe héritant de celle-ci sera
ensuite créée pour chaque type d’employé permettant l’utilisation
d’informations ou de méthode particulières.

– Variante/Composition : Sont des tables ad hoc matérialisant les liens multiples.

Modèle physique de données