Master InformatiqueFaculte des sciences Jean Perrin de Lens

2008-2009

Creation d’un serveur de jeu pour Pickomino :Pickomania

Mathieu Boniface

Tuteurs :M. Cardon StephaneM. Lagrue Sylvain

Me. Chetcuti-Sperandio Nathalie

Table des matieres

1 Presentation du projet 21.1 Pickomino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Pickomania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Maquette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.2 Architecture n-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.3 Securite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 Extensibilite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Choix techniques 92.1 Java Enterprise Edition 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Glassfish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.2 Java Persistence API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.3 Enterprise Java Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Google Web Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Persistance 123.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Entites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.1 User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.2 Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.3 PickominoParty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.4 Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Partie Cliente 164.1 Architecture du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.1 Modelisation de la partie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.1.2 Interfacage client/serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Partie serveur 205.1 Architecture du serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.1.1 Modelisation de la partie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.1.2 Modelisation des joueurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2 Developpement des intelligences artificielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.2.1 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.2.2 Exemple : SimpleAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6 Securite de l’application 276.1 JDBCRealm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.1.1 JAAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.1.2 Principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1

1 Presentation du projet

Le projet qui nous est confie a pour but de developper une application permettant de jouer aPickomino sur le Web. Elle doit par ailleurs permettre de collecter des informations sur le deroulementdes parties, et plus particulierement, sur les resultats des intelligences artificielles developpees face auxcomportements humains. Basee sur la plate-forme Java Enterprise Edition, l’application devra permettreune certaine extensibilite en fournissant une base qui permette de developper et de publier d’autres jeux parla suite. Elle devra aussi permettre de developper et de publier facilement des intelligences artificielles.

1.1 Pickomino

Preparation du jeu

Au depart de la partie les seize pickominos forment la brochette et sont disposes par ordre croissantface aux joueurs. Chaque pickomino donne deux informations : la premiere sous forme numerique pouvantaller de 21 a 36 donne la somme minimum des des qu’il faut conserver pour pouvoir prendre ce pickomino.La seconde, representee par le nombre de vers, sera prise en compte a la fin de la partie pour designer levainqueur. Pour debuter la partie on designe arbitrairement le joueur qui commence.

Deroulement d’un tour

Au debut de son tour, le joueur dispose de huit des. Il commence par lancer les des, puis decidede conserver une valeur parmi les des lances et garde alors tout les des ayant cette valeur. Il recommenceainsi a lancer les des qu’il n’a pas deja garde jusqu’a ce qu’il puisse prendre un pickomino ou qu’il perde sonttour. Aussi pour prendre un pickomino le joueur doit disposer d’au moins un ver parmi les des qu’il a dejaconserve. Au cours de ces lances plusieurs cas sont possibles :

Fig. 1.1 – La brochette de pickominos

2

Fig. 1.2 – Les des

– Lorsque toutes les valeurs obtenues apres un lancer sont egales a celles obtenues precedemment,le joueur perd son tour.

– La somme des des qu’il a conserve est superieur ou egale a un pickomino present dans la brochette.Il peut alors decider de prendre ce pickomino ou de relancer les des au risque de perdre son tour.

– La somme des des qu’il a conserve est strictement egale a la valeur d’un pickomino possede parun adversaire, il peut alors prendre ce pickomino et le placer au dessus de sa propre pile. Seulsles pickominos place au dessus de la pile sont prenable par les adversaires.

Lorsqu’un joueur perd son tour et qu’il possede au moins un pickomino dans sa pile, il doit replacer cepickomino dans la brochette. De plus, il retire le pickomino de plus forte valeur dans la brochette, sauf si cepickomino est celui qu’il vient de replacer.

Fin de la partie

La fin de la partie est declaree lorsqu’un joueur se saisit du dernier pickomino sur la brochette.On compte alors, pour chaque joueur, le nombre de vers sur les pickominos qu’il possede. Le joueur ayant leplus de vers est declare vainqueur. En cas d’egalite c’est le joueur qui possede le pickomino de plus grandevaleur qui est declare vainqueur.

1.2 Pickomania

1.2.1 Maquette

Afin d’attirer le public nous nous devions de fournir une interface agreable et ergonomique pourl’utilisateur. Cependant arriver a un tel resultat demande de maitriser certaines techniques, du temps et del’experience. C’est pourquoi nous avons decide de nous appuyer sur un modele XHTML/CSS deja realise.FreeCSSTemplate.org1 est un site qui propose des modeles graphique gratuits et modifiables a souhait. PourPickomania c’est le modele « exploitable » que nous avons choisi 2. En plus d’etre sobre et elegant, lapalette de couleurs utilisees correspond assez bien avec les elements du jeu qui nous ont ete fournis (des etpickominos). Apres avoir procede a quelques modifications nous sommes parvenu a ce que sera Pickomania.

1http ://www.freecsstemplates.org/css-templates/2http ://www.freecsstemplates.org/preview/exploitable

