Discussion :

[SQLpro]

Voici un exercice de style que je donne en troisième exercice à mes étudiants... J'aimerais en avoir quelques critiques !

1 - ÉNONCÉ

La FFE, Fédération Française des Échecs vous demande de modéliser les tournois qu'elle organise dans toute la France.
Il y a trois sortes de tournois : "cadence lente", "une heure KO" et "Rapides & Blitz".
Chaque tournoi est organisé dans une ville à une date précise, par une ligue. Certains tournois peuvent être annuels d'autres semestriel trimestriels...
Un tournois consiste à opposer les joueurs deux à deux afin que l'un sorte gagnant.
Le gagnant d'une manche est celui qui :

• gagne la partie par un mat, un abandon ou une faute de l'adversaire,
• gagne la revanche en cas de pat (partie nulle),
• à utilisé le moins de temps pour jouer ses coups en cas de pats successifs (partie et manche)

Seul le gagnant d'une manche peut continuer le tournoi.
Au final il ne reste jamais qu'un seul vainqueur et le classement est sans ex aequo.

Par exemple à 16 joueurs inscrits il faut 4 manches pour classer tout le monde :

• la première manche oppose 8 joueurs à 8 autres joueurs
• la seconde oppose parmi les 8 joueurs restant 4 joueurs à 4 autres joueurs
• la troisième oppose parmi les 4 joueurs restant 2 joueurs à 2 autres joueurs
• la dernière oppose les 2 joueurs restants

Seul le vainqueur d'un tournoi peut prétendre à s'inscrire à un tournoi de niveau supérieur.

Au cours de la partie on enregistre tous les mouvements des joueurs et le temps de chaque coup. Les blancs commencent toujours les parties.

Votre travail consiste à modéliser à la fois les rencontres futures et passées, les inscriptions ainsi que les parties jouées dans tous les tournois. Vous veillerez notamment à ce que les coups joués soient réguliers en proposant une méthode pour éviter les erreurs de saisie.

Élaborez le modèle conceptuel de données avec la notation MERISE.

2 - MCD PROPOSÉ

2.1 - Personne



2.2 - Parties



2.3 - Jeu



--> modifié, version définitive

3 - RÈGLES DE GESTION

• R_VALIDATION_COUP_JOUE : Le coup joué dans une partie doit figurer dans la tables des mouvement autorisés
• R_VALIDATION_COUP_NUMERO : Les numéro des coups dans la partie doivent se suivent sans trou et sans redondance (Validation)
• R_VALIDATION_DATE : Vérifier que l'inscription se fasse avant la date du tournoi (Contrainte)
• R_VALIDATION_INSCRIPTION : Le joueur doit avoir un niveau supérieur au niveau du tournoi pour s'inscrire (Validation)
• R_VALIDATION_NOM : Valider qu'un nom ne doit avoir que des lettres et éventuellement les caractères espace, tiret et apostrophe sauf aux extrémités (Contrainte)
• R_VALIDATION_PARTIE : Dans une partie un joueur ne peut pas jouer contre lui-même (Contrainte)
• R_VALIDATION_REVANCHE : Une revanche ne doit pas être chainée à une partie déjà en revanche (Validation)
• R_VALIDATION_TEL : Valider la saisie des n° de téléphone (Contrainte)
• R_VALIDATION_TOUR_MANCHE : Doit être une puissance de 2 (Contrainte)

--> contraintes ajoutées

• R_VALIDATION_EP : Le pion peut prendre en passant le pion adverse que si le pion adverse a avancé de deux cases
• R_VALIDATION_ROQUE : Vérifier que le roi et la tour n'ont pas été déplacé, vérifier que les cases sont libre entre les deux, ne noter que le déplacement du Roi
• R_VALIDATION_TRAJET : Les cases parcourue par un mouvement doivent être libre

Merci d'avance pour vos commentaires....

PS : le MCD est maintenant complet au niveau du contrôle des coups joués.

A +

[escartefigue]

Bonjour Fred,

Je ne suis pas expert en échecs mais il me semble que la contrainte R_VALIDATION_TRAJET n'est pas applicable pour le cavalier, à ma connaissance, seule la case d'arrivée doit être libre.

Pour le reste

Avoir modélisé rangée et colonne ne parait pas utile, ces entités-type n'ont pas d'attribut, une simple contrainte check sur les plages de valeurs devrait suffire

Les cardinalités de plateau vers pièce devraient être 0,n et non 1,1 (un plateau contient zéro à plusieurs pièces)

Pour les pièces, il faut distinguer la pièce et le type de pièces : c'est chaque pièce qui effectue un mouvement, mais le type de mouvement autorisé dépend du type de pièce
Le mouvement pourrait être identifié relativement à la pièce et à la partie

