Embed Size (px)
Citation preview
TP de C# .NETOBJECTIFS
Ce document est une aide pour la réalisation des travaux pratiques de C#. Il vous propose
notamment différents diagrammes comme support. Il ne se substitue pas entièrement aux
explications données en cours ou en TP.
TABLE DES MODIFICATIONS
Auteur Modifications Version DateMarc Chevaldonné Description du TP 1 1.0 12 septembre 2012
Marc Chevaldonné • [email protected] • IUT Informatique Clermont1 1
IntroductionCette série de 14 TP a pour objectif la réalisation du jeu Plus4. Il est vivement conseillé de lire les règles du jeu avant de faire les TP :)Ces premières pages vous présentent de manière simplifiée l’architecture de notre programme, i.e. de nos bibliothèques et de nos exécutables.
NOYAU ET INTERFACE GRAPHIQUE
Un des points les plus importants est de bien séparer le noyau de l’application (c’est-à-dire le
fonctionnement du jeu : gestion des joueurs, des règles du jeu, de l’état du jeu...) de
l’interface graphique (ou non) permettant aux utilisateurs d’interagir avec le jeu.
Nous allons donc créer un premier assemblage de type bibliothèque dynamique (dll) que nous
appellerons giCore.dll et qui contiendra toutes les classes nécessaires au fonctionnement
de notre programme. Ensuite, nous créerons d’autres assemblages de type exécutables (exe)
qui dépendront de giCore.dll et l’utiliseront pour permettre aux clients d’interagir avec et
de visualiser le jeu. Nous créerons des exécutables de tests pour tester nos classes de giCore,
un exécutable en affichage Console pour vérifier le bon fonctionnement du jeu, et enfin un
exécutable en mode fenêtré pour la livraison au client. Le diagramme de déploiement ci-
dessous résume tout ceci.
On voit ainsi qu’il faudra porter une attention toute particulière à l’API1 de giCore et des
exécutables. L’intérêt ici, est de rendre les plus indépendants possible le noyau et les
interfaces :
•si on doit modifier le noyau, ces modifications ne doivent avoir aucun impact sur le code de
l’exécutable ;
•si on modifie l’exécutable, le noyau ne doit en aucun cas avoir besoin d’être modifié.
L’API doit être parfaitement pensée, et la plus simple possible.
Marc Chevaldonné • [email protected] • IUT Informatique Clermont1 2
1 Application Programming Interface : Interface de programmation (http://fr.wikipedia.org/wiki/Interface_de_programmation)
LES CLASSES DU NOYAU
Voici un aperçu des classes du noyau pour le jeu Plus4 et leurs responsabilités et
compétences :
•l’état du jeu Plus4 est stocké à l’aide d’une classe (Board) et de deux structures (Case et
Piece) :
• Board représente la grille du jeu et est donc un tableau à deux dimensions de Cases,
•une Case représente ... une case de la grille et peut posséder ou non, une Piece.
• Board est responsable de ses Cases et est capable d’insérer ou d’enlever des Pieces.
• Rules représente les règles du jeu : il est capable de lire Board et d’en déduire quels sont
les coups (valeurs de la structure Move) autorisés. Il teste également si la partie peut
démarrer, si la partie est terminée, et met à jour les scores (instance unique de Score, à la
demande du GameManager). La recherche des coups autorisés, le test de fin de partie, la
mise à jour des scores, la recherche de lignes (...) varie en fonction des règles du jeu
(classique, partie sans fin, variante...). En conséquence, Rules est une classe abstraite qui
sera dérivée en plusieurs classes filles implémentant ces méthodes. On peut ainsi voir se
dessiner un pattern Strategy.
•Les joueurs sont représentés par des sous-filles de la classe Player. Cette classe
communique avec le GameManager pour choisir un coup (valeur de Move) et demander
l’insertion. Le choix du coup dépend du type de joueur (intelligence artificielle ou joueur
humain).
•Le GameManager est le pivot de giCore. L’instance unique du GameManager permet de
créer le jeu et de gérer la communication entre les différents éléments du jeu. Le
GameManager va par exemple :
•demander aux règles du jeu si les conditions du jeu sont réunies pour démarrer le jeu,
•démarrer le jeu,
Marc Chevaldonné • [email protected] • IUT Informatique Clermont1 3
•demander aux règles du jeu quel est le prochain joueur à jouer
•informer ce joueur que c’est son tour de jouer,
•demander aux règles du jeu si un coup demandé par un joueur est valide,
•faire l’insertion de la pièce dans la grille,
•indiquer que la partie est terminée
•...
CALENDRIER DES TP
Développement de giCoreDurant les 5 premières semaines, l’objectif sera de réaliser giCore, de tester l’ensemble de
ses classes, puis de créer une application Console permettant de jouer. Pour cela, nous
rajouterons un nouvel assemblage giConsoleTools qui contiendra des classes d’affichage
adaptées à la Console.
Durant la première semaine, nous développerons la structure de données de la grille, soit la
classe Board et les structures Case et Piece.
En deuxième et troisième semaine, les règles du jeu seront implémentées : classes Rules (et
quelques classes filles), Score et la structure Move.
Enfin, en quatrième et cinquième semaine, nous nous attaquerons au GameManager et aux
classes Player. Toutes les liaisons seront établies afin de permettre de jouer dans la version
Console du jeu.
Replay et meilleurs scores grâce à XML et des parseurs en C#Suite à cette implémentation, nous profiterons des cours sur XML pour rajouter des
«gadgets» non indispensables à notre jeu. Nous stockerons notamment le déroulement d’une
partie dans un fichier XML puis les résultats de l’ensemble des parties réalisées dans un autre
fichier XML de façon à pouvoir effectuer des replays, des sauvegardes ou afficher les meilleurs
scores. Pour cela, durant les semaines 6 et 7, nous définirons les formats de ces deux types de
Marc Chevaldonné • [email protected] • IUT Informatique Clermont1 4
fichiers. Puis pendant les semaines 8 et 9, nous réaliserons deux nouveaux assemblages
(giHighScores.dll et giGameSaver.dll) en C# qui permettront l’écriture et la lecture
de ces fichiers. Nous pourrons ainsi afficher les meilleurs scores à la fin de chaque partie,
rejouer une partie pour revoir un match serré ou admirer une technique, etc...
Affichage web des meilleurs scores grâce à XSLTEn semaine 10 et 11, nous créerons une page web dynamique à partir de feuille de
transformation XSL pour transformer notre fichier XML de meilleurs scores en page XHTML
interactive.
Interface graphique et système de plugins dynamiquesEnfin, durant les 3 dernières semaines, nous réaliserons l’interface graphique du jeu avec
gestion de la souris et affichage moderne. Nous réaliserons également un système de plugins
dynamiques pour permettre à n’importe qui de créer sa propre classe de type Player (une
intelligence artificielle) ou sa propre classe de règles du jeu, sans avoir à recompiler ou à
ouvrir VisualStudio.
Marc Chevaldonné • [email protected] • IUT Informatique Clermont1 5
TP 1Dans ce premier TP, vous allez réaliser la structure de données du jeu Plus4 en créant deux structures pour représenter les pièces du jeu et les cases de la grille, et une classe pour représenter la grille. Vous devrez ensuite créer des projets de tests de vos structures et classe en Console.
STRUCTURE DE DONNÉES
Écrivez quatre types personnalisés dans l’espace de noms giCore :
•une énumération PieceType
•une structure Piece
•une structure Case
•une classe Board.
Ajoutez les propriétés et méthodes comme proposées dans le diagramme de classes UML
incomplet de la page suivante.
Vous pourrez notamment :
•pour Piece :
‣ mettre PieceType en type imbriqué de Piece,
‣ faire en sorte que Piece soit une structure immuable (write-once),
‣ PlayerId et Type devront être des propriétés permettant d’accéder à deux
membres privés en lecture seule
‣ le 2ème constructeur initialisera le type à Normal (vous pourrez appeler l’autre constructeur pour factoriser votre code),
‣ le ToString de Piece rendra ‘r’, ‘R’, ‘b’, ‘B’ selon les valeurs de PlayerId et Type, comme dans le tableau ci-dessous
PlayerId Type ToString
0 Normal r
0 Bonus R
1 Normal b
1 Bonus B
•pour Case :
‣ faire en sorte que Case soit une structure immuable (write-once),
Marc Chevaldonné • [email protected] • IUT Informatique Clermont1 6
‣ Row, Column et Piece devront être des propriétés permettant d’accéder à trois
membres privés en lecture seule,‣ Piece est nullable,
‣ les constructeurs utiliseront une valeur par défaut pour le paramètre piece,
‣ le 2ème constructeur sera proche d’un constructeur par recopie : il recopie les propriétés Row et Column du paramètre de type Case, mais pas la propriété Piece.
Il pourra également appeler le 1er constructeur pour factoriser le code,
‣ le ToString rendra un blanc s’il n’y a pas de Piece, et le ToString de la pièce s’il
y en a une•pour Board :
‣ DEFAULT_NUMBER_OF_ROWS et DEFAULT_NUMBER_OF_COLUMNS sont des constantes,
‣ mCases est un tableau privé à deux dimensions de Case,
‣ Rows et Columns sont des propriétés calculées rendant les dimensions de mCases,
‣ le constructeur par défaut utilise les constantes pour construire le tableau de Case sans Piece,
‣ Board(Case[,]) et Board(Board) sont des constructeurs par recopie (on recopie la
grille dans les deux cas),‣ InsertPiece(byte, byte, Piece?) insert une pièce dans la case spécifiée,
‣ InsertPiece(Case, Piece?), RemovePiece(byte, byte) et RemovePiece(Case) utilisent InsertPiece(byte, byte, Piece?) pour factoriser le code. Les
méthodes Remove retire une pièce.
‣ les méthodes InsertPiece et RemovePiece seront internal et non public comme indiqué dans le diagramme.
‣ l’indexeur permettra d’accéder aux Cases de la grille en lecture seule.
‣ le ToString écrit une grille sur plusieurs lignes, comme dans l’exemple suivant,
où on voit les numéros de ligne et de colonnes, puis le contenu de chaque case : 0 1 2 3 0 r b r r 1 b b r B 2 R b b R 3 b r b r
TESTS DES STRUCTURES ET CLASSE
Testez vos structures et votre classe à l’aide de projet de type Console dans lesquels vous
appellerez les différentes méthodes de vos types pour vérifier leur bon fonctionnement.
Marc Chevaldonné • [email protected] • IUT Informatique Clermont1 7
Marc Chevaldonné • [email protected] • IUT Informatique Clermont1 8
TP 2Vous allez maintenant développer les règles du jeu Plus4. Le développement de la classe Rules et des classes qui l’entourent se déroulera sur deux semaines. Cette première semaine sur Rules permettra de prendre en main l’héritage et le polymorphisme à partir de Rules et les collections génériques et en particulier List<T>.
Note : toutes les méthodes protégées de Rules sont en réalité également internal et virtuelles.
Les classes grises appartiennent au framework .NET, les blanches ont déjà été implémentées
ou le seront prochainement, les jaunes concernent le TP2.
QUELQUES PROPRIÉTÉS DE RULES
•Les règles sont caractérisées par le nombre de pièces à aligner (4 par défaut) et le nombre
de pièces Bonus par joueur (1 par défaut), ainsi qu’un nom. Grâce à la méthode
Marc Chevaldonné • [email protected] • IUT Informatique Clermont1 9
GetNbOfBonusPiecesLeft(int playerId), on sait toujours combien de pièces Bonus il
reste en main pour le joueur playerId.
• Rules peut prendre une référence de Board à la construction. L’intérêt est double :
reprendre une partie à un état déjà avancé (sauvegarde) ; tester les règles du jeu en fonction
d’un état de la grille.
UN DÉBUT DE PLAYER...
La classe Player contient deux propriétés, mais l’identifiant doit être créé automatiquement
(0 ou 1) grâce à un compteur statique. AddPlayers permet d’ajouter des joueurs à Rules.
NextPlayer indique quel sera le prochain joueur à jouer et LastPlayer quel est le dernier
joueur à avoir joué.
LES COUPS AUTORISÉS
Un coup dans le jeu sera représenté par une valeur de la structure Move. Rules contient une
collections de coups qui peuvent être joués au prochain coup. La méthode
IsMoveAuthorized(Move move) permet de tester si move est un coup autorisé (i.e. s’il est
contenu dans la collection de coups autorisés).
GESTION DES SCORES
La classe Score permet de stocker les points des joueurs, organisés en points, sets, et matchs.
LES MÉTHODES CLÉS
• IsGameReadyToStart vérifie si les conditions initiales sont vérifiées (à vous de les
déterminer).
• IsGameOver vérifie si la partie est terminée.
• UpdateScores met à jour les scores (en particulier la propriété CurrentSet).
• UpdateAuthorizedMoves met à jour la collection de coups autorisés.
• IsThereAnAlignment teste s’il y a des alignements de pièces et combien. Pour cela, utilisez
une classe WinningAlignment représentant un alignement de pièces. Cette classe pourra
dériver de List<Case> ou contenir un membre de List<Case>.
•Enfin, OnPieceInserted met en musique les tests de Rules lorsqu’un pièce est insérée,
c’est-à-dire :Marc Chevaldonné • [email protected] • IUT Informatique Clermont1 10
‣ vérifie s’il y a un ou plusieurs alignements,
‣ ajoute les points en fonction de ces alignements (nouvel alignement et pas ancien,
une pièce bonus ou non, type de la dernière pièce insérée...),
‣ met à jour les scores,
‣ met à jour les anciens alignements comptabilisés (rappel des règles : si un
alignement a été compté lors d’un coup, il ne peut pas être recompté au coup
suivant),
‣ met à jour NextPlayer et LastPlayer,
‣ met à jour la collection de coups autorisés.
TP 3Quelques ajouts avec nos nouvelles connaissances de la semaine 3, au TP initié en semaine 2...
ENCAPSULATION DES COLLECTIONS
Encapsulez toutes les collections qui devront être accessibles en dehors de giCore, i.e. :
•la liste des coups autorisés,
•la collection de joueurs.
PROTOCOLES D’ÉGALITÉ
Réécrivez les protocoles d’égalité de :
• Case : deux Cases seront égales si elles ont les mêmes coordonnées (ligne, colonne),
• Piece : deux Pieces seront égales si elles ont le même propriétaire et le même type,
• Player : deux Players seront égaux si ils ont le même id
• WinningAlignement : deux WinningAlignements seront égaux si ils ont au moins
NbOfPiecesInAWinningAlignment pièces en commun.
FIN DE RULES
Terminez les TP 2 et 3 avec ces améliorations.
Marc Chevaldonné • [email protected] • IUT Informatique Clermont1 11