3

Dans un soucis d’ergonomie le formulaire de connexion a ete place dans l’en-tete de page et estdonc present sur toutes les pages du site. Le menu de gauche ne change pas, chaque visiteur peut decider delancer une nouvelle partie, mais s’il n’est pas identifie, il sera automatiquement redirige vers la page d’ins-cription/identification. Un lien vers une page sensee presenter les statistiques est aussi presente, cependantcette partie de Pickomania n’a pas encore ete developpee. Un message avertissant de la future arrivee decette fonctionnalite est presente a l’utilisateur s’il decide de s’y rendre.

4

Une fois identifie, il peut creer une nouvelle partie. Pour ce faire un formulaire lui est propose :

L’utilisateur peut creer une partie en ajoutant de un a cinq adversaires, il peut choisir le typed’intelligence pour chaque adversaire et lui attribuer un nom. Ensuite, l’utilisateur n’a qu’a cliquer sur lebouton « commencer la partie » pour arriver sur la page de jeu :

5

Chaque cadre au nord presente les informations d’un adversaire. On y montre le sommet de sa pilede pickominos ainsi que le nombre de pickominos qu’elle contient. Juste en dessous nous avons la brochette.A l’est deux cadres representent, de haut en bas, les des gardes et les des lances. Enfin le cadre au sudpresente les informations de l’utilisateur en temps que joueur. Ce cadre est plus large car il est le seul amontrer tout les pickominos pris au cours de la partie. En effet, le joueur « humain » ne doit voir que lesommet de la pile de ses adversaires. Le joueur actif est identifie par un cadre plus epais et dont les traitssont continus.

1.2.2 Architecture n-tiers

Comme toute application qui repose sur la plate-forme JEE, Pickomania est decoupee en couchessuccessives (ou tiers en anglais). Sun Micro Systems introduit dans son tutoriel trois grandes couches au seindes applications JEE :

6

L’EIS Tier pour Enterprise Informations system. Il constitue le systeme d’information, travail souventdelegue a une base de donnees relationnel. Le developpeur n’a donc dans la plupart des cas pas a lagerer.

le Business Tier represente quant a lui la couche metier de l’application. Elle s’execute au sein d’unserveur d’applications et permet de deleguer a un conteneur d’EJB3 des traitements fastidieux pour ledeveloppeur comme la gestion des threads pour les traitements asynchrones (envoie de mail, traitementslourds) ou la gestion des transactions pour les acces en base de donnees. Outre ces deux avantages, ellepermet dans une moindre mesure de «factoriser» le code entre differents types de clients (client Swing,client Web, ...).

Le Web Tier constitue la partie presentation des donnees.

1.2.3 Securite

La securite est un point essentiel de toute application destinee a un large public. Au sein dePickomania cet aspect n’a bien sur pas ete neglige, ainsi certaines actions comme la creation d’une partie nesont pas rendu possible pour un utilisateur non-identifie. De plus, Pickomania a ete concu de tel maniere aempecher les joueurs de tricher. En effet si un utilisateur triche, il fausse les donnees statistiques recoltees,qui n’auraient alors plus aucune valeur.

Dans une application Web un probleme apparaıt des lors qu’un utilisateur decide de rafraıchirla page ou qu’il ferme et redemarre son navigateur. En effet, cote serveur les informations concernant lapartie en cours sont toujours presentes. Un moyen facile de resoudre le probleme serait d’abandonner lapartie en cours et d’en lancer une nouvelle. Cependant Pickomania ne reagit pas de cette maniere. Une foisl’application cliente chargee on commence d’abord par verifier si une partie existe cote serveur, auquel cason la charge. Dans le cas contraire on affiche simplement le formulaire de creation d’une nouvelle partie.

3Enterprise Java Beans

7

1.3 Extensibilite

Le projet tel qu’il avait ete presente dans le sujet introduisait la notion de modularite. Il s’agissaitdonc de developper des composants generiques afin de pouvoir developper par la suite d’autres applicationsbasees sur ces composant, cependant au sein de JEE5, la modularite sur la partie web de l’application estdifficile a mettre en place pour ne pas dire quasi impossible. Nous avons donc decide de modifier cettemodularite en extensibilite, c’est a dire que nous fournissons en plus de Pickomania un autre projet quipourrait servir de base au developpement d’autres jeux avec tout ce qui n’est pas directement en rapportavec Pickomino :

– le systeme d’identification.– le systeme d’inscription.– la gestion de la securite.– la navigation entre les pages (regles, nouvelle partie, index)

8

2 Choix techniques

2.1 Java Enterprise Edition 5

2.1.1 Glassfish

JEE requiert l’utilisation d’un serveur d’application pour le deploiement des applications. Aussi ilexiste beaucoup de serveurs implementant les differentes specifications. Glassfish en fait partie mais possedeune particularite : il est la reference. C’est donc naturellement que nous avons choisi ce serveur d’applicationpour une premiere prise de contact avec la plate-forme. Glassfish dispose d’une interface d’administrationclaire, son code est ouvert, son utilisation gratuite, et la documentation est bien suffisante pour une utilisationminimale.

