629 lines
34 KiB
Markdown
629 lines
34 KiB
Markdown
# 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
|
||
```
|