EVALUATION PROJET A

2023-2024
Nom et prénom :

5/30/2024
 EVALUATION PROJET ANALYSE ET CONCEPTION

Tableau de matières :

Unité Nom Pag.

Table of Contents
Introduction 2
Rôles 3
Diagramme de Cas d’utilisation 4
Diagramme développé 5
Definition de chaque cas d’utilisation 5-6
Type chapter title (level 1) 4
Type chapter title (level 2) 5
Type chapter title (level 3)6
Type chapter title (level 1) 4
Type chapter title (level 2) 5
Type chapter title (level 3)6
Type chapter title (level 1) 4
Type chapter title (level 2) 5
Type chapter title (level 3)6
Type chapter title (level 1) 4
Type chapter title (level 2) 5
Type chapter title (level 3)6

Introduction :
- Au début de l’analyse de notre projet, on a pensé en la possibilité de
développer une application qui nous permettre la gestion des événements,
manipulations d’argent, calcule de ventes, analyses de ventes, etc. On a

May 30, 2024 1

 EVALUATION PROJET ANALYSE ET CONCEPTION

commencé à décrire la manière dans lequel vont être réalisées le processus

de l’app, on a défini le concept, les points plus importants. Dans les pages
suivantes de ce document informatif, on va expliquer d’une manière détaillée
notre projet.
- Ce projet sera formulé dans le principe de la méthodologie Agile, ce que
signifie que tous les processus qu’on va avoir dans les pages qui suivent sont
basés entre le client et les développeurs, nous définirons tous les processus
par sprint. On a choisi cette méthodologie dû à la capacité qui ont les
individus pour modifier le projet constantement, ainsi que la possibilité de
séparer les processus et les outils par les pensées développées par l’homme
(Drumond, 2024).
- C’est un projet structure dans les différents sprints du framework Scrum, on a
défini un certain temps pour chaque étape, au cours de laquelle nous avons
élaboré les composants techniques au moyen de diagrammes, qui vous
serviront à comprendre ce qu’on a développé.
- L’idée principal du fichier c’est de vous informer sur l’application future, afin
que vous soyez capable de traduire cette information à l’ordinateur, prendre
les bases pour la phase de réalisation (construction de l’app).
-
- Notre objectif sera de développer une application pour gérer les commandes
de différents événements de l'école.
- Notre vision est de faciliter le processus de gestion des ventes pour les
événements futurs.
- La réalisation du projet fonde ses bases grâce à trois étudiant de la promotion
sociale qui ont pensés à la manière de transformer une gestion manuelle de
monde commerciale comme les ventes dans un restaurant à la gestion virtuel
par moyen d’une application mobile, et aussi à l’interaction de notre
professeur Alain Choquet, qui nous a guidés dans le cours de gestion
d’analyses et conception, on a travaillé avec Scrum, une méthodologie
simple, pratique, adaptable au changement et d’avance rapide dans un projet
petit.

Les rôles :

Les profiles Participation à application Type de dispositive

Le serveur Prendre une commande Téléphone –

May 30, 2024 2

 EVALUATION PROJET ANALYSE ET CONCEPTION

Reprendre une commande Orientation verticale

Modifier la commande
Confirmer le paiement
Mettre la commande en attente
Reprendre une commande en
attente
Annuler la commande
Se connecter/S’enregistrer
Modifier options

Le caissier Acheter tickets de boissons Tablette - orientation

Se connecter/S’enregistrer horizontale
Modifier Options
Réaliser des actions du serveur

Le preparateur Recevoir la commande Tablette – Orientation

Se connecter / s’enregistrer horizontale
Gérer la commande
L’organisateur CRUD EVENT Téléphone –
Enregistrer l’inventaire initial Orientation verticale
Enregistrer l’inventaire Tablette – Orientation
résiduelle horizontale
Gérer l’inventaire

Responsable financier Consulter les revenus d’un Téléphone –

événement Orientation verticale
Réaliser des actions d’un Tablette – Orientation
organisateur horizontale