2.1.2 Java Persistence API

Depuis les debuts de J2EE, les modeles de persistance de donnees n’ont cesse d’evoluer. Aujourd’huila plate-forme propose JPA, reelle cassure par rapport au modele qui la precede : les entity beans 2.1, leurarchitecture imposait beaucoup de contraintes et une certaine redondance lors du developpement. JPA,quant a lui permet de s’abstraire des traitements qui sont effectues directement en base de donnees. Ledeveloppement s’en trouve grandement simplifie, ce qui implique un gain de productivite non negligeable.

2.1.3 Enterprise Java Beans

Enterprise Java Beans (EJB) est une specification qui introduite une API et des regles de developpement.Cette specification delegue a un conteneur au sein du serveur d’application la gestion des threads, ainsi quela gestion des transactions pour la base de donnees. Il existe trois types d’EJB :

– Les Stateless Session Beans sont des objets sans etats, ils peuvent servir a effectuer destraitements mais ne conservent pas de donnees, ils sont souvent utilises pour gerer les objetsstockes en base de donnees.

– Les Stateful Session Beans au contraire disposent d’une duree de vie au sein de leur conteneuret chaque client dispose de sa propre instance. Attention toute fois a la notion de client : sil’EJB est l’attribut d’un servlet, c’est le servlet lui-meme qui devient client de l’EJB, et puisqu’iln’existe qu’une seul instance de ce servlet sur la serveur d’application, cet EJB sera communa tout les clients Web. En revanche si le client est un client swing distant il existera bien uneinstance de cet EJB pour chaque client distant.

– Les Message Driven Beans permettent d’effectuer des traitements asynchrones, il sont generalementutilises pour effectuer des traitements lourds comme l’envoie de mail ou l’impression de docu-ments.

9

Pour Pickomania nous n’utilisons que Stateless Session Beans qui nous permettent de persister des objetsdans la base de donnees, ou d’acceder a ces memes objets.

2.2 Google Web Toolkit

Presentation

Google Web Toolkit (GWT) est un framework open source edite par Google. GWT part d’unconstat simple : de nos jours developper une application internet riche (RIA) a base de JavaScript est uneoperation fastidieuse pour plusieurs raisons :

– Javascript etant ne en pleine guerre des navigateurs (Netscape vs Internet Explorer), des problemesde compatibilite subsistent.

– Comme tout langage, la maıtrise du JavaScript requiert un apprentissage.– Il est assez difficile de deboguer une application ecrite en JavaScript.– Des problemes de fuites memoires apparaissent et peuvent devenir inquietants au fur et a mesure

que l’application grossit si le developpeur n’y prete pas attention des le depart.Autant de facteurs qui font qu’un developpeur passe plus de temps a resoudre des problemes lies au langage,qu’a developper son application.

GWT propose une approche differente. Le developpeur ecrit son code en Java. Il profite ainsides avantages du langage (IDE, Stack Trace, popularite du langage, ...), ce qui lui permet de gagner enproductivite. Ce code est ensuite retranscrit en JavaScript. De plus la programmation se fait a la manieredu developpement d’une application SWING, fini donc la generation du HTML en JavaScript.

Pour ce faire, GWT apporte plusieurs outils de developpement :– Une API riche et dynamisee par une communaute OpenSource grandissante.– L’apparition d’API externes au projet qui decuplent les possibilites de GWT en matiere de

conception d’interfaces hommes-machines (GXT 1, SmartGWT2)– Un compilateur croise (cross-compiler en anglais) qui permet de compiler du code Java en JavaS-

cript de facon a ce qu’il soit optimise et compatible pour la plus grande partie des navigateurs.– Un mode d’execution (appele hosted mode) qui interprete le code source Java (pas le bytecode)

plutot que le Javascript, ce qui permet de profiter des traces d’execution de Java, d’eviter deperdre du temps a la compilation et de n’avoir qu’a sauvegarder le fichier source pour profiterdes modifications visuelles.

– un modele de communication client serveur base sur RPC (Remote Procedure Call) qui permetde developper entierement une application JEE en Java juste en declarant les interfaces

Restrictions

Bien que sur le papier GWT apparaisse comme la technologie magique ideale, il existe tout dememe quelques limites. Parmi celles-ci on pourrait citer :

– La lenteur de l’etape de compilation Java vers JavaScript.– La difficile integration avec d’autres technologies cote serveur (PHP par exemple).– L’emulation de l’API Java Se qui est loin d’etre complete3.

Enfin un dernier point, il ne faut pas oublier qu’au final, le code interprete est en JavaScript ! En consequenceles mecanismes d’introspection et de reflexivite propres a Java sont a proscrire, au meme titre que les

