ExpressFood
Sommaire
Cadre du projet
Diagramme de contexte Diagramme de package
Diagramme de cas d’utilisation : création d’une commande Diagramme de séquence : création d’une commande
Diagramme de cas d’utilisation : ajout d’un plat du jour Diagramme de séquence : ajout d’un plat du jour
Diagramme de cas d’utilisation : livraison d’une commande Diagramme de séquence : livraison d’une commande
Diagramme de classes
Modèle physique de données
Base de données
Cadre du projet
Résumé
ExpressFood est une jeune startup qui ambitionne de livrer des plats de qualité à domicile en moins de 20 minutes grâce à un réseau de livreurs à vélo.
Contexte de l’entreprise
Chaque jour, ExpressFood élabore 2 plats et 2 desserts à son QG avec l'aide de chefs expérimentés.
Ces plats sont conditionnés à froid puis transmis à des livreurs à domicile qui "maraudent" ensuite dans les rues en attendant une livraison.
Dès qu'un client a commandé, l'un des livreurs (qui possède déjà les plats dans un sac) est missionné pour livrer en moins de 20 minutes.
Enjeux et objectifs
Sur son application, ExpressFood propose à ses clients de commander un ou plusieurs plats et desserts.
Afin de structurer les données de l’application, il faut d’abord analyser les besoins de celle-ci.
Nous verrons à l’aide de schémas successifs et de plus en plus détaillés les fonctionnalités importantes à l’aide de diagrammes UML.
Ensuite nous pourrons identifier les différentes entités de l’application en structurant notre réflexion avec un diagramme de classe.
Ce dernier sera traduit en modèle physique de données
L’étape finale sera la création d’une base de données et des tests de son fonctionnement.
Diagramme de contexte
A l’aide du diagramme de contexte, nous allons identifier les acteurs qui auront des interactions avec le système.
Le modèle de contexte met en évidence, à un niveau très général, les flux d'information échangés entre les acteurs.
Nous avons identifié deux types d’acteurs : - les acteurs principaux
- Chef (Cuisinier) qui aura le rôle d’administrateur par la suite - Client
- Livreur
- les acteurs secondaires - le système bancaire - le système GPS
Le système étant notre application qui est en cours de développement.
Nous avons pu identifier d’autres systèmes qui interagissent avec notre application :
- système bancaire - système GPS
Diagramme de Package
En avançant dans notre analyse, nous pouvons maintenant identifier les familles de fonctionnalités du système : - la gestion des produits (plats et desserts)
- la gestion des clients - la gestion des commandes - la gestion des livraisons
Nous pouvons observer que l’acheteur peut utiliser plusieurs fonctionnalités.
Nous avons précisé les rôles d’un client (schéma précédent) il peut être un internaute (consultation) et/ ou un acheteur (commandes)
Diagramme de cas d’utilisation “création d’une commande”
Chaque cas d’utilisation reflète le point de vue d’un acteur en particulier.
Un cas d’utilisation représente un ensemble d’actions.
Dans ce cas d’utilisation “création d’une commande” nous pouvons voir les différentes étapes qui démarre par l’action “Visiter l’application” et se termine par
“envoyer confirmation de commande”.
L’acheteur peut s’inscrire s’il ne l’a pas fait auparavant.
Le système bancaire va vérifier la solvabilité de l’acheteur.
Diagramme de séquence “Création d’une commande”
Le diagramme de séquence est une
représentation différente du diagramme de cas d’utilisation.
Il prend en compte la chronologie des actions qui étaient représentées précédemment.
Nous retrouvons nos différents acteurs : - l’internaute dont les actions sont :
- visiter l’application - choisir ses plats
Il deviendra un acheteur quand il sera authentifié sur l’application.
- l’acheteur dont les actions sont : - s’authentifier
- vérifier son adresse de livraison et sa commande
- effectuer son paiement
- l’application enverra des réponses aux différentes actions des acteurs
principaux:
- historique de navigation
- enregistrement du choix des plats - confirmation de l’authentification - validation des informations de
commande et de livraison - confirmation de la commande - le système bancaire vérifiera le paiement.
Descriptif textuel “cas d’utilisation création d’un commande”
Nom : création d’une commande Objectif :
Acteurs principaux : acheteur Acteurs secondaires : le système application et le système bancaire Dates création : 18 décembre 2019 Date de mise à jour :
Responsable : Sonia Panisello Version : 1
Données d’entrée : le cas d’utilisation démarre lorsque que le client visite l’application Scénario nominal :
1. l’acheteur visite l’application
2. le système enregistre l’historique de navigation
3. l’acheteur constitue son panier en choisissant ses plats 4. le système enregistre son panier
5. l’acheteur s’authentifie
6. le système confirme l’identification
7. l’acheteur vérifie sa commande et son adresse de livraison 8. le système valide les informations
9. l’acheteur effectue le paiement
10. le système bancaire vérifie la solvabilité et confirme le paiement 11. le système confirme la commande et indique le délai de livraison Scénario d’exception : client inconnu
6 a. le client n’est pas enregistré. Le système affiche un message d’erreur. Retour à l’étape 5.
Scénario d’exception : transaction échouée
11 a. le système informe que la transaction a échouée et invite l’acheteur à renouveler son paiement. Retour à l’étape 9 Scénario alternatif : nouvelle adresse de livraison
7 a. le client saisit une nouvelle adresse de livraison et valide sa commande. Retour à l’étape 8.
Diagramme de cas d’utilisation : Ajout d’un plat du jour
Dans ce cas d’utilisation “ajout d’un plat du jour”, nous pouvons remarquer que les acteurs concernés sont :
- Chef - Application
Le chef ayant le rôle d’administrateur dans ce projet, il pourra ajouter, modifier,
supprimer un plat du jour.
Chaque jour, il supprimera les plats proposés la veille pour mettre à jour les plats pour la date concernée.
Il y a deux catégorie de produit : - les desserts
- les plats
Diagramme de séquence : Ajout d’un plat du jour
Nous reprenons les mêmes acteurs et
étapes que le schéma précédent mais
dans un ordre chronologique.
Descriptif textuel : cas d’utilisation “ajout d’un plat du jour”
Nom : ajout d’un plat du jour Objectif :
Acteurs principaux : Chef Acteurs secondaires : le système “application”
Dates création : 18 décembre 2019 Date de mise à jour : Responsable : Sonia Panisello Version : 1
Données d’entrée : le cas d’utilisation démarre lorsque que le chef se connecte à l’application.
Scénario nominal :
1. le chef s’identifie à l’application 2. le système confirme l’identification 3. le chef crée un nouveau plat
4. le système enregistre et confirme la création du plat 5. le chef publie ce nouveau plat dans le menu du jour
6. le système enregistre et confirme la publication du nouveau plat Scénario d’exception : chef inconnu identification échouée
2 a. le chef n’est pas reconnu par le système. Le système affiche un message d’erreur. Retour à l’étape 1.
Scénario d’exception : Scénario alternatif :
Diagramme de cas d’utilisation “livraison d’une commande”
Dans ce cas d’utilisation “livraison d’une commande”, nous pouvons remarquer que les acteurs concernés sont :
- Livreur - Application - API GPS
L’API GPS interviendra après la réception de la commande par le livreur, et
transmettra une estimation du délai de livraison à l’acheteur.
Une fois la livraison finalisée l’application passera le statut du livreur à “Libre”.
Diagramme de séquence : livraison d’une commande
Nous reprenons les mêmes acteurs et
étapes que le schéma précédent mais
dans un ordre chronologique.
Descriptif textuel : cas d’utilisation “livraison d’une commande”
Nom : livraison d’une commande Objectif :
Acteurs principaux : livreur Acteurs secondaires : le système application et le système GPS Dates création : 18 décembre 2019 Date de mise à jour :
Responsable : Sonia Panisello Version : 1 Données d’entrée :
Scénario nominal :
1. Le livreur s’identifie dans l’application 2. le système confirme l’identification 3. L’acheteur valide sa commande
4. Le système transmet sa commande au livreur 5. Le livreur réceptionne la commande
6. Le système confirme la réception de la commande 7. Le livreur transmet sa position à l’API GPS
8. L’API GPS transmet une estimation du délai de livraison à l’acheteur 9. Le livreur livre la commande
10. L’application confirme la livraison en cours (statut en cours de livraison) 11. Le livreur indique à l’application que la livraison est finalisée
12. L’application confirme que la livraison est finalisée (statut libre) Scénario d’exception : livraison non finalisée
11 a. La commande est transmise à un autre livreur. Retour à l’étape 4 Scénario d’exception :
Scénario alternatif :
Diagramme de classes
A l’aide du diagramme de classe nous pourrons mettre en évidence les relations entre les différentes entités manipulées par le système.
Modèle Physique de Données
Le modèle physique de données est une représentation différente du diagramme précédent mais il reprend les mêmes informations.
Il s’agit de l’étape intermédiaire avant la création de la base de données.
De nouvelles tables seront créées : Commande_Produit, Position_Livreur.
Elles représentent une clé primaire composée des clés étrangères pointant vers ces tables.
Base de données
La base de données est une représentation différente du diagramme précédent mais il reprend les mêmes informations.
Jeux de données
Exemple de la Table Administrateur
Requêtes SQL
Liste des produits
SELECT * FROM produit;
Liste des clients dans l’ordre alphabétique SELECT * FROM utilisateur ORDER BY nom ASC;
Liste des livreurs avec le statut libre SELECT * FROM Livreur
WHERE statut=‘libre';
Liste des commandes du 2 décembre 2019 SELECT * FROM Commande
WHERE date = ’02/12/2019‘;
Changer le mot de passe d’un administrateur UPDATE Administrateur
SET motdepasse='Xfg12$' WHERE nom='Bocuse';
Vider la table des produits Ajouter les produits
Créer une commande
Afficher le produit le plus cher
Liste des produits inférieurs à 10 euros SELECT designation, prix FROM produit WHERE prix <= 10.00;
Le montant moyen d’une commande Combien de commande a livré le livreur 1
Liste des produits et le nombre de fois qu’ils ont été commandés
Le prix moyen par catégorie de produit SELECT categorie_id, AVG(prix) FROM Produit
GROUP BY categorie_id;