Figure 1diagramme cas d'utilisation 1

- J’ai utilisé le diagramme de cas d’utilisation pour classifier les points plus
importants du projet et distribuer chaque cas à l’acteur correct selon ses
besoins.

May 30, 2024 3

 EVALUATION PROJET ANALYSE ET CONCEPTION

Figure 1diagramme cas d'utilisation 1 Voir le document

Développement de chaque cas d’utilisation :

- On a priorisé chaque cas d’utilisation, pour réaliser ça on a utilisé des
couleurs avec des numéros, c’est nécessaire pour pouvoir élaborer le Product
back log items qui représentent les sprints qu’on va réaliser dans un temps
déterminé.
- Les use case égale ou plus proches à 1, sont les plus importants.
- Les use case égale ou plus proches à 7, sont les moins importants.

Brève définition de chaque cas d’utilisation :

- Prendre une commande / Take an order : Elle consiste à prendre une
demande de nourriture soit parce qu'un client l'a faite via l'application par
moyen d’un serveur qui à l’accès à l’application. On va décrire là, toutes les
options possibles qui peut choisir le client au sujet de la nourriture, ainsi que
la manipulation de la commande par le serveur. p_c 1
- Modifier une commande / Modify an order : Modification d'une commande
envoyée à condition que son état soit "En attente" et non "En préparation". La
commande en cours de modification disparait de l'écran du préparateur afin

May 30, 2024 4

 EVALUATION PROJET ANALYSE ET CONCEPTION

de ne pas la préparer tant qu'elle est en cours de modification. Si la

commande a déjà été facturée, sa modification entraine une correction de
paiement (négatif ou positif). Si la commande est en préparation, on peut lui
offre la création d’une nouvelle facture si la personne veut acheter autre
chose, mais au sujet d’une commande qui peut être constituée de plusieurs
produits (Recettes) qui va se préparer, on ne peut pas la modifier parce
qu’elle est cuisinée dans ce moment par le préparateur. m_c 1

- Recevoir des nouvelles commandes / Receive new orders : consiste à

