# BDW - Projet

# DeezCycle 🚴

### UCBL - Département Informatique de Lyon 1 – Printemps 2024

## Connect 🌐

```
ssh p22XXXXX@bdw.univ-lyon1.fr
```

## Transfer 📬

```
scp -r ./DeezCycle p2203977@bdw.univ-lyon1.fr:~
```

## Site 🎲

https://bdw.univ-lyon1.fr/p22XXXXX/DeezCycle/

## Table des matières

**1 Informations générales sur le projet 1**

**2 Spécification de l’application 2**

**3 Mise en place de la Base de Données 5**
3.1 Construction de la base de données................................... 5
3.2 Intégration des données fournies.................................... 5

**4 Les fonctionnalités 5**
4.1 Page d’accueil et statistiques...................................... 6
4.2 Fonctionnalité 1 : Liste des parties terminée et en cours....................... 6
4.3 Fonctionnalité 2 : Mise en place de la partie.............................. 7
4.4 Fonctionnalité 3 : Déroulé d’une partie................................. 8
4.5 Fonctionnalité 4 : fonctionnalités supplémentaires........................... 9

**5 Déroulé du projet et jalons 9**
5.1 Les jalons................................................. 9
5.2 Rendu du projet............................................. 9
5.3 Calendrier récapitulatif......................................... 10

**6 ANNEXE A : à propos de l’intégration de données 11**

## 1 Informations générales sur le projet

Le projet est à réaliser **en binôme** (les trinômes ne sont pas autorisés). La réalisation du projet en monôme
nécessite l’accord du responsable de l’UE.

À noter que la réalisation du projet nécessitera un travail personnel et/ou collaboratif complémentaire au
travail réalisé durant les séances de TP. Il est donc important de choisir un binôme avec un emploi du temps
compatible avec le vôtre.

### À propos de l’évaluation du projet

Le projet est évalué à travers les notes issues des différents QCM de Validation des Acquis pour le Projet,
de l’évaluation des jalons et de la soutenance finale.

**Gestion du plagiat**. Il est important de noter que toute ressemblance trop importante entre des projets
sera sanctionnée par un 0 à chacun des protagonistes.

**BDW est avant tout une UE d’introduction aux bases de données**. La non-utilisation d’une BD
relationnelle dans le projet impactera forcément la note de manière négative.

**Attention à la gestion de votre temps!** La mise en place de jalons réguliers est là pour vous aider dans
ce sens. En effet, il a souvent été observé que des étudiants passaient trop de temps sur les aspects modélisa-
tion (avec l’objectif d’avoir un schéma EA parfait) au détriment du développement des fonctionnalités dont la

compréhension tardive imposait finalement de modifier le schéma EA _a posteriori_.

## 2 Spécification de l’application

L’objectif du projet est de développer un jeu de dés _via_ une application web. Ce jeu est fortement inspiré
du jeu DICYCLE RACE présenté en cours.

Le principe du jeu est le suivant : chaque joueur est un cycliste qui doit arriver le premier au bout du
parcours qui est composé de 12 cartes. Pour avancer sur une case, il faut que le joueur réalise la combinaison de
dés demandée sur la carte. Pour cela, chaque joueur dispose de 6 dés de couleur bleue, 6 dés de couleur jaune
et 6 dés de couleur rouge. À chaque tour, le joueur choisit 6 dés parmi les 18 dés de couleurs pour essayer de
valider une ou plusieurs cases en au plus 3 lancers. Différentes stratégies peuvent être mises en place en fonction
du nombre de cartes que le joueur souhaite valider en un tour.

Cette section va vous permettre de modéliser et concevoir la base de données sur laquelle s’appuiera votre
application web. À partir de cette spécification, il est important de bien distinguer les données qui devront être
stockées de celles qui seront calculées.

Dans un premier temps, nous considérons les joueurs. Les joueurs sont identifiés par un entier numérique et
on stocke le nom, le prénom, la date de naissance, un pseudo et une adresse mail.

Un joueur joue des parties. Une partie est identifiée par une valeur numérique et on stocke la date et l’heure
du début de partie ainsi que la durée une fois que la partie est terminée. Une partie a donc un état qui peut
être ’A venir’ (partie paramétrée et créée mais non encore commencée), ’En cours’ (partie en cours de jeu ou
interrompue) et ’Terminée’ (partie où tous les joueurs ont fini le parcours).