1http ://extjs.com/explorer/2http ://www.smartclient.com/smartgwt/showcase/3http ://code.google.com/intl/fr/webtoolkit/doc/1.6/RefJreEmulation.html

10

operations d’entrees/sorties. Aussi le modele de communication client/serveur introduit est asynchrone cequi implique parfois quelques difficultes dans la conception de l’application.

11

3 Persistance

3.1 Architecture

3.2 Entites

3.2.1 User

L’entite User represente l’utilisateur au sein de l’application. Ainsi chaque utilisateur dispose d’unidentifiant de connexion userLogin , ici l’annotation @Id indique que cet attribut est la cle primaire del’entite. Il dispose egalement d’un mot de passe (password) et d’une adresse mail (mailAddress). Chaqueutilisateur possede egalement une liste de parties qu’il a acheve. L’attribut groups est une liste qui contientles reference vers les objets Group aux quels appartient l’utilisateur. Ce champs est utilise par JDBCRealmpour la partie securite de l’application.

Voici un extrait du script qui est genere pour la creation de la base de donnees au deploiement del’application. On y voit que la table t user qui represente l’entite User en base de donnees ne contient pasles groupes puisque ceux-ci sont injectes dans la classe lors de l’appel aux differentes « getters » de l’objet.

CREATE TABLE t_user {

userLogin VARCHAR (255) PRIMARY KEY ,

password VARCHAR (255) ,

mailAddress VARCHAR (255)

};

CREATE TABLE Party {

12

owner_userLogin VARCHAR (255)

FOREIGN KEY REFERENCES t_user(userLogin),

-- Autres champs de la table party

}

3.2.2 Group

Comme indique precedemment chaque utilisateur est affilie a un groupe. Pour l’instant un seulgroupe est defini mais par la suite si une partie administration venait se greffer a l’application il serait doncassez simple de gerer l’acces a certaines ressources. En effet, il suffirait d’inscrire les utilisateurs privilegiesdans le groupe.

On pourrait croire que JDBCRealm est la solution parfaite pour gerer la securite, cependant cesysteme au coeur du serveur Glassfish est assez peu flexible. En fait, il ne permet pas de definir les requetes quisont effectuees en base de donnees pour recuperer les groupes et mot de passes des utilisateurs (contrairementa Tomcat par exemple). Voici la trace laissee par JDBCRealm lors de la connexion d’un utilisateur :

SELECT password FROM t_user WHERE userlogin = $1

SELECT groupname FROM t_group WHERE userlogin = $1

On voit donc que JDBCRealm oblige le developpeur a inserer l’identifiant de l’utilisateur et lenom du groupe auquel il est associe dans la meme table (pas de jointure possible). De plus comme son noml’indique JDBCRealm, n’utilise pas JPA mais Java DataBase Connectivity. Il faut donc adapter nos entitesau systeme. Afin de satifaire ces contraintes nous avons du produire une entite qui lors du deploiement del’application puisse produire le schema relationnel donne par JDBCRealm.

L’entite Group contient donc une cle primaire composee du nom du groupe et du nom de l’utili-sateur. De plus le champs userLogin est une cle etrangere referencant la cle primaire de la table t user. JPAoblige a creer une classe pour englober les attributs des cles primaires composees et de declarer cette cle al’aide de l’annotation @EmbeddedId. Finalement la redondance du champs userLogin dans l’entite Group etdans la classe IdGroup est obligatoire pour definir la cle etrangere...

Voici le script SQL genere lors du deploiement :

13

CREATE TABLE t_group (

groupName VARCHAR (255) not null ,

userLogin VARCHAR (255)

FOREIGN KEY REFERENCES t_user(userLogin),

PRIMARY KEY (groupName , userlogin)

);

3.2.3 PickominoParty

L’entite PickominoParty est la representation d’un partie en base. Elle dispose d’une cle primaireauto generee (id). La date de la partie startedDate est conservee. L’utilisateur « proprietaire » (owner) estcelui qui a demarre la partie et peut etre optionnel ; en effet si un utilisateur est supprime de la base on gardeses statistiques. L’attribut players reference la liste des joueurs ayant participe a cette partie ; mappedBysignifie que nous utilisons un systeme de cle etrangere et non une table de jointure sa valeur correspond aunom de l’attibut proprietaire de la relation dans l’entite Player. CascadeType.PERSIST singifie que lorsquela partie sera persistee en base de donees on persistera automatiquement ses joueurs.

3.2.4 Player

L’entite Player represente un joueur au sein d’une partie. C’est l’entite dans laquelle sera stockeeles statistiques du joueur au cours de la partie. Un joueur pouvant etre un humain ou une intelligence, nousavons choisi de representer cette difference avec l’attribut isHuman. Concretement lorsque cet attribut ala valeur true c’est le champs humanPlayer qui est considere, dans le cas contraire on considere l’attributaiType

14