attendre l'arrivée d'une demande pour qu'il l'accepte. On aura trois parties
dans cette écran, réception, en préparation, et services. R_n_c 1
- CRUD Event : Création de l'évènement, et de ses paramètres (Type de
caisse (cash ou tickets), Modification de l’évènement, les ressources d’un
événement (nombre de serveurs, caissiers et préparateurs), spécificités de
l'évènement (ex : alcool interdit), obligation d'encaissement (encaissement
obligatoire avant l'envoi de la commande, au service, ou au choix du serveur),
Délai de sauvegarde des commandes Non-Envoyées , analyses statistique
d’un événement, annexe des produits, annexe des recettes, c’est très
important ce cas d’utilisation parque fait partie du but principal, gérer les
commandes d’un événement. c_e 1

- Confirmer le paiement / Confirm payment : Sert à réaliser le processus de

paiement de la commande effectué par client-serveur-caissier. La personne
qui va encaisser sera le caissier, seulement si l’événement est géré par ticket
où le paiement est obligatoire, dans ce cas on peut laisser la commande en
sauvegardée et au moment qu’il souhaite payer, il doit se diriger jusqu’à le
caissier et payer, une fois que ce processus a été réalisé, la commande
changerai son statut à ‘envoyée’, mais si le paiement n’est pas obligatoire, on
va permettre au serveur d’envoyer la commande sans encaisser. c_p 1
-
- Annuler la commande / Cancel order : Annuler une commande existante, si
la commande est payer il faut réaliser le remboursement. a_c 1
- Mettre la commande en attente / putting an order on hold : Fonction
permettant d'enregistrer durant un certain lapse de temps (défini dans les
paramètres de l'évènement) une commande sous le statut "En attente", par
exemple si les clients veulent encore y réfléchir, sans devoir supprimer et
recommencer toute la commande. Si la commande est sauvegardée est
payée, il ne faut pas la supprimer. m_c_e_a 1

- Reprendre la commande / Resuming a pending order : Si une commande

a été enregistrée sans être envoyée (statut "En attente", elle est conservée
durant un laps de temps défini dans les paramètres de l'évènement, et peut
être reprise pour être modifiée, et finalisée. r_c 1

May 30, 2024 5

 EVALUATION PROJET ANALYSE ET CONCEPTION

- Gérer la commande / Manage an order : Ouverture d'une nouvelle

commande en sélectionnant la table (ou retrait), et le détail de la commande.
g_c 1

- Enregistrer l’inventaire initial / Record the initial inventory :

Enregistrement des articles qui seront disponibles à l'évènement, la quantité,
le prix d'achat (unitaire ou pour l'ensemble), les catégories (alcool, soft,
snacks, plat, ...), définir une caution (pour des goblets, tasses, etc.).e_i_i 1
-

- Enregistrer l’inventaire résiduelle / Record residual inventory : Inventaire

du stock restant par rapport au stock avant l'évènement, afin de définir la
différence avant-après, et la différence avec les quantités vendues, afin
d'évaluer les pertes. Le stock après-évènement peut être récupéré lors d'un
enregistrement de stock avant l'évènement suivant. e_i_r 1

- Gérer l’inventaire / Manage the inventory : consiste à gérer les objets que
vous possédez. g_i 1

- Afficher un rapport d’événement / View an event report : on a défini cette

fonction pour réaliser une analyse de chaque événement, savoir combien
d’argent j’ai dépensé dans l’événement, combien de produits est-ce que j’ai
vendu, combien d’argent j’ai gagné dans l’événement, quel est le produit plus
vendu, quel est la recette plus vendue, etc. a_u_r_e 1

- Achat d’un ticket de boisson / Purchasing drink ticket : Achat de billets, la

fonction de ce cas d’utilisation est de vendre les billets pour chaque
événement. a_t_b 1

- Consulter les revenus d’un événement / Consult the income of an

event : Cette fonction est donnée pour expliquer de façon détaillée chaque
ventes et dépenses d’un événement. c_r_e 1

- Se connecter / s’enregistrer - Log in/ Sign up : Consiste à réaliser

l’enregistrement et permettre l’accès aux utilisateurs. s_c_s_e 1
- Modifier options / Modify options : Ce sont des détails des utilisateurs.
m_o1

May 30, 2024 6

 EVALUATION PROJET ANALYSE ET CONCEPTION

Méthodologie de travail et des outils utiliser pour la réalisation :

1) Product Backlog Items priorisé :

On a
estimé
une durée
de 3
semaines

Chaque
date qu’on
a dans la
liste,
Ouvrir document
représente
projectLibre

DIAGRAMME ERD 1

May 30, 2024 7

EVALUATION PROJET ANALYSE ET CONCEPTION

DIAGRAMME MLD 1

May 30, 2024 8

 EVALUATION PROJET ANALYSE ET CONCEPTION

DEFINITION TABLES :

- ORDERS_ORD (T_ORDERS) : Entité des commandes.

May 30, 2024 9

 EVALUATION PROJET ANALYSE ET CONCEPTION