Comment sera vérifiée la contrainte R_VALIDATION_ROQUE ?

Dans le sous-ensemble "personnes", les téléphones, email et adresse pouraient être identifiés relativement à la personne

[SQLpro]

Bonjour Fred,

Je ne suis pas expert en échecs mais il me semble que la contrainte R_VALIDATION_TRAJET n'est pas applicable pour le cavalier, à ma connaissance, seule la case d'arrivée doit être libre.

Tout à fait, le cavalier saute. C'est pourquoi la cardinalité est 0,n entre l'entité MOUVEMENT AUTORISE et "passe par"

Pour le reste

Avoir modélisé rangée et colonne ne parait pas utile, ces entités-type n'ont pas d'attribut, une simple contrainte check sur les plages de valeurs devrait suffire

Oui, mais c'est un exercice de style !

Les cardinalités de plateau vers pièce devraient être 0,n et non 1,1 (un plateau contient zéro à plusieurs pièces)

Le plateau sert à indiquer, au cours de la partie, la position de toutes les pièces. Il évolue en fonction du coup joué. Une partie est donc associée à n lignes dans le plateau à raison d'une ligne par pièce positionnées.

Pour les pièces, il faut distinguer la pièce et le type de pièces : c'est chaque pièce qui effectue un mouvement, mais le type de mouvement autorisé dépend du type de pièce
Le mouvement pourrait être identifié relativement à la pièce et à la partie

Non, pas besoin de ni l'un ni l'autre. À l'exception du pion, les pièces évoluent de la même façon qu'elles soient noire ou blanche. Nous avons rajouté l'attribut MVA_BLANC pour distinguer les mouvements des pions noir ou blanc et si NULL des autres pièces. De même pour l'attribut MVA_PRISE pour gérer la "prise en passant".

Comment sera vérifiée la contrainte R_VALIDATION_ROQUE ?

Le mouvement du Roi sera stocké. Seul cas ou son déplacement est de 2 (petit roque) ou 3 (grand roque)

Dans le sous-ensemble "personnes", les téléphones, email et adresse pouraient être identifiés relativement à la personne

Bof....

A +

[Puiss51]

Le mouvement du Roi sera stocké. Seul cas ou son déplacement est de 2 (petit roque) ou 3 (grand roque)

Je ne peux pas intervenir pour la modélisation par contre pour les échecs oui : quel que soit le roque, le roi se déplace de 2 cases

[SQLpro]

Je ne peux pas intervenir pour la modélisation par contre pour les échecs oui : quel que soit le roque, le roi se déplace de 2 cases

Oui, c'est intégré.

A +

[JPhi33]

Bonjour Fred,

MCD Personne

• J'aurais identifié Adresse ligne relativement à Adresse.

MCD Parties

• On ne voit qu'une cardinalité pour les deux pattes [Partie]---(Revanche) et [Partie]---(joue blanc). Je suppose que la cardinalité 0,1 appartient à la patte de gauche de [Partie]---(Revanche), et que la cardinalité de la patte [Partie]---(joue blanc) est 1,1 et quelle est masquée...
• J'aurais identifié Partie relativement à Manche et Manche relativement à Edition du Tournoi.
• En raison de cette phrase de l'énoncé : "Certains tournois peuvent être annuels d'autres semestriel trimestriels...", il serait intéressant d'associer une entité Fréquence à Tournoi :
  [ Tournoi ]--0,1----( )----0,n->[ Fréquence ]

MCD Jeu

• J'aurais identifié Mouvement relativement à Partie
• Je crois comprendre que l'entité Plateau permet de savoir, au fur et à mesure du déroulement de la partie, quelle case est occupée par quelle pièce, ce qui permet notamment de vérifier si le coup est légal au regard du Trajet. La contrainte qui vérifie ça risque d'être gourmande en ressources. Il me semble qu'elle serait optimisée si Plateau était identifié par la case et et la partie. Autrement dit, Plateau serait une association entre CASE et Partie avec une CIF vers Piece.
• Les entités Mouvement autorisé et Trajet vont donner lieu à des tables plutôt conséquentes. Exemple : une tour a 14 mouvements autorisés par case et peut se situer sur n'importe laquelle des 64 cases de l'échiquier, ce qui lui confère 896 mouvements autorisés. Pour chaque case sur laquelle la tour est située, il y aura 42 occurrences de Trajet (si l'on exclut les cases de départ et d'arrivée), ce qui donnera 2688 occurrences de Trajet pour l'ensemble des mouvements autorisés de la tour. Mais bon, une fois que ces tables sont alimentées, ça ne bouge plus.

Certes, il ne s'agit que d'un exercice, mais tant qu'à faire, autant se projeter dans la réalisation d'une application réelle.

Jean-Philippe