b8cb3ef68d
Baseline of the P1 conception work produced over sessions 5-7 (was uncommitted in the working tree). 11-entity model, French naming. Superseded next by the prod-like revision (English, ~16 entities) per the 2026-06-04 decision session - this commit preserves the baseline in history before that rewrite.
222 lines
11 KiB
Markdown
222 lines
11 KiB
Markdown
# Diagramme de cas d'utilisation - Wakdo
|
|
|
|
**Phase UML** : P1 - Conception, complement UML (apres MCD)
|
|
**Statut** : v0.1
|
|
**Date** : 2026-05-21
|
|
**Branche** : `feat/p1-conception`
|
|
**Auteur methodologie** : BYAN
|
|
|
|
---
|
|
|
|
## 1. Objet du document
|
|
|
|
Ce document recense les **cas d'utilisation** de Wakdo, c'est-a-dire les
|
|
fonctionnalites observables du systeme du point de vue de ses acteurs. Il
|
|
complete le MCD (`docs/merise/mcd.md`) et le dictionnaire
|
|
(`docs/merise/dictionary.md`) en passant de la vue **donnees** a la vue
|
|
**usages**.
|
|
|
|
Le diagramme reste au niveau conceptuel. Il ne prejuge pas de l'ecran ou de
|
|
l'endpoint qui realisera chaque cas, mais identifie qui fait quoi.
|
|
|
|
**Sources** :
|
|
- `docs/PROJECT_CONTEXT.md` sections 2 (acteurs, processus), 7 (scope RBAC)
|
|
- `docs/merise/dictionary.md` (entites `commande`, `role`, `user`)
|
|
|
|
---
|
|
|
|
## 2. Acteurs - perimetre et challenge de pertinence
|
|
|
|
Le brief (`PROJECT_CONTEXT.md` section 2 et section 7) definit les acteurs
|
|
metier. Avant de les retenir, chaque acteur propose dans la consigne initiale
|
|
est confronte au perimetre reel du projet.
|
|
|
|
| Acteur candidat | Statut | Justification (perimetre reel) |
|
|
|---|---|---|
|
|
| **Client (borne kiosk)** | Retenu | Acteur central du Bloc 1. Compose et valide une commande sur la borne tactile autonome (canal `kiosk`). Non authentifie. |
|
|
| **Manager / Admin** | Retenu, fusionne en **Administration** | Le brief ne distingue pas "manager" et "admin" comme deux roles. Le role RBAC reel est `admin` (section 7). Il porte le CRUD catalogue, la gestion des utilisateurs/roles et les stats. On nomme l'acteur **Administration** pour coller au vocabulaire du brief. |
|
|
| **Cuisine** | Retenu, renomme **Preparation** | Correspond au role RBAC `preparation` (section 7). Voit la file des commandes a preparer triees par heure de livraison croissante et fait avancer leur statut. Le terme "Cuisine" est un synonyme metier ; le role technique est `preparation`. |
|
|
| **Caisse** | Ecarte comme acteur distinct | Challenge : il n'existe pas de role RBAC `caisse` (les 3 roles sont `admin`, `preparation`, `accueil`). Le paiement existe dans le cycle (cote Client sur la borne et cote Accueil au comptoir/drive), mais aucun acteur "Caisse" dedie n'est modelise. L'equivalent operationnel le plus proche est l'**Accueil** (role `accueil`) qui saisit les commandes au comptoir/drive et remet les commandes livrees. |
|
|
| **Accueil** | Retenu (non liste dans la consigne mais present au brief) | Role RBAC `accueil`. Saisit les commandes au comptoir (canal `counter`) ou au drive (canal `drive`), puis remet les commandes au client (passage a `delivered`). C'est l'acteur qui recouvre le besoin que la consigne attribuait a "Caisse". |
|
|
|
|
### Decision sur les acteurs retenus
|
|
|
|
Quatre acteurs sont conserves au diagramme :
|
|
|
|
1. **Client** (borne, non authentifie)
|
|
2. **Administration** (role `admin`)
|
|
3. **Preparation** (role `preparation`, ex-"Cuisine")
|
|
4. **Accueil** (role `accueil`, recouvre le besoin "Caisse")
|
|
|
|
> Decision actee : il n'y a **pas** de parcours employe dedie modelise a part.
|
|
> Les cas d'usage des employes (Administration, Preparation, Accueil) sont
|
|
> couverts directement ici. Cette decision suit le mantra du Rasoir d'Ockham
|
|
> (#37) : on evite une couche de modelisation redondante tant qu'aucun besoin
|
|
> ne la justifie.
|
|
|
|
---
|
|
|
|
## 3. Diagramme de cas d'utilisation
|
|
|
|
Mermaid ne fournit pas de type `usecase` natif. La representation ci-dessous
|
|
utilise un `flowchart` : les acteurs sont des noeuds a gauche, les cas
|
|
d'utilisation sont des noeuds arrondis regroupes par sous-systeme, et les
|
|
fleches portent les relations (`<<include>>`, `<<extend>>`) la ou elles
|
|
ont du sens.
|
|
|
|
```mermaid
|
|
flowchart LR
|
|
%% Acteurs
|
|
Client(("Client<br/>borne kiosk"))
|
|
Admin(("Administration<br/>role admin"))
|
|
Prep(("Preparation<br/>role preparation"))
|
|
Accueil(("Accueil<br/>role accueil"))
|
|
|
|
%% Sous-systeme Borne client
|
|
subgraph BORNE["Borne client - Bloc 1"]
|
|
UC1(["Consulter le catalogue"])
|
|
UC2(["Composer un menu"])
|
|
UC3(["Passer une commande"])
|
|
UC4(["Saisir le numero de retrait"])
|
|
UC5(["Recevoir la confirmation"])
|
|
UC6(["Payer la commande"])
|
|
end
|
|
|
|
%% Sous-systeme Back-office
|
|
subgraph BACK["Back-office - Bloc 2"]
|
|
UC10(["Gerer le catalogue<br/>categories, produits, menus"])
|
|
UC11(["Gerer les utilisateurs et roles"])
|
|
UC12(["Consulter les statistiques"])
|
|
UC20(["Consulter la file de preparation"])
|
|
UC21(["Faire avancer une commande"])
|
|
UC30(["Saisir une commande<br/>comptoir ou drive"])
|
|
UC31(["Remettre la commande au client"])
|
|
UC40(["S'authentifier"])
|
|
end
|
|
|
|
%% Relations Client
|
|
Client --> UC1
|
|
Client --> UC2
|
|
Client --> UC3
|
|
Client --> UC6
|
|
Client --> UC5
|
|
|
|
%% include / extend cote borne
|
|
UC3 -. include .-> UC4
|
|
UC3 -. include .-> UC6
|
|
UC2 -. include .-> UC1
|
|
UC3 -. extend .-> UC2
|
|
|
|
%% Relations Administration
|
|
Admin --> UC40
|
|
Admin --> UC10
|
|
Admin --> UC11
|
|
Admin --> UC12
|
|
|
|
%% Relations Preparation
|
|
Prep --> UC40
|
|
Prep --> UC20
|
|
Prep --> UC21
|
|
|
|
%% Relations Accueil
|
|
Accueil --> UC40
|
|
Accueil --> UC30
|
|
Accueil --> UC31
|
|
UC30 -. include .-> UC1
|
|
|
|
%% Authentification mutualisee
|
|
UC10 -. include .-> UC40
|
|
UC11 -. include .-> UC40
|
|
UC20 -. include .-> UC40
|
|
UC30 -. include .-> UC40
|
|
```
|
|
|
|
---
|
|
|
|
## 4. Description des cas d'utilisation
|
|
|
|
### 4.1 Acteur Client (borne kiosk)
|
|
|
|
| Cas | Description | Entites manipulees |
|
|
|---|---|---|
|
|
| Consulter le catalogue | Parcourir les categories, produits et menus disponibles. Charges via `GET /api/categories`, `/api/products`, `/api/menus` (ou JSON fallback). | `categorie`, `produit`, `menu` |
|
|
| Composer un menu | Choisir burger + accompagnement + boisson + sauce, regler les options de taille (normale / grande) et de personnalisation. Etend "Passer une commande" car un menu compose est une variante d'item au panier. | `menu`, `menu_produit`, `produit` |
|
|
| Passer une commande | Valider le panier, declencher la creation de la commande composee. Inclut la saisie du numero de retrait et le paiement. | `commande`, `ligne_commande` |
|
|
| Saisir le numero de retrait | Renseigner le numero qui identifie le client au comptoir. Cas inclus par "Passer une commande". | `commande.numero` |
|
|
| Payer la commande | Regler la commande une fois le panier compose et valide. Materialise la transition `pending_payment -> paid` de `state-commande.md`. Cas inclus par "Passer une commande". | `commande.statut`, `commande.paye_a` |
|
|
| Recevoir la confirmation | Afficher l'ecran de confirmation avec le numero, apres paiement. | `commande` |
|
|
|
|
> Note de coherence : le cycle de vie comporte deux phases successives, la
|
|
> composition de la commande puis son paiement (regle metier confirmee). Le cas
|
|
> "Payer la commande" est retenu cote Client et materialise la transition
|
|
> `pending_payment -> paid` de l'ENUM `statut`
|
|
> (`dictionary.md` 3.5, `state-commande.md`).
|
|
|
|
### 4.2 Acteur Administration (role admin)
|
|
|
|
| Cas | Description | Entites manipulees |
|
|
|---|---|---|
|
|
| Gerer le catalogue | CRUD sur categories, produits et menus (libelles, prix, images, disponibilite, composition de menu). | `categorie`, `produit`, `menu`, `menu_produit` |
|
|
| Gerer les utilisateurs et roles | CRUD sur les comptes back-office et leurs roles ; consultation de la matrice de permissions. | `user`, `role`, `permission`, `role_permission` |
|
|
| Consulter les statistiques | Voir les commandes du jour de service, le chiffre d'affaires, les produits les plus commandes. | `commande`, `ligne_commande` |
|
|
|
|
### 4.3 Acteur Preparation (role preparation, ex-Cuisine)
|
|
|
|
| Cas | Description | Entites manipulees |
|
|
|---|---|---|
|
|
| Consulter la file de preparation | Afficher les commandes a preparer triees par heure de livraison croissante, tous canaux confondus. | `commande`, `ligne_commande` |
|
|
| Faire avancer une commande | Declarer une commande "preparee", ce qui declenche une transition de statut (voir `state-commande.md`). | `commande.statut` |
|
|
|
|
### 4.4 Acteur Accueil (role accueil, recouvre Caisse)
|
|
|
|
| Cas | Description | Entites manipulees |
|
|
|---|---|---|
|
|
| Saisir une commande | Creer une commande pour un client au comptoir (`counter`) ou au drive (`drive`), en consultant le catalogue. | `commande`, `ligne_commande`, `produit`, `menu` |
|
|
| Remettre la commande au client | Declarer une commande "livree" au moment de la remise physique. | `commande.statut` |
|
|
|
|
### 4.5 Cas transverse - S'authentifier
|
|
|
|
Tous les acteurs du back-office (Administration, Preparation, Accueil) passent
|
|
par "S'authentifier" avant d'acceder a leurs cas. Modelise comme cas inclus
|
|
(`<<include>>`) par chaque cas back-office pour eviter de surcharger le
|
|
diagramme. Le Client de la borne n'est pas authentifie (canal `kiosk` public).
|
|
|
|
---
|
|
|
|
## 5. Relations include / extend retenues
|
|
|
|
| Relation | Type | Justification |
|
|
|---|---|---|
|
|
| Passer une commande -> Saisir le numero de retrait | include | La saisie du numero fait partie integrante de toute validation de commande. |
|
|
| Passer une commande -> Payer la commande | include | Le paiement suit la composition du panier et fait partie integrante du parcours (phase 2 du cycle de vie). |
|
|
| Composer un menu -> Consulter le catalogue | include | Composer un menu suppose de parcourir les produits eligibles a chaque slot. |
|
|
| Passer une commande -> Composer un menu | extend | Le menu est un cas optionnel : une commande peut ne contenir que des produits a la carte. La composition etend le parcours seulement si le client choisit un menu. |
|
|
| Saisir une commande (Accueil) -> Consulter le catalogue | include | L'equipier consulte le catalogue pour saisir au comptoir / drive. |
|
|
| Cas back-office -> S'authentifier | include | Acces conditionne a une session authentifiee. |
|
|
|
|
---
|
|
|
|
## 6. Incoherences remontees vers les autres livrables
|
|
|
|
Ces ecarts entre les sources sont signales pour arbitrage de l'auteur (la
|
|
modelisation finale releve de sa decision, mantra de validation humaine).
|
|
|
|
1. **ENUM `statut` et phase de paiement (tranche)**
|
|
Le dictionnaire (`dictionary.md` 3.5) definit
|
|
`statut ENUM('pending_payment','paid','preparing','ready','delivered','cancelled')`
|
|
avec un paiement explicite. La regle metier confirmee fixe deux phases
|
|
successives, la composition de la commande puis son paiement. Le cas
|
|
"Payer la commande" est donc retenu cote Client et materialise la transition
|
|
`pending_payment -> paid`. Cet ecart est tranche : la machine canonique de
|
|
`state-commande.md` fait foi.
|
|
|
|
2. **Acteur "Caisse" absent du RBAC**
|
|
Aucun role `caisse` n'existe (`PROJECT_CONTEXT.md` section 7 : `admin`,
|
|
`preparation`, `accueil`). La fonction d'encaissement de la consigne a ete
|
|
rattachee a l'acteur **Accueil**. A confirmer.
|
|
|
|
3. **"Manager" vs "Admin"**
|
|
La consigne parle de "Manager/Admin" ; le brief ne connait que `admin`. Les
|
|
deux ont ete fusionnes en un acteur **Administration**. A confirmer si un
|
|
role manager intermediaire est souhaite (le dictionnaire 3.8 mentionne un
|
|
role `manager` extensible, non present dans le scope section 7).
|