- TYPES_INTERACTION_ORDER_TIORD(T_TYPES_INTERACTION_ORDE
R) : Types d'interaction d'une prestation sur une commande. Exemple : créer,
modifier, sauvegardé, supprimé, envoyé, préparé, servi.
- TABLES_TAB (T_TABLES) : Entité des tables existantes, rappelées dans un
évènement pour constituer son plan de table personnalisé à chaque
évènement.
- WORKERS_WOR (T_WORKERS) : Entité des travailleurs, constituant le
carnet de contacts.
- JOBS_JOB (T_JOBS) : Représente un poste de travail. Exemple : Le
serveur, le préparateur, etc.
- CATEGORIES_EVENT_CEVE (T_CATEGORIES_EVENT) : Catégories
d'évènements afin de pouvoir structurer, alimenter et regrouper les rapports
d'évènements par types. Exemple : "Remises de diplômes ; Soupés des
enseignants ; Soirée d'intégration ; ...".
- WORK_SERVICES_WSER (T_WORK_SERVICES) : Prestations des
travailleurs pour un évènement donné, incluant leur rôle (Job) et salaire.
- INTERACTIONS_ORDER_IORD (T_INTERACTION_ORDER) : Interactions
d'une prestation sur une commande. Permet de savoir qui a fait quoi et à
quelle heure sur quelle commande. (Création, modification, sauvegarde,
annulation, envoi, préparation, service, etc.).
- EVENTS_EVE (T_EVENTS) : Entité des évènements créées par l'école.
C'est sur ces évènements que sont définis les paramètres tel que le type de
caisse (ByTicket) ou l'obligation d'encaissement PayToSend.
- GENERAL_EVENT (T_GENERAL_EVENT) : Interaction de dépenses
indirectes d’un événement.
- GENERAL_EXPENSES (T_GENERAL_EXPENSES) : Constitue les
dépenses générales. Exemple : "paiement de livraison des tables". Ce n'est
pas de paiement de nourriture. Dépenses liées à la structure
organisationnelle de l'événement.
- STATUS_EVENTS_EVENTS (T_STATUS_EVENTS_EVENTS) : Interaction
d'un événement liée au statut.
- STATUS_EVENEMENT(T_STATUS_EVENEMENT) : Toutes les catégories
qui peuvent faire partie d'un événement. Upcoming events (événement à
venir), events in progress (événement en cours), completed events
(événement complété), etc.
- SALEITEMS_TO_EVENT(T_SITE_TO_EVE) : Entité intermédiaire servant à
sélectionner les articles de ventes qui seront disponibles pour un évènement
donné.
- T_TABLES_TO_EVENTS(T_TABLES_TO_EVENTS) : Table de relation entre
les événements et les tables enregistrer par l'événement.
- SALEITEMS_SITE(T_SALEITEMS) : Articles de vente constitués de recettes
ou produits indiquant les ingrédients correspondant à des achats. Exemple :
« Tomates farcies au chèvre chaud », id 1.

May 30, 2024 10

 EVALUATION PROJET ANALYSE ET CONCEPTION

- CATEGORIES_SALEITEMS_CSITE(T_CATEGORIES_SALEITEMS) :
Catégories des articles de vente s'affichant sur les écrans de prise de
commande. Exemple : Boisson, snacks, repas.
- TYPE_PRODUITS(T_TYPE_PRODUITS) : Garde deux noms, Recette ou
Produit. Il faut ajouter l’identifiant à la table SALEITEMS_SITE. Exemple :
« Tomates farcies au chèvre chaud », c’est une recette, « Coca Cola », c’est
un produit.
- SALEITEMS_PRODUITS(T_SALEITEMS_PRODUITS) : Garde tous les
produits qui sont enregistrés dans SALEITEMS_SITE, ainsi que tous les
produits nécessaires pour la recette. Exemple : « Tomates farcies au chèvre
chaud », id 1, contient poivre, sel, 250g de lardons fumés, 1 bûchette de
fromage de chèvre, 60g de champignons de Paris, herbes de Provence.
Chaque produit est enregistré à la table avec son identifiant et l’identifiant de
la recette.
- PRODUITS_RECETTES(T_PRODUITS_RECETTES) : Cette table contient
tous les produits, Exemple : « Tomates farcies au chèvre chaud », id 1,
contient poivre, sel, 250g de lardons fumés, 1 bûchette de fromage de chèvre,
60g de champignons de Paris, herbes de Provence, On va enregistrer les
produits avec son nom, il ne faut pas prendre la quantité de la recette, il faut
utiliser la quantité générale de produits qu’il y a dans l’inventaire.
- ORDER_SALEITEMS_OSITE(T_ORDER_SALEITEMS) : Détails des articles
de vente dans une commande. Par exemple : la commande 2 contient 4
recettes de « Tomates farcies au chèvre chaud » au prix de 20€ x 4 = 80€,
ainsi que 9 Coca-Cola au prix de 1,20€ x 9 = 10,80€. Nous enregistrerons
l’identifiant du produit ou de la recette avec sa quantité, et répéterons
plusieurs fois l’identifiant de la commande s'il contient plusieurs produits.
- T_BILLET_RECU(T_BILLET_RECU) : Les billets et monnaies utilisées.
200€, 100€, 50€, 20€, 10€, 5€, 2€ ,1€, 5 cents, etc.
- T_BILLE_ORDER(T_BILLE_ORDER) : Interaction entre la commande et les
billets reçus que nous voulons gérer. Par exemple : le client paie une
commande de 8,40€ avec un billet de 10€. Ce que nous ferons sera de
choisir le billet de 10€, calculer le montant à rendre (1,40€ en liquide). De
cette manière, nous contrôlons les billets qui entrent et sortent de
l’événement.