L’attribut Id comme l’indique l’annotation qui le precede est auto-genere lors de la persistencede cette entite et fait office de cle primaire grace a l’annotation @Id. L’attribut aiType represente le typed’intelligence artificielle, sa valeur correspond au champs name de l’annotation @AI definie au chapitre 5.2.1. playerName represente le nom du joueur. Plusieurs intelligences du meme type pouvant etre representeesau sein d’une meme partie il a semble interessant pour l’utilisateur de pouvoir les differencier par autre chosequ’un nombre. humanPlayer reference l’utilisateur qui represente cette entite.

Viennent ensuite les champs qui sont mis a jour en cours de jeu et qui donnent des informationssur le comportements et les resultats des joueurs.

numLoosedPickomino represente le nombre total de pickomino perdus au cours de la partie. Un pickominoest considere comme perdu lorsqu’il a soit ete pris par un autre joueur, soit lorsque le joueur a perduson tour suite a un mauvais lancer de des.

numLoosedPickominoThatReducesTheSkewer est le nombre de pickomino perdu ayant provoque lareduction de la brochette.

numMissedRound est le nombre de tour que le joueur a perdu, notez que la perte d’un tour ne reduit pasforcement la brochette.

numStolenPickominoByOpponent est le nombre de Pickominos pris par les opposants au cours de lapartie.

numStolenPickominoFromOpponent est le nombre de pickomino qu’un joueur a reussi a prendre a sesadversaires.

partyBiggerPickomino est le pickomino de plus grande valeur pris au cours de la partie. Si le joueur aperdu ce pickomino le champs n’est pas remis a jour.

stackMaxSize est la taille maximale atteinte par la pile de pickomino au cours de la partie.

stackSize represente la taille de la pile de pickominos en fin de partie.

sumWorms represente le nombre de vers que le joueur possede en fin de partie.

15

4 Partie Cliente

4.1 Architecture du client

4.1.1 Modelisation de la partie

Dans un premier temps nous sommes partis du principe que certains composants ne seraientinstancies qu’une seule fois au cours de la vie de l’application. De plus ces composants sont peu dependantsdu reste de l’application. C’est pourquoi nous les avons declare en temps que « singleton ». Parmi cescomposant on trouve :

– la classe KeptDicesPanel est le conteneur qui accueille les des gardes par le joueur.– la classe RolledDicesPanel est en charge des lances de des, ainsi que la presentation de ces

derniers.– la classe Skewer represente la brochette de pickomino.Ensuite est venue la gestion des actions. Pour les intelligences, il a ete decide de ne pas montrer

les resultats des lances de des ainsi que les choix de des. Ceci pour deux raisons : d’une part l’utilisateuraurait pu etre gene par la lenteur du jeu, d’autre part cela aurait multiplie les echanges entre le serveur et leclient, chose qui n’etait pas souhaitable. S’agissant des actions de l’utilisateur nous avons ete un peu surprisau depart par le modele de communication asynchrone entre le client et le serveur. En effet il est impossiblede prevoir un controleur qui puisse donner la main a chaque joueur de cette maniere :

public class Controller {

public void startParty () {

while (! party.isFinished ()) {

player.play ();

16

player = nextPlayer ();

}

}

}

Pour contourner le probleme nous avons fait en sorte que chaque joueur de la partie controle l’execution deson tour. Chaque joueur connaıt donc le joueur suivant, et des qu’il a fini son tour il demande au joueursuivant de demarrer son tour :

public class Player {

public void startRound () {

// appels asynchrones

}

public void finalizeRound () {

// traitements de fin du tour

nextPlayer.startRound ();

}

}

4.1.2 Interfacage client/serveur

GWT permet de definir des interfaces de communication client/serveur en Java. Ces interface souspickomania on ete pense de telle maniere a eviter au maximum les echanges de donnees entre le client et leserveur. Par exemple quand un joueur decide de prendre un pickomino nous pourrions renvoyer l’etat de labrochette ainsi que l’etat de chacune des piles des adversaires, cela permettrait de limiter la logique metiercote client en n’implementant pas les regles de jeu. Pickomania n’est pas concue de cette maniere, les reglesde jeu sont donc implementees chez le client et sur le serveur. Bien sur le travail a ete plus long et les risquesde produire des bogs lors du developpement plus grands.

Voici l’interface de communication tel qu’elle est declaree sur le serveur :

– getAiList() retourne la liste des IA disponible sur le serveur. cette methode est utilisee pourpeupler le formulaire de creation de nouvelle partie.

– rollDices() permet de lancer les des, cette methode est appelee lorsque l’utilisateur clique surle bouton lancer.

17

– keepDice(int) permet de definir le de lance. cette methode ne retourne rien. Si le client par-vient a envoyer une valeur fausse (hacking) le client risque de se desynchroniser puisque cesinformations ne seront pas prises en compte par le serveur. Le joueur n’aura qu’a rafraıchir lapage pour se resynchroniser avec le serveur afin de continuer la partie.

– takePickomino(int) et takePickominoFromOpponent(int) permettent de signaler au ser-veur que le joueur a choisi un pickomino parmi la brochette ou parmi un de ses opposants.

– getCurrentParty() Retourne la partie courante si elle existe, dans le cas contraire null estretourne.

– createParty(PartyDTO) demande la creation d’un partie. Bien sur, un utilisateur mal in-tentionne pourrait theoriquement appeler cette methode de maniere detournee, mais elle verifiequ’il n’existe pas deja de partie en cours et si c’est le cas elle renvoie cette meme partie. Aussion pourrait tenter d’injecter dans l’argument passe en parametre de fausse informations, commeun nombre de joueurs trop grand ou un type d’IA qui n’existe pas sur le serveur, c’est pourquoile serveur renvoie une autre instance de PartyDTO qui contient les donnees filtrees.

–

Data Transfert Objects

Dans notre cas, nous utilisons ce pattern pour plusieurs raisons : d’une part GWT impose que lesobjet qui navigue entre le client et le serveur soient « Serializable ». D’autre part il vaut mieux transferer unobjet qui agrege des types definis par le langage plutot qu’un graphe complet d’objets. Enfin, afin d’affaiblirle couplage, le client ne doit pas connaıtre comment les structures de donnees sont definies sur le serveur.

Pour illustrer le principe prenons l’exemple de la partie :

Voici le diagramme simplifie des classes d’une partie cote serveur :

Voici le diagramme simplifie des classes d’une partie cote client :

Enfin le diagramme des objets representant une partie qui transite entre le serveur et le client :

18

19

5 Partie serveur

5.1 Architecture du serveur

5.1.1 Modelisation de la partie

Ce schema represente l’architecture relative a l’execution d’une partie. Il traite des relations entreles differentes classe pour des traitements allant de la creation jusqu’a l’enregistrement en base de donneeslorsque cette partie est terminee.

Lorsqu’une partie est creee, elle est stocke dans la session du client, ainsi chaque client dispose deses propres donnees, ce qui est somme toutes assez logique pour une application Web.

L’etat d’une partie n’est pas mis a jour en base de donnees au fur et a mesure des requetes recuespar les clients. En fait ce traitement serait d’une part inutile : comment attribuer un quelconque credit auxstatistiques d’une partie qui n’est pas terminee ? D’autre part il serait un facteur de « montee en charge »

20

du serveur, element qui n’est bien sur pas a negliger.

La servlet GameManagerServiceImpl constitue le point d’entree pour toutes les requetes enprovenance des clients. Par ailleurs, il n’existe qu’une instance de cette servlet sur le serveur d’applica-tions pour tous les clients. Cette servlet s’appuie sur l’objet GameController pour traiter ces requetes. Cecontroleur existe pour chaque client des lors qu’il effectue le chargement de l’application JavaScript sur sonnavigateur. Lorsque qu’un client demande a creer une partie, une nouvelle instance de PartyBuilder estcreee. Cette classe permet de decharger la classe Party de code inutile a son execution. En effet Pickomi-noParty est une entite donc elle ne contient pas de code metier, elle permet juste de stocker les informationsen base de donnees. Ainsi la classe Party se charge des traitements en cours de partie. Ce Builder est utilisea deux moments clefs :

– Lors de la creation de la partie c’est lui qui ajoutera les joueurs aux objets Party et Pickomi-noParty

– Lorsque que l’objet Party detecte la fin de la partie, il previent le controleur, il Party est alorsretire de la session et l’instance de PickominoParty est sauvee en base. C’est ce Builder quiest charge de l’operation de sauvegarde puisqu’il est le seul a connaıtre la reference vers l’objetPickominoParty.

La classe PickominoSkewer represente la brochette de pickominos. Elle fournit les services de gestion de labrochette (retirer, replacer, verifier la disponibilite, ...) a la classe Party. Quant a la classe DicesManager,elle fournit les services associes aux des (lancer, garder, calculer la somme des des gardes ...).

5.1.2 Modelisation des joueurs

L’entite Player est la classe qui sera persistee en base de donnees. Cette classe ne contient pas laliste des pickominos qu’un joueur possede, aussi il n’etait pas logique d’integrer un quelconque code metierdans cette classe. Pourtant, quand un joueur se saisit d’un pickomino, il faut bien traiter cette information.C’est donc ce qui a motive la mise en place du design pattern Adaptateur par l’intermediaire de la classePlayerAdapter et de l’interface PlayerInterface. De cette maniere, lorsque la partie valide le choix d’unpickomino par un joueur elle l’indique a l’objet adaptateur afin qu’il puisse mettre a jour les valeurs desattributs de l’objet Player et ajouter le pickomino dans l’objet PickominoStack qu’il agrege.

Lorsque c’est au tour d’une intelligence de jouer, l’objet Party dispose d’une liste de Decision-Maker qui sont les objets « preneurs de decisions ». Ceux-ci ne connaissent pas la partie en tant que Partymais en tant que PartyFacade, cela permet d’une part d’eviter une redondance cyclique et d’autre part delimiter l’acces a certaines methode de la classe Party qui n’aurait aucun sens dans le cadre de la prise dedecision.

21

5.2 Developpement des intelligences artificielles

Le developpement des intelligences artificielles est un point sensible de l’application. En effet, cetteetape de production sera laisse a des developpeur qui n’ont pas forcement connaissance de toute la structurede l’application, il leur faut donc un cadre simple et efficace qui leur permette de developper facilement.

5.2.1 API

Facade

Le patron de conception Facade permet de cacher la complexite du systeme sous-jacent. En effet,la complexite de l’architecture de notre application nous obligeait de produire une API simple afin que ledeveloppeur d’IA ne se perde pas dans les meandres des couches successives de Pickomania. De notre analyseil est donc ressorti une interface qui fournit quelques services qui nous sont parus essentiels pour certains,utiles pour d’autres.

Lorsque la methode play() d’une IA est appele celle-ci doit effectuer les operations dans un certainordre, d’abord elle lance les des, puis decide de garder la valeur d’un de et enfin choisi un pickomino si c’estpossible. autant d’operation qui sont essentielles au bon fonctionnement de l’application. Ces operation sontdonc regroupes au sein de la facade :

rollDices() permet de lancer les des, et retourne la liste des resultats.

takePickomino(Pickomino) permet de prendre un Pickomino.

keepDice(Dice) permet de choisir un des parmi les des lances.

Ensuite viennent les methodes de plus haut niveau qui facilite le developpement des IA. En faitces operations pourraient etre recodees par ces dernieres mais cela rendrait le travail du developpeur plusdifficile.

getChoosableDices() peut etre invoquee juste apres avoir lance les des via la methode rollDices. Elleretourne donc un ensemble de des dont la valeur n’a pas deja ete choisi auparavant.

isChoosable(Pickomino) renvoie vrai si le pickomino passe en parametre est prenable, faux sinon.

getRolledDices() renvoie la liste des des lances au prealable.

22

getChoosablePickominos() renvoie la liste des pickominos qui sont prenables en fonction de la sommedes des gardes.

getOpponents() renvoie la liste des adversaires, permettant d’avoir un acces direct a leurs informations.

getKeptDicesSum() renvoie la valeur courante de la somme des des gardes.

getMe() renvoie un objet de type PlayerInterface qui permet d’obtenir les informations sur le joueurcourant.

PlayerInterface

Comme chaque partie se joue au moins a deux joueurs, tous possede au moins un adversaire. Ainsiil est primordiale de connaıtre a n’importe quel instant de la partie les differentes informations sur chacun.

La encore il s’agit de simplifier l’acces au donnees, mais aussi de cacher les traitements effectuesdans la classe qui realise cette interface.

possesPickomino() permet de savoir si le joueur possede au moins un pickomino.

getFirstOnStack() renvoie le pickomino au dessus de la pile.

Annotation et Interface

L’ensemble des classe representant les IA sont decouvertes par introspection Pour developper etpublier une intelligence, il faut que :

– la classe realise l’interface DecisionMaker.

– la classe soit annotee avec l’annotation @AI

23

Le code de l’annotation presente deux attributs :

name correspond au nom de l’intelligence tel qu’il sera vu dans la partie cliente de l’application

scope permet de definir l’etendue de la classe, si cette attribut prend la valeur AIScope.PARTY,alors chaque client disposera de sa propre instance. En revanche s’il prend la valeur Ai-Scope.APPLICATION, il n’existera qu’une seule instance de cette intelligence pourl’ensemble des clients.

5.2.2 Exemple : SimpleAI

SimpleAI lance les des puis selectionne le de ayant la plus grande valeur. Puis des qu’un ou plusieurspickominos sont disponibles elle se saisit du pickomino ayant la plus grande valeur.

Pour implementer cette intelligence nous allons utiliser deux classes. La premiere sera une classeabstraite chargee d’effectuer les operations « generiques » :

public abstract class GenericAI implements DecisionMaker {

public abstract Dice chooseDice(PartyFacade party ,

List <Dice > rolledDices ,

List <Dice > choosableDices );

public abstract Pickomino choosePickomino(PartyFacade party ,

List <Pickomino > choosablePickomino );

@Override

public void play(PartyFacade party) {

List <Dice > rolledDices = party.rollDices ();

List <Dice > choosableDices = party.getChoosableDices ();

List <Pickomino > choosablePickominos;

while (choosableDices.size() > 0) {

Dice choosenDice =

chooseDice(party , rolledDices , choosableDices );

party.keepDice(choosenDice );

choosablePickominos = party.getChoosablePickominos ();

if (choosablePickominos.size() > 0) {

Pickomino choosenPickomino =

choosePickomino(party , choosablePickominos );

if (choosenPickomino != null) {

party.takePickomino(choosenPickomino );

break;

}

}

rolledDices = party.rollDices ();

24

choosableDices = party.getChoosableDices ();

}

}

}

Ici la methode play se charge de lancer les des et de demander a la sous-classe de choisir un de parmi lesdes choisissables par l’appel a la methode chooseDice. Lorsque qu’un pickomino est disponible, elle invoquealors la methode choosePickomino de la sous-classe.

Maintenant il nous suffit de creer une classe qui herite de GenericAI et qui realise ses methodesabstraites.

25

@AI(name="Simple AI", scope=AIScope.APPLICATION)

public class SimpleAI extends GenericAI implements DecisionMaker {

@Override

public Dice chooseDice(PartyFacade party ,

List <Dice > rolledDices ,

List <Dice > choosableDices) {

Dice choosenDice = Dice.ONE;

for (Dice choosableDice : choosableDices) {

if (choosenDice.getId () < choosableDice.getId ()) {

choosenDice = choosableDice;

}

}

return choosenDice;

}

@Override

public Pickomino choosePickomino(PartyFacade party ,

List <Pickomino > choosablePickomino) {

Pickomino pickominoMaxValue = choosablePickomino.get (0);

for (int i = 1 ; i < choosablePickomino.size() ; i++) {

if (pickominoMaxValue.getValue () < choosablePickomino.get(i). getValue ()) {

pickominoMaxValue = choosablePickomino.get(i);

}

}

return pickominoMaxValue;

}

}

26

6 Securite de l’application

6.1 JDBCRealm

JDBCRealm qui est une « sur-couche » de JAAS est un systeme qui permet d’authentifier les utili-sateurs et de les reconnaitre comme faisant partie d’un groupe en allant chercher les informations directementdans la base de donnees.

6.1.1 JAAS

Java Authentication and Authorization Service ou JAAS (prononcez «jazz») a ete integre aJavaSe depuis la version 1.4. C’est la specification de reference de Java pour la gestion de la securite. JAASest utilise dans deux optiques :

– Authentifier les utilisateurs, afin de determiner qui execute le code ou demande les ressourcesindependamment du fait qu’un utilisateur soit derriere un client Swing, une applet, un servlet,un bean...

– Autoriser certains utilisateurs a executer certaines parties de l’application ou demander cer-taines ressources.

JAAS introduit les roles au sein des applications. Par exemple, dans un Bean il est possible de n’autoriserqu’un ensemble de roles a executer une methode juste en la faisant preceder de l’annotation @RoleAllowed(”role-name”)

6.1.2 Principe de fonctionnement

JDBCRealm associe des utilisateurs a des groupes, ensuite c’est dans les descripteurs de deploiementque la relation entre un utilisateur ou un groupe et un role est definie. Sous Glassfish, ce « mapping » se faitdans les fichier sun-*.xml. Pour la partie web (archive .war) il s’agit du fichier sun-web.xml, pour les EJBs lefichier sun-ejb-jar.xml et pour une application d’entreprise (archive .ear) c’est le fichier sun-application.xml.

Exemples de configurations :

<sun -web -app>

<security -role -mapping >

<role -name>AdminRole </role -name>

<group -name>AdminGroup </group -name>

</security -role -mapping >

</sun -web -app>

Ici on associe le groupe AdminGroup au role AdminRole

<sun -web -app>

27

<security -role -mapping >

<role -name>AdminRole </role -name>

<principal -name>AdminUser </principal -name>

</security -role -mapping >

</sun -web -app>

Cette configuration permet d’associer le role AdminRole a l’utilisateur ayant pour identifiant AdminUser

Ensuite il faut definir les ressources protegees. Dans notre cas, l’operation est faite dans le fichierweb.xml puisque notre application n’a pas de contrainte de securite a d’autres niveaux.

<security -constraint >

<web -resource -collection >

<web -resource -name>

Secured Pages Area

</web -resource -name>

<url -pattern >/protected /*</url -pattern >

<http -method >POST</http -method >

<http -method >GET</http -method >

</web -resource -collection >

<web -resource -collection >

<web -resource -name>

Secured JS and Servlet Area

</web -resource -name>

<url -pattern >/PickominoJS /*</url -pattern >

<http -method >POST</http -method >

<http -method >GET</http -method >

</web -resource -collection >

<auth -constraint >

<role -name>PickomaniaPlayer </role -name>

</auth -constraint >

<user -data -constraint >

<description >SSL not required </description >

<transport -guarantee >NONE</transport -guarantee >

</user -data -constraint >

</security -constraint >

Ces elements de configuration nous permettent de definir le contenu des repertoires /pickominoJS/ et /pro-tected/ comme interdit aux methodes POST et GET pour les utilisateurs n’etant pas lies au role Pickoma-niaPlayer. On indique aussi que le transport ne se fait pas a travers https. De cette maniere, un utilisateurn’etant pas connecte ne peut pas recuperer la moindre page JSP ou image dans ce repertoire ; mieux encore,il ne peut pas effectuer d’appel sur les servlets mappees derriere ces URL !

28