Pour chaque partie, on dispose d’un plateau composé de plusieurs cartes. Chaque plateau a un nombre de
cartes fixé. Par défaut, un plateau est composé de 12 cartes.

Pour chaque carte, on dispose d’une image pour représenter le visuel de la carte. Une carte dispose d’un
niveau (vert, orange ou noir) en fonction du niveau de difficulté de celle-ci. Chaque carte dispose également
de points, là encore définis en fonction de la difficulté de la carte. Une carte est associée à une ou plusieurs
contraintes de base. Ces contraintes ont un nom et on en considère quatre :

— une contrainte nommée **"face de dé"** représentée par le couple ( _coul_ , _val_ ), où _coul_ ∈{’rouge’,’jaune’,’bleu’}
et _val_ ∈{1, 2, 3, 4, 5, 6} : Pour valider cette contrainte, le joueur doit obtenir au moins un dé de couleur
_coul_ avec la valeur _val_.
— une contrainte nommée **"seuil de dés"** représentée par le triplet ( _coul_ , _seuil_ , _sens_ ), où _coul_ ∈{’rou-
ge’,’jaune’,’bleu’}, _seuil_ ∈{2,.. ., 36} et _sens_ ∈{ _<_ , _>_ } : Pour valider cette contrainte, le joueur doit
obtenir un score cumulé de valeurs de dés de couleur _coul_ qui soit strictement supérieur ou inférieur (selon
la valeur de _sens_ ) à la valeur _seuil_.
— une contrainte nommée **"les mêmes au choix"** représentée par le couple ( _coul_ , _nb_ ), où _coul_ ∈{’rou-
ge’,’jaune’,’bleu’} et _nb_ ∈{2, 3, 4} : Pour valider cette contrainte, le joueur doit obtenir au moins _nb_ dés
de même valeur et de couleur _coul_.
— une contrainte nommée **"suite au choix"** représentée par le singleton ( _coul_ , _nb_ ), où _coul_ ∈ {’rou-
ge’,’jaune’,’bleu’} et _nb_ ∈{2, 3, 4} : Pour valider cette contrainte, le joueur doit obtenir au moins _nb_
dés de valeurs successives et de couleur _coul_.
À partir de ces contraintes, il est possible d’associer à chaque carte une ou plusieurs contraintes. Ainsi, la
Figure 1 représente trois cartes associées à une ou plusieurs contraintes "face de dés".

La carte C005.png est associée à une contrainte "face de dé" (’bleu’,5). La carte C020.png est associée aux
contraintes "face de dé" (’bleu’,2) et (’rouge’,4). La carte C039.png est associée aux contraintes "face de dé"
(’jaune’,3), (’rouge’,3) (’bleu’,3). À noter que C039.png n’est pas associée à une contrainte "les mêmes au choix"
car les couleurs imposées par dé sont différentes.

```
Figure 1– Exemple de 3 cartes associées à une ou plusieurs contraintes "face de dés"
```

```
Figure 2– Exemple de cartes associées à des contraintes "face de dé", "seuil de dés" et "les mêmes au choix"
```

D’autres exemples sont sur la Figure 2.
La carte C053.png est associée à une contrainte "seuil de dés" (’jaune’,14, ’ _>_ ’). La carte C072.png est asso-
ciée aux contraintes "seuil de dés" (’rouge’,4, ’ _<_ ’) et "face de dé" (’jaune’,2). La carte C056.png est associée à
la contrainte "les mêmes au choix" (’bleu’,3).

Pour finir, la Figure 3 représente trois cartes associées à des contraintes "face de dé", "les mêmes au choix"
et "suite au choix".

```
Figure 3– Exemple de 3 cartes associées à une ou plusieurs contraintes "face de dés"
```

La carte C070.png est associée aux contraintes "les mêmes au choix" (’jaune’, 2) et "face de dé" (’jaune’, 2).
La carte C068.png est associée à la contrainte "série au choix" (’rouge’, 3). La carte C073.png est associée aux
contraintes "les mêmes au choix" (’bleu’,2) et "série au choix" (’rouge’, 2).

```
À noter que sur les 3 figures, le niveau des cartes est représenté par la couleur de fond de la pastille des
```

points. Les cartes C005.png et C020.png sont des cartes vertes valant 1 point. Les cartes C053.png et C072.png
sont des cartes vertes valant 2 points. Les cartes C039.png, C056.png, C070.png et C068.png sont des cartes
oranges valant 4 points. Enfin la carte C073.png est une carte noire valant 5 points.

Au début d’une partie, une couleur de pion est attribuée aléatoirement à chaque joueur. Chaque pion est
placé sur la carte ’départ’.
Un ordre de passage est choisi. Trois modes sont possibles :
— Un mode dit **honneur au plus jeune** : l’ordre de passage se fait du plus jeune au plus ancien en fonction
de la date de naissance des joueurs. Pour les joueurs nés le même jour, l’ordre de passage se fera en fonction
du nom selon l’ordre lexicographique.
— Un mode dit **honneur au moins expérimenté** : l’ordre de passage se fait du joueurs ayant fait le moins
de parties à celui qui en a fait le plus. Pour les joueurs ayant fait le même nombre de parties, l’ordre de
passage se fera en fonction du nom selon l’ordre lexicographique.
— Un mode dit **aléatoire** : l’ordre de passage se fait de manière aléatoire.
Une partie se déroule en plusieurs tours (autant que nécessaires pour que tous les joueurs franchissent la
carte ’arrivée’).
À chaque tour, chaque joueur choisit une main constituée de 6 dés dont un certain nombre de dés rouges, de
dés jaunes et de dès bleus. À partir de cette main, le joueur a droit à au plus 3 lancers. Après chaque lancer, le
joueur sélectionne le ou les dés qui permettent de valider une ou plusieurs contraintes de la prochaine carte sur
laquelle il veut avancer. Si toutes les contraintes de la carte sont validées, le pion du joueur peut alors avancer
sur cette carte.

En termes de stratégie pour avancer plus vite, le joueur peut chercher à valider plusieurs cartes lors d’un
même tour. Toutefois, s’il se trouve sur la carte _n_ , qu’il arrive à valider entièrement les contraintes de la carte
_n_ +2mais que la carte _n_ +1n’est pas entièrement validée au bout des 3 lancers, le pion du joueur n’avancera pas.

```
L’ordre d’arrivée des joueurs permet d’établir le classement final.
```

La gestion des scores se fait de la manière suivante :
— Pendant la partie, chaque joueur cumule les points des cartes qu’il a validées, points qui sont pondérées
de la manière suivante, sachant qu’une tentative de validation correspond à un tour (et non un lancer) :
— le joueur cumule 3 fois le nombre de points de la carte, s’il la valide à la première tentative ;
— le joueur cumule 2 fois le nombre de points de la carte, s’il la valide à la seconde tentative ;
— le joueur cumule le nombre de points de la carte, s’il la valide à la troisième tentative ;
— le joueur ne cumule aucun point au-delà de la troisième tentative.
— Pendant un tour, le nombre de points cumulés durant le tour est multiplié par le nombre de cartes validées
durant ledit tour.
— À l’arrivée d’un joueur, son score correspond au nombre de points cumulés durant la partie multiplié par
la pondération _δ_ , où _δ_ correspond au nombre total de joueurs de la partie auquel on retranche le rang final
dudit joueur augmenté de un. Ainsi, pour une partie avec 5 joueurs, le joueur de rang 1 verra son nombre
de points cumulés multiplié par (5-1+1=) 5 et le dernier verra son nombre de points cumulés multiplié
par (5-5+1) = 1.
Élément très important : l’application doit permettre à un joueur de se déconnecter (volontairement ou non)
et de pouvoir reprendre la partie là où il en était. Ainsi, la position des pions sur le plateau, la valeur des dés
lancés durant un tour, le nombre de points cumulés, le nombre de tentatives de validation d’une carte par un
joueur doivent être mémorisés en base.

En marge des parties, on souhaite gérer également l’organisation de tournois et les classements de joueurs.
Concernant les tournois, un tournoi est identifié par un entier numérique et il a un nom, une date de début et
une date de fin. Un tournoi se décompose en phase. Une phase est identifiée relativement au tournoi par rapport
à un niveau ’Poule de sélection’, ’Seizième de finale’, ’Huitième de finale’, ’Quart de finale’, ’Demi-finale’ et
’Finale’. Un joueur participe à une phase de tournoi et on stocke l’information si le joueur a joué la phase et
s’il s’est qualifié pour la phase suivante ou pas. À noter que si le joueur est qualifié pour la phase de niveau
’Finale’, cela signifie qu’il a gagné le tournoi. Les différentes éditions des tournois sont gérées par le fait que les

tournois peuvent être en lien les uns avec les autres. Ainsi, le tournoi nommé ’DeezCycle France 2024’ est
en lien avec le tournoi nommé ’DeezCycle Race France 2023’. Le type de lien entre les deux tournois est un lien
d’édition.
Les classements se font en fonction des points cumulés et du nombre de parties jouées. Un classement est
identifié par un entier et on stocke la portée du classement (’internationale’, ’nationale’, ’régionale’.. .). Il existe
alors différents classements. Les joueurs peuvent être classés de manière individuelle ou en équipe. En effet, un
joueur peut être membre d’une équipe. Les résultats des membres d’une équipe sont agrégés, ce qui permet de
classer les équipes. Au même titre que les tournois, les classements peuvent être en lien. Ainsi, le Classement
international ’World DeezCycle Ranking’ est en lien avec le classement national ’DeezCycle Race France’. Les
types de lien peuvent être hiérarchiques.

## 3 Mise en place de la Base de Données

### 3.1 Construction de la base de données

Dans un premier temps, vous allez concevoir la base de données à partir des spécifications précédentes. Votre
modélisation doit respecter au mieux ces spécifications.

1. Produire un diagramme Entité/Association selon les spécifications fournies _via_ l’outil _mocodo_ (version en
   ligne https://www.mocodo.net/) ou Looping.
2. Produire le modèle relationnel dérivé de votre schéma Entité/Association. Attention : si vous générez
   automatiquement ce schéma avec l’outil de modélisation, il est fortement recommandé de le vérifier pour
   éventuellement le corriger ou le compléter.
3. Produire le script SQL permettant le création de votre base de données ( _idem_ que précédemment, il sera
   sûrement nécessaire de le modifier si vous le générez automatiquement).

### 3.2 Intégration des données fournies

Dans un deuxième temps, vous allez migrer les données existantes fournies dans la base de données _dataset_
dans votre base de données. L’utilisation de ces données est **obligatoire**. Les données fournies sont stockées
dans une table qui ne correspond pas à votre modèle de données, il va donc être nécessaire de transformer les
données fournies pour pouvoir les insérer dans vos tables. Ce processus, que l’on appelle _intégration de données_
sera réalisé à travers des requêtes SQL que vous exécuterez dans PHPMyAdmin.
L’étape d’intégration peut se décomposer en 3 parties :

1. Réfléchir aux correspondances entre les données existantes et votre schéma ( _e.g.,_ à quel attribut de votre
   schéma correspond tel attribut fourni). Vérifier si les types de données sont cohérents entre attributs
   correspondants et quelles sont les transformations nécessaires au niveau des valeurs. Il est important de
   comprendre que le jeu de données fourni n’est pas bien modélisé. En conséquence si vous modélisez votre
   schéma de base de données avec l’objectif d’intégrer facilement les données fournies, votre schéma ne
   respectera plus les spécifications demandées.
2. Écrire les d’insertion du type _INSERT INTO maTable SELECT ... FROM donnees_fournies.instancesX ;_
   permettant de peupler votre base.
   Il est important de noter que la base _donnees_fournies_ sera à terme (avant la soutenance) supprimée. Donc
   les données doivent être absolument récupérées dans votre propre base de données.

**Remarque** : il n’est pas demandé de développer une fonctionnalité permettant de gérer l’intégration depuis
votre interface Web.
Pour bien comprendre le principe par l’exemple, vous pouvez vous référer à l’annexe A.

## 4 Les fonctionnalités

Dans ce projet, vous allez avoir à développer des interfaces associées aux fonctionnalités décrites dans cette
section.
Il est important dans un premier temps de définir (ou récupérer dans les TP4-5) ces primitives de votre
modèle que vous pourrez alors utiliser pour le développement des fonctionnalités.

Vous disposez avec le sujet des ressources graphiques associées aux cartes dans le répertoire RessourcesGra-
phiques*DéBiclou. Les 75 cartes proposées sont définies dans la base \_donnees_fournies* dans la table _’ressources’_.

### 4.1 Page d’accueil et statistiques

En parallèle du processus d’intégration, vous pouvez commencer à mettre en place votre site WEB à partir
du code fourni lors des TP précédent. Il est important de conserver l’approche MVC que l’on vous a apprise.

**À propos des statistiques**

La première fonctionnalité de votre application est de mettre en place la page d’accueil qui offre un descriptif
de l’application et un ensemble d’informations et de statistiques. Parmi ces informations et ces statistiques, il
est demandé d’avoir au moins :

```
— "un n-uplet contenant le nombre de joueurs, le nombre d’équipes, le nombre de classements, le nombre de
tournois et la moyenne des participants par tournoi".
— "les phases de tournoi (nom et année de tournoi, niveau de phase) jouées et pour lesquelles s’est qualifié
l’utilisateur courant. Le résultat sera trié sur les années selon l’ordre antéchronologique puis sur les niveaux
de phase selon l’ordre lexicographique inverse".
— "le nombre d’équipes classées premières des classements et dont aucun des membres n’est premier dans
un classement individuel".
— "Pour les 3 dernières années, donner le nombre moyen de participants aux tournois".
— "Donner le nom et le prénom des joueurs classés de manière individuelle dans le top 5 d’au moins 2
classements de portée nationale".
— "Pour chaque taille de plateau, donner le nombre de parties jouées avec un plateau de cette taille".
— "Le top 5 des joueurs (pseudo) qui ont joué le plus de parties".
```

**à propos du design du site**

Chaque page de votre site dispose d’une structure qui vous est imposée. En effet, pour chaque page vous
devez avoir les cinq zones suivantes :

— Un bloc "entête" ( _<header>_ ), qui contient le nom du site et un logo cliquable pour toujours revenir à la
page d’accueil,
— Un bloc "menu" ( _<nav>_ ) dans lequel chaque élément permet d’accéder à une page spécifique,
— Un bloc "contenu de la page" ; contenu qui s’adaptera en fonction de la fonctionnalité à laquelle l’utilisateur
souhaite accéder,
— Un bloc "pied de page" ( _<footer>_ ), qui contiendra au moins un lien vers le site de l’UCBL, le nom des
auteurs du site, l’année de réalisation, un lien vers une page statique contenant le plan du site...
Concernant la mise en forme du site, elle se fera avec des styles CSS. Le projet sera évalué avec le navigateur
Mozilla Firefox, donc vérifiez le rendu de votre site avec ce navigateur!

Concernant le rendu, il est possible d’embellir votre application en ajoutant des composants ou widgets
javascript. Il est cependant important de garder en mémoire que le projet est un projet PHP, donc la proportion
de javascript doit rester raisonnable.

### 4.2 Fonctionnalité 1 : liste des parties terminées et en cours

```
Cette fonctionnalité, que l’on nommera "afficherPartie", consiste à lister les parties se trouvant en base.
```

Pour cette fonctionnalité, on affichera les informations sur les parties sous la forme d’un lien hypertexte
faisant apparaître les informations suivantes (quand celles-ci existent) :

```
— Identifiant de partie,
— Date et horaire de la partie,
— Taille du plateau,
```

```
— Triplet (nbB, nbJ, nbR) représentant respectivement le nombre de cartes vertes, oranges et noires dans la
partie,
— Liste des pseudos des joueurs de la partie,
— Podium (1 e , 2 e et 3 e places) des joueurs avec respectivement leur nombre de points gagnés dans la partie.
Ainsi, vous devez :
```

1. Créer le contrôleur et la vue associés à cette fonctionnalité.
2. Afficher la liste des parties dans l’état ’À venir’.
3. Afficher la liste des parties dans l’état ’En cours’ (potentiellement interrompue).
4. Afficher un formulaire permettant de sélectionner un mode d’affichage des parties terminées. On considé-
   rera une liste déroulante avec au moins les modes d’affichage suivants :
   — "Toutes les parties",
   — "Les 50 parties les plus récentes" avec un tri de la plus récente à la plus ancienne,
   — "Les 50 parties plus rapides par taille de plateau" avec un tri par nombre de cartes décroissant puis,
   pour les parties avec un plateau de même taille, de la plus rapide à la plus lente.

### 4.3 Fonctionnalité 2 : Mise en place de la partie

Cette fonctionnalité, que l’on nommera "creerPartie", consiste à créer en base une partie paramétrée par
l’utilisateur et de lui associer des joueurs.

```
Pour cela, vous devez :
```

1. créer le contrôleur et la vue associés à cette fonctionnalité.
2. afficher, quand aucun formulaire n’est soumis, un formulaire permettant de saisir les paramètres de la
   partie qui contient au moins :
   — le nombre de cartes constituant le plateau (en plus des cartes de départ et d’arrivée)
   — le nombre de cartes vertes à sélectionner
   — le nombre de cartes oranges à sélectionner
   — le nombre de cartes noires à sélectionner
   — un bouton de soumission du formulaire qui déclenche la création de la partie en base.
3. créer la partie en base dans un état ’A venir’. Une fois la partie créée, il faut créer le plateau avec la taille
   saisie dans le formulaire et associer le plateau courant à la partie courante. Une fois le plateau créé, il
   est nécessaire de choisir aléatoirement autant de cartes vertes, oranges et noires que demandées dans le
   formulaire pour les associer au plateau courant. Il sera évidemment nécessaire de s’assurer que le nombre
   de cartes sélectionnées est cohérent avec la taille du plateau.
4. afficher, quand le formulaire de saisie des paramètres de la partie est soumis, un formulaire permettant de
   sélectionner des joueurs, qui contient au moins :
   — une liste déroulante contenant la liste de tous les noms, prénom et pseudo des joueurs en base.
   — un bouton de soumission d’ajout d’une personne, qui rechargera la page en affectant la personne
   sélectionnée à la partie courante. Une couleur sera alors associée aléatoirement à la personne, ce qui
   correspondra à la couleur de son pion dans le jeu.
   — un bouton de soumission de retrait d’une personne, qui rechargera la page en retirant la personne
   sélectionnée de la partie courante (pour gérer les éventuelle erreur d’affectation).
   — une liste déroulante contenant la liste des stratégies d’ordre de passage ’Honneur au plus jeune",
   "Honneur au moins expérimenté" ou "Aléatoire".
   — un bouton de soumission de validation de la partie. En fonction de la stratégie d’ordre de passage des
   joueurs, il est nécessaire de calculer l’ordre de passage des joueurs et de mettre à jour l’information
   en base.
   **Remarque d’amélioration :** Le protocole proposé est une proposition, libre à vous de proposer un
   autre protocole, qui peut se baser sur le principe d’invitation de certains joueurs, d’inscription à la partie par
   publication sur une page des parties en attente de joueurs...

### 4.4 Fonctionnalité 3 : Déroulé d’une partie

```
Cette fonctionnalité, que l’on nommera "jouerPartie", correspond au déroulement d’une partie.
```

```
Pour cela, vous devez :
```

1. créer le contrôleur et la vue associés à cette fonctionnalité.
2. afficher, quand aucun formulaire n’est soumis, les différents éléments permettant le déroulé d’une partie :
   — le plateau contenant les cartes sélectionnées,
   — un numéro au-dessus de chaque carte (hormis carte de départ et d’arrivée) qui servira à associer les
   dés lancés à la carte lors du déroulement de la partie,
   — les pions de chaque joueur placés sur ou à hauteur de la case de départ,
   — la liste des joueurs (pseudo) triée selon l’ordre de passage déterminé précédemment.Le nom des joueur
   doivent apparaître de la couleur correspondant à leur pion.
   — un bouton de soumission pour lancer la partie. Au lancement de la partie, la base est mise à jour
   pour sauvegarder la date et l’horaire de début de partie. L’état de la partie passe à ’En cours’.
3. créer un tour pour la partie. À la création du tour, le pseudo du joueur courant est indiqué et sauvegardé
   en base. Le formulaire précédent s’affichera hormis le bouton de soumission pour lancer la partie qui est
   remplacé par les onglets permettant au joueur courant de choisir une main. On a donc :
   — un onglet de saisie du nombre de dés bleus,
   — un onglet de saisie du nombre de dés jaunes,
   — un onglet de saisie du nombre de dés rouges,
   — un bouton de soumission pour enregistrer la main en base et permettre ensuite au joueur courant de
   lancer 3 fois les dés.
4. créer la main associée au joueur courant pour le tour courant dans la base. Une fois la main créée, afficher :
   — les dés correspondants à la main,
   — le numéro du tour,
   — le nombre de lancers restant,
   — un bouton "lancer les dés" pour que le joueur courant puisse lancer les dés.
5. lancer les dés consiste à choisir aléatoirement des valeurs entre 1 et 6 pour chaque couleur de dés de la
   main. Ce choix est mis en base. Pour permettre ensuite à l’utilisateur d’associer un dé à une carte pour
   valider sa contrainte, le joueur courant verra afficher sur la page :
   — les dés correspondant au lancer,
   — à côté de chaque dé, on affichera une liste déroulante cor-
   respondant au numéro des cartes du plateau qu’il reste à
   parcourir et l’option ’Affecter une carte’ comme représenté
   sur la Figure 4.
   — le nombre de lancers restant,
   — le nombre de tentatives de validation de la carte suivante
   ( _i.e.,_ depuis combien de tours le joueur essaie de valider
   la carte suivante) ,
   — un bouton "lancer les dés" pour que le joueur courant
   puisse lancer les dés.

```
Figure 4 : Illustration de
l’affectation de dés à des cartes
```

6. valider l’affectation d’un dé à une carte. Il est nécessaire de s’assurer que la ou les affectations à une carte
   sont possibles. Si l’affectation est valide, elle est mise en base. Les dés affectés ne peuvent plus être utilisés
   au lancer suivant.
7. avancer le pion du joueur au bout des 3 lancers. Une fois les 3 lancers effectués, identifier la ou les cartes
   dont toutes les contraintes sont validées. Affecter la nouvelle position du joueur et la mettre en base.
   Calculer le nombre de points obtenus par le joueur.
8. passer au joueur suivant en mettant à jour la base.
9. changer de tour, une fois que tous les joueurs ont effectué leurs 3 lancers,

10. détecter si un joueur est arrivé. Dans le cas où le joueur valide la dernière carte (avant celle de l’arrivée),
    le rang final du joueur est mémorisé en base.
11. détecter si tous les joueurs sont arrivés. Dans le cas où le dernier joueur est arrivé, on mémorise la durée
    de la partie et on calcule les scores des joueurs selon le principe décrit dans le cahier des charges. L’état
    de la partie passe à ’Terminée’. On affichera alors :
    — l’ordre d’arrivée des joueurs
    — le nombre de points gagnés pour chaque joueur

**Remarque importante :** Il est rappelé ici qu’à tout moment le navigateur peu être fermé et la partie
interrompue. Il est donc important de bien mettre en base toute information permettant de reprendre la partie
là où elle a été interrompue.

### 4.5 Fonctionnalité 4 : fonctionnalités supplémentaires

En fonction de l’avancement de votre projet, libre à vous de proposer des amélioration dans le déroulé de la
partie, ou des fonctionnalités supplémentaires telles que la gestion des tournois, des classements, la proposition
de nouvelles règles de jeux...

## 5 Déroulé du projet et jalons

```
Lors de la réalisation de votre projet, on vous demande de respecter le calendrier de jalons suivant.
```

### 5.1 Les jalons

#### JALON 1

Lors de la séance de TP du 29/03/2023, vous présenterez votre schéma entité association en l’état. Une
appréciation vous sera alors attribuée.

#### JALON 2

Lors de la séance de TP du 05/04/2023, vous présenterez votre base de données peuplées et les requêtes
statistiques. Une appréciation vous sera alors attribuée.

#### JALON 3

Lors de la séance de TP 13/04/2023, vous présenterez l’état d’avancement du déroulé d’une partie. Une
appréciation vous sera alors attribuée.

### 5.2 Rendu du projet

```
Ce projet est à rendre avec les consignes de rendu suivantes :
— L’archive rendue (un seul par binôme) aura une extension .zip et il doit inclure votre/vos nom(s) à la fois
dans le nom de fichier et en entête de chacun de vos fichiers
— Ce fichier zip contiendra au moins 4 fichiers :
— l’archive contenant les pages de votre site (code commenté et indenté).
— un fichier .sql qui contiendra le script SQL "exécutable" de création de votre base de données,
— un fichier .sql qui contiendra le script SQL "exécutable" d’importation des données dans votre base,
— un fichier contenant votre MCD (schéma E/A).
Ce fichier zip est à rendre le 18 avril à 23h59 dans la zone de dépôt TOMUSS dédiée (Rendu_projet).
```

### 5.3 Calendrier récapitulatif

```
Date Type Description
29/03/23 Jalon 1 Évaluation du schéma E/A en séance
05/04/23 Jalon 2 Évaluation état BD et statistiques en séance
13/04/23 Jalon 3 Évaluation état d’avancement déroulé d’une partie
18/04/23 Jalon 4 Dépôt sur TOMUSS de votre rendu de projet
19/04/23 Soutenance démonstration de l’application
```

## 6 ANNEXE A : à propos de l’intégration de données

```
On considère d’une part, la relation initiale R définie comme suit :
R (idA, A1, A2, B1, B2, C1, C2, D)
```

```
En sachant que D est une valeur numérique représentant une capacité mémoire en Mo.
```

```
D’autre part, on dispose du schéma relationnel suivant :
EA (idA, A1, A2), #idB)
EB (idB, B1, B2)
EC (idC, C1, C2)
ED (#idA, #idC, D)
```

```
En sachant que D est exprimé en Ko.
```

```
Ce modèle relationnel répond au schéma Entité/Association suivant :
```

```
Comment intégrer les données de R dans les relation EA, EB, EC, ED?
```

1. **Création de la table EB** : comme EB ne dispose d’aucune contrainte de clé étrangère, nous allons
   commencer par créer la table correspondante. Cependant, il n’y a pas de valeur deidBdans R. Nous
   allons donc définiridB de typeinteger avec unAUTO_INCREMENT. On peut donc créer la EB de la
   manière suivante :
   CREATE TABLE EB (
   idB integer AUTO_INCREMENT PRIMARY KEY,
   B1 varchar(100),
   B2 varchar(100)
   )
2. **Création de la table EC** : on utilise le même principe que précédemment. On peut donc créer la EC
   de la manière suivante :
   CREATE TABLE EC (
   idC integer AUTO_INCREMENT PRIMARY KEY,
   C1 varchar(100),
   C2 varchar(100)
   )
3. **Création de la table EA** : comme l’identifiantidAde ’EA’ se trouve dans R, il est possible de récupérer
   directement sa valeur dans R. On peut donc créer la EA de la manière suivante :
   CREATE TABLE EA (
   idA integer PRIMARY KEY,
   A1 varchar(100),
   A2 varchar(100),
   idB integer
   ) ;
   ALTER TABLE EA ADD CONSTRAINT fk_EA_EB FOREING KEY (idB) REFERENCES EB (idB) ;
4. **Création de la table ED** : La table ED peut être définie de la manière suivante :

#### CREATE TABLE ED (

```
idA integer,
idB integer,
D integer ) ;
```

```
ALTER TABLE ED ADD CONSTRAINT fk_ED_EA FOREING KEY (idA) REFERENCES EA (idA) ;
ALTER TABLE ED ADD CONSTRAINT fk_ED_EB FOREING KEY (idB) REFERENCES EB (idB) ;
```

5. **Peuplement de la table EB** : Pour cela, il est possible d’utiliser la requête suivante :

```
INSERT INTO EB (B1, B2) SELECT DISTINCT B1, B2 FROM R ;
```

```
Les valeurs deidBsont alors définies.
```

6. **Peuplement de la table EC** : Pour cela, il est possible d’utiliser la requête suivante :

```
INSERT INTO EB (B1, B2) SELECT DISTINCT B1, B2 FROM R ;
```

```
Les valeurs deidBsont alors définies.
```

7. **Peuplement de la table EA** : Pour cela, il est possible d’utiliser la requête suivante :

```
INSERT INTO EA (idA, A1, A2, idB)
SELECT DISTINCT R.idA, R.A1, R.A2, EB.idB FROM R JOIN EB ON R.B1 = EB.B1 AND
R.B2 = EB.B2 ;
```

```
La valeur deidBen clé étrangère est retrouvée grâce à la jointure sur B1 et B2, que l’on sait unique dans
ce cas particulier (du fait de la manière dont on a peuplé EB). Dans le cas général, il sera important de
s’assurer que les attributs de jointures garantissent d’identifier de manière unique le n-uplet.
```

8. **Peuplement de la table ED** : Pour cela, il est possible d’utiliser la requête suivante en transformant
   les données quand cela est nécessaire :

```
INSERT INTO ED (idA, idC, D)
SELECT DISTINCT R.idA, EC.idC, (1024 * R.D) as D FROM R JOIN EC ON R.C1 = EC.C1 AND
R.C2 = EC.C
```