May 30, 2024 11

EVALUATION PROJET ANALYSE ET CONCEPTION

SPRINTS

May 30, 2024 12

 EVALUATION PROJET ANALYSE ET CONCEPTION

Les écrans de l’application :

sma_wait = Le serveur et aussi le caissier
Nro Shortname Sprint Nom
° travailleur
1 SMA_wait_01 Prendre une commande / Take an
order 1 MAIN_SCREEN_WAIT
19

2 SMA_wait_02 Prendre une commande /Take an Category and 19

order 1 choosing
3 SMA_wait_03 Prendre une commande /Take an summary send confirm 20
order 1
4 SMA_wait_04 Confirmer le paiement / Confirm send free|pay of Er
Payment 3 charge ror
:
Re
fer
en
ce
so
ur
ce
no
t
fo
un
d
5 SMA_wait_05 Confirmer le paiement / Confirm cashier's check back
Payment 3
6 SMA_wait_06 Confirmer le paiement /Confirm send free|pay of
Payment 3 charge copy
7 SMA_wait_07 Putting order on hold 3 order saved menu
8 SMA_wait_08 Mettre la commande en attente / saved whitout
Putting order on Hold 3 payment
9 SMA_wait_09 Mettre la commande en attente / Save and paid
Putting order on Hold 3
10 SMA_wait_10 Mettre la commande en attente / order saved and paid
Putting order on hold 3
11 SMA_wait_11 Modifier la commande /Modify an table saved 20
order 1
12 SMA_wait_12 Modifier la commande / Modify an table sent whitout 21
payment timer 20

May 30, 2024 13

 EVALUATION PROJET ANALYSE ET CONCEPTION

order 1
13 SMA_wait_13 Modifier la commande / Modify an table sent whitout 21
order 1 payment en attente
copy 4
14 SMA_wait_14 Modifier la commande / Modify an table sent whitout 21
order 1 payment
15 SMA_wait_15 Modifier la commande / Modify an table sent and paid 20
order 1
16 SMA_wait_16 Modifier la commande / Modify an table in preparation 21
order 1
17 SMA_wait_17 Modifier la commande / Modify an table prepared 20
order 1
18 SMA_wait_18 Modifier la commande / Modify an Table served 20
order 1
19 SMA_wait_19 Modifier la commande / Modify an table prepared without 20
order 1 paied
20 SMA_wait_20 Modifier la commande / Modify an table sent whitout en 20
order 1 attente sans payer
21 SM_wait_21 Modifier la commande / Modify an table in preparation copy 21
order 1

May 30, 2024 14

EVALUATION PROJET ANALYSE ET CONCEPTION

May 30, 2024 15

EVALUATION PROJET ANALYSE ET CONCEPTION

May 30, 2024 16

 EVALUATION PROJET ANALYSE ET CONCEPTION

SPRINT 1 Diagramme d’activité : Sprint 1 DAC take an order.pdf

Sprint 1 : DAC Modify an order

May 30, 2024 17

 EVALUATION PROJET ANALYSE ET CONCEPTION

Prendre une commande / Take an order

May 30, 2024 18

EVALUATION PROJET ANALYSE ET CONCEPTION

SMA_WAIT_
1:MAIN_SCREEN_WAI
Cet écran est utilisé pour gérer toutes les tables d’un
T 1
événement, ainsi que modifier les commandes en
appuyant sur les items, voir les statuts de la
commande, de la table, etc. Cet écran sera utilisé
par le serveur et le caissier. On aura une version
pour le téléphone et une version pour la tablette.
Comme on peut voir, on va manipuler différents
statuts de la commande, pour savoir par où est-ce
qu’elle est, de cette manière nous pouvons en avoir
un contrôle total. ‘Ajouter une commande’ sera
utilisée pour enregistrer les commandes qui n’ont
pas
Accès deERD
table.
: DIAGRAMME ERD 1
Accès MLD :DIAGRAMME MLD 1
Accès Diagramme : Sprint 1 DAC take an order.pdf
Nom de la requête : main_screen_select et main_screen_select_order

SMA_WAIT_ 2 : Category and

choosing
Cet écran sera utilisé par le serveur pour choisir les
produits que le client veut acheter. On a trois options,
Boissons, snacks et repas, chaque produit sera classifié et
montrer à cet écran selon l’événement. On va utiliser le
même écran pour réaliser les modifications de la
commande, on va changer le nom du bouton (réviser
mockup )

Accès ERD : DIAGRAMME ERD 1

Accès MLD :DIAGRAMME MLD 1
Accès Diagramme : Sprint 1 DAC take an order.pdf
Nom de la requête : update_status_table (quand le serveur sélectionner
la table), update_status_worker(quand le serveur prend la commande),
query_eve_by_ticket_and_products(Sert à savoir si l’événement sera
en ticket ou en cash et les produits),filter_by_category(Filter les
catégories)

May 30, 2024 19

 EVALUATION PROJET ANALYSE ET CONCEPTION

SMA_WAIT_ 3: summary send confirm

On utilisera cet écran pour faire un aperçu des

produits, ajouter le nom du client et une note.
, où l’envoyer qui fait partie de confirmer la
commande.

Accès ERD : DIAGRAMME ERD 1

Accès MLD :DIAGRAMME MLD 1
Accès Diagramme : Sprint 1 DAC take an order.pdf
Nom de la requête : bd_ajoute_produit_en_attente(mettre les données
dans la bases de données, statut en attente),
update_commande_note(ajouter la note, sinon ajouter une chaîne
vide), update_commande_client(ajouter le client, sinon ajouter une
chaîne vide, dépend de vous ;-°).

Modifier une commande / Modify an order supra

w
SMA_WAIT_11 : table SMA_WAIT_4 : table SMA_WAIT_20 : table sent
saved sent and paid whitout en attente sans payer

SMA_WAIT_19 : table SMA_WAIT_5 : SMA_WAIT_17: table

prepared without paied table served prepared

May 30, 2024 20

 EVALUATION PROJET ANALYSE ET CONCEPTION

SMA_WAIT_16 :table SMA_WAIT_11 : SMA_WAIT_12:

in preparation table sent whitout table sent whitout
payment payment timer
Error: Reference source not found

SMA_WAIT_12 : table SMA_WAIT_21:

sent whitout payment table in preparation
en attente copy 4 copy

- Comme nous l'avons déjà vu, il est possible de changer le statut de la

commande. Une fois la commande est enregistrée dans le système, elle
contiendra un statut qui peut être en attente, sauvegardée, envoyée,
préparée, servie, etc. Il y aura aussi des commandes qui ne seront pas
payées mais qui seront envoyées, cependant, cette situation dépend de
l'événement : si l'administrateur n'autorise pas l'envoi de la commande avant
le paiement, le processus sera plus simple et nécessitera un paiement avant
l'envoi, par contre, si l'administrateur permet l'envoi sans encaissement
préalable, dans l'application, la commande sera marquée comme « Pas
payée » jusqu'à la préparation. Lorsque la commande sera servie, il faudra
l'encaisser si elle n'a pas encore été payée mais nous pouvons passer par
plusieurs statuts sans payer.
- Comme nous voyons aux écrans, on va désactiver certains boutons si le
statut change.

May 30, 2024 21

 EVALUATION PROJET ANALYSE ET CONCEPTION

- Si la commande est en préparation, il n'est pas possible de la modifier. Dans

ce cas, il sera possible de créer une nouvelle facture ajoutée à la même table.
-
Sprint 1 : ERD
Tables à utiliser :
t_events,t_work_services,t_tables,t_tables_to_events,t_orders,t_interaction_o
rder,t_types_interaction_order,t_bille_order,t_bille_recu,t_order_saleitems,
t_saleitems.

Attention : le texte en noir (Bold) représente les tables qui seront

utilisées dans le sprint 1. Les tables mentionnées dans l’explication sont
utilisées comme référence pour comprendre les relations.

- ORDERS_ORD relation TYPES_INTERACTION_ORDER_TIORD :

- Cardinalité : La commande peut passer par plusieurs étapes, contiendra
plusieurs statuts et un type de statut spécifique peut être utilisé par plusieurs
commande, c’est pour ça qu’on a une relation N-N, liée avec la table
Interactions_order_iord, une table supplémentaire.

- TABLES_TAB Relationi ORDERS_ORD :

- Cardinalité : On observe une relation 0-N, car une commande ne peut être
enregistrée qu'à une seule table, mais une table peut enregistrer plusieurs
commandes, mais c’est possible qu’une commande crée ne soit pas
enregistrée à la table, ainsi qu’avoir une table sans commandes, c’est très
importante t_tables (tables_tab), on va l’utiliser dans l’écran
main_screen_wait.
- EVENTS_EVE <-> TABLES_TAB : On observe une relation N-N (Many-to-
many), parce qu’on peut avoir 0 à N tables dans l’événements, et une table
peut être utilisée en plusieurs événements.
- Interactions_order_iord : Est une table supplémentaire, qui contient une
relation avec ORDER_ID, TYPES_INTERACTION_ORDER_TIORD et
work_services_wser (autre table supplémentaire).
- WORK_SERVICE_WSER Une table supplémentaire sera utilisée dans
main_screen_wait pour obtenir l’identifiant de l’événement. Chaque
événement doit être associé à cette table. L'identifiant enregistré dans
WORK_SERVICE_WSER ne peut apparaître qu'une seule fois dans la table
EVENTS_EVE, mais l'identifiant de la table EVENTS_EVE peut être utilisé
plusieurs fois dans la table WORK_SERVICE_WSER. En ce qui concerne les
travailleurs, la table WORKERS_WOR est en relation avec la table
EVENTS_EVE, formant une relation N-N (many-to-many). Ainsi, l'identifiant
de ces deux tables doit être enregistré dans la table
WORK_SERVICE_WSER. Un travailleur peut être affecté à 0 ou plusieurs
événements, et un événement peut avoir 0 ou plusieurs travailleurs. La table

May 30, 2024 22

 EVALUATION PROJET ANALYSE ET CONCEPTION

JOBS_JOB est liée à la table car un poste de travail peut être associé à
aucun ou plusieurs événements, et un événement peut recruter un travailleur
pour un poste de travail spécifique. De plus, plusieurs travailleurs peuvent
être affectés au même poste de travail lors d'un événement, ce qui implique
une relation N-N (many-to-many).
- CATEGORIES_SALEITEMS_CSITE <-> SALEITEMS_SITE : il existe une
relation 1-N (One-to-many) entre ces deux tables, car un produit ou recette ne
peut appartenir qu’à une catégorie (boissons, snacks, repas), mais une
catégorie peut contenir plusieurs produits et recettes.
INTERACTIONS_ORDER_IORD : C’est une table supplémentaire qui permet
d’établir une relation ternaire avec TYPES_INTERACTION_ORDER_TIORD,
ORDERS_ORD et WORK_SERVICES_WSER. Une commande peut

MLD Sprint 1 MAIN_SCREEN_WAIT SMA_WAIT_01

MLD Sprint 1 MAIN_SCREEN_WAIT SMA_WAIT_01:

Rêquete

May 30, 2024 23

 EVALUATION PROJET ANALYSE ET CONCEPTION

Statuts de la commande DET : Accès au diagram

May 30, 2024 24

 EVALUATION PROJET ANALYSE ET CONCEPTION

Sprint 2 :

Recevoir une nouvelle commande / Receive new orders supra

CRUD event supra

Sprint 3 :

May 30, 2024 25

 EVALUATION PROJET ANALYSE ET CONCEPTION

Confirmer le paiement / Confirm Payment supra

Gérer la commande / Manage an order supra
Mettre la commande en attente / Putting order on hold supra
Reprendre la commande / Resuming a pending order supra
Annuler la commande / Cancel order supra

Sprint 4 :
Enregistrer l’inventaire initial /Record the initial inventory supra
Enregistrer l’inventaire résiduelle / Record the residual inventory
supra
Gérer l’inventaire / Manage the inventory supra
Sprint 5 :
Afficher un raport d’événement / View an event report above
Sprint 6:
Consulter un rapport d’événement / consult the income of an event
Consulter les revenus d’un événement / Consult the income of an
event : Cette fonction est donnée pour expliquer de façon détaillée
chaque ventes et dépenses d’un événement. c_r_e 1above
Achat d’un ticket de boissons / Purchasing drink ticket above

Sprint 7:
Se connecter / s’enregistrer - Log-in /Sign up above
Modifier options / Modify options above

May 30, 2024 26

 EVALUATION PROJET ANALYSE ET CONCEPTION

Si le caissier va encaisser et pas le serveur, dans ce cas on peut laisser la

commande on attente jusqu’au client passe par le caissier, le caissier doit
procéder à passer la commande à ‘envoyée’, c’est dans le cas où soit
obligatoire, mais on peut offre la possibilité de réaliser le paiement avec le
serveur.
Si le caissier va encaisser et le serveur, le paiement n’est pas obligatoire, on
peut permettre au serveur d’envoyer la commande

Envoyée pas modifie – préparateur peut modifier

Envoyée modificacion – préparateur ne va la voir à son écran
Server ne peut pas la modifier, on offre une nouvelle facture - Préparateur
change à en préparation

May 30, 2024 27

 EVALUATION PROJET ANALYSE ET CONCEPTION

Présentation avec explications du projet et du diagramme des cas d’utilisation

Vous présentez le DCU en expliquant chaque CU éventuellement par commentaires sur les
DCU, sous la forma de notes UML, ou dans un texte à part.

May 30, 2024 28

EVALUATION PROJET ANALYSE ET CONCEPTION

Présenté le product backlog priorisé

May 30, 2024 29

 EVALUATION PROJET ANALYSE ET CONCEPTION

Remarque importante :
Typiquement, un écran (IHM) permet de déclencher des événements qui entrainent certaines
actions : Choisir un article, valider un ajout, etc. Ces actions sont constituées d’opérations en
base de données ou de traitement en mémoire (comme trier un tableau par exemple).
Il est primordial de détailler ces actions afin de démontrer la cohérence de votre conception.
Les actions CRUD seront décrites en français ou SQL

Application dans sa globalité : le diagramme de navigation, l’erd et son MLD

May 30, 2024 30

 EVALUATION PROJET ANALYSE ET CONCEPTION

La conclusion
Conclusion :
- Nous essaierons que les informations de ce document servent de référence
pour la réalisation de l'application à travers un langage de programmation.

May 30, 2024 31

EVALUATION PROJET ANALYSE ET CONCEPTION

Bibliographie :

(Drumond, 2024)

May 30, 2024 32

EVALUATION PROJET ANALYSE ET CONCEPTION

May 30, 2024 33