Déploiement du Machiabot à l'um2

Transcription

1 Déploiement du Machiabot à l'um2 Projet tutoré M1 IC Parcours CCI Encadré par : Eric BOURREAU et Pierre POMPIDOR Réalisé par : Gaël GONZALEZ Yvan SERIEYE Avec la participation de : Guillaume Tisserant Mai 2011

2 2 Table des matières Partie 1 : Rappels et présentation du projet Introduction Objectifs Principaux résultats... 5 Partie 2 : Le modèle MVC et son implémentation pour notre projet Présentation J2EE, TomCat, modèle MVC et le rôle de web.xml Notre implémentation : servlet Jouer.java, les modèles (Gestionnaire.java, Machiabot, Pierres) et vue jeu.jsp Partie 3 : Le modèle fondamental : la classe Machiabot.java Les Threads et le lancement du process de communication avec Machiabot La classe Machiabot.java La méthode jouer(string coup)...21 Partie 4 : Les sessions Rôle des SESSIONS: Les attributs de session Partie 5 : L'interface WEB La base en HTML/CSS L'amélioration avec Javascript Un nouveau modèle : algorithmes de retrait de Pierres Les dernières touches avec Ajax...31 Partie 6 : Principaux problèmes rencontrés Les erreurs Java Le cas du serveur Les améliorations à apporter...37 Conclusion Annexes Annexe 1 : la conférence à Paris...39 Annexe 2 : le code... 40

3 Partie 1 : Rappels et présentation du projet 3 Partie 1 : Rappels et présentation du projet 1.1 Introduction Au cours du dernier semestre, nous avions réalisé une étude préalable pour mettre en place une application WEB servant à utiliser un programme installé sur un serveur à l'université. Le programme en question est le Machiabot : une intelligence artificielle qui permet de joueur au jeu de GO contre une machine ; ce programme ayant été développé l'année précédente par des étudiants du Master IFPRU. Au cours de ce semestre notre projet a été très intéressant mais aussi difficile à mettre en place car il concernait de nombreuses personnes: 2 enseignants chercheurs encadrant les différents projets (E. Bourreau et P. Pompidor); un étudiant en M2 IFPRU (G. Tisserant créateur du Machiabot actuellement en stage de recherche au LIRMM pour améliorer le programme); 3 étudiants en M1 IFPRU (initialement chargés d'aider G. Tisserant et de développer des modules complémentaires pour ajouter des fonctionnalités au bot et dont nous n'avons plus de nouvelles depuis quelques mois); ainsi que nous: 2 étudiants en M1 IC (chargés de l'application WEB). (plus l'administrateur réseau de l'université A. Weisseldinger quand il était disponible pour la mise en place du serveur de projet) 1.2 Objectifs Les objectifs n'ont pas put être défini clairement à l'avance car ils dépendaient de plusieurs paramètres: les difficultés et ralentissements que nous rencontrions, les besoins de Guillaume Tisserant, la disponibilité du serveur. Mais malgré tout nous avions quelques pistes dès le départ: il fallait faire un site pour jouer en ligne avec le Machiabot qui serait hébergé sur un serveur de projet à l'université et si possible intégrer au bot un aspect didactique pour aider les nouveaux joueurs. A la fin du dernier semestre nous pensions coder en C++ pour nous adapter au code du Machiabot mais nous avons changé d'avis car on avait trop peu de temps pour apprendre un nouveau langage et le maitriser. De même nous avons abandonné l'idée des sockets car nous avons trouvé une méthode plus adaptée à nos besoins et à nos connaissance: le pattern MVC en Java JEE, qui utilise le langage JAVA que nous utilisons depuis quelques mois et que nous commençons à maîtriser. Ce pattern MVC correspondait à ce que l'on cherchait car il peut prendre en compte la communication avec un programme (avec une classe Java et des Threads) et la création de pages en HTML qui peuvent servir d'ihm pour envoyer des informations au programme.

4 Partie 1 : Rappels et présentation du projet 1.3 Principaux résultats Voici un aperçu de ce que nous avons obtenu : 4

5 Partie 1 : Rappels et présentation du projet 5 Après 4 mois de travail nous avons: Un site qui permet de jouer contre le Machiabot, cela comprends: de la programmation en Java : générer un goban sous forme de tableau et le mettre à jour avec Java JEE et les servlets lancer le programme et communiquer avec lui à l'aide de Threads vérification chaque coup donné pour éviter qu'un utilisateur malveillant entre un coup impossible directement dans l'url capturer les erreurs pouvant se produire et afficher une page d'erreur propre (on évite les pages automatiques du genre ERREUR ) gérer les cas d'abandon ou de passage de tour visualiser la partie en cours s'il y en a une (sans pouvoir cliquer sur le goban) avec différenciation des utilisateurs grâce aux Sessions affichage de l'état final du goban quand la partie est finie bloquer les liens quand on vient de jouer (pour ne pas renvoyer un deuxième coup au bot quand il réfléchit) gérer la capture des pierres (calcul de libertés) de l'utilisation des technologies du WEB (HTML/CSS et Javascript) : les différentes pages sont en HTML (avec un formulaire de connexion,...) afficher le goban en HTML actualiser le goban en Javascript (pose de la pierre au clic et pas seulement au rechargement de la page) affichage de différent messages pour avertir l'utilisateur des action du Machiabot (initialisation, réflexion,...) retirer les pierres capturées calculer le score (nombre de pierres capturées) et l'afficher et même l'utilisation d'ajax : un chat qui permet le dialogue entre l'utilisateur qui joue et ceux qui regardent la partie (limité à 5 messages affichés)

6 Partie 2 : Le modèle MVC et son implémentation pour notre projet 6 Partie 2 : Le modèle MVC et son implémentation pour notre projet 2.1 Présentation J2EE, TomCat, modèle MVC et le rôle de web.xml Comme expliqué précédemment, nous avons découvert et implémenté un nouveau concept servant à réaliser des applications WEB en Java, l'architecture J2EE. Le J2EE signifie Java 2 Entreprise Edition. Cette architecture est très utilisée dans le milieu professionnel car elle offre des possibilités de développement et une robustesse d'applications incomparables. Le J2EE fonctionne avec ce qu'on pourrait assimiler ou comparer à un serveur WEB qui comprendrait notre code JAVA et nous générerait le code HTML de la page WEB demandée. Cela est le cas en PHP, le client demande une page *.php et le serveur se charge de récupérer par exemple des informations dans une base de données et de générer le code HTML de la page web en réponse. Par analogie au PHP, nous pourrions dire que nous utilisons un serveur qui génère les pages HTML. Cependant, il offre des possibilités bien plus importantes qu'un serveur PHP. Nous y reviendrons. En java, le principe, bien qu'il y ait un serveur qui génère la page de réponse, est totalement différent. Le J2EE est bâti sur le principe du modèle MVC pour Modèle Vue Contrôleur. Le modèle M, peut être une ou plusieurs classes JAVA. Et c'est là toute la puissance du J2EE par rapport à par exemple PHP qui seul peut générer des pages. Là notre modèle peut être un jeu, une application JAVA quelconque qui effectue des traitements, une classe permettant de gérer des bases de données...n'importe quoi...du moment qu'il s'agit de classes JAVA. Nous avons donc un modèle (rappel : des classes JAVA) qui effectue des traitements. Il faut maintenant que notre client (utilisateur) ait une interface lui permettant d'accéder aux informations de notre modèle. C'est le rôle des VUES. Par analogie encore au PHP, elles seraient similaires à des fichiers PHP. Sauf, qu'il s'agit de pages *.jsp pour JAVA SERVER PAGE. Elles permettent de récupérer la réponse du serveur à une requête et d'envoyer une requête au serveur. C'est ici qu'intervient le dernier élément du modèle MVC, les CONTROLEURS. Il s'agit de classes JAVA particulières héritant de la classe HttpServlet des packages javax.servlet.http inclus dans les classes JAVA de base. Ces classes qui héritent de HttpServlet s'appellent des Servlets. Elles implémentent des attributs (qui peuvent être des objets de nos modèles pour récupérer des données), et surtout une méthode principale doget(..) prenant comme paramètres deux objets très importants : HttpServletRequest request (la requête demandée par une page.jsp), HttpServletResponse response (la réponse qui va être générée dans cette méthode).

7 Partie 2 : Le modèle MVC et son implémentation pour notre projet 7 Un point s'avère nécessaire ici afin de bien résumer les nouvelles notions que nous venons d'aborder : J2EE est le diminutif de Java 2 Entreprise Edition. Cela est une architecture qui permet de générer des pages HTML tout en effectuant des traitements dans des classes Java. Pour cela, J2EE implémente le modèle MVC (Modèle Vue Contrôleur). Le modèle emmagasine des classes Java quelconques faisant divers traitements souhaité, comme des accès à des bases de données, le lancement d'un jeu, une application de comptabilité La vue consiste en des pages.jsp (Java Server Pages) qui contiennent du code HTML et du code JAVA qui sera transformé par le serveur en HTML. Au final, après traitement par le serveur, la page ne contiendra que du code HTML (adapté à un simple navigateur WEB). Et finalement, des contrôleurs appelés Servlet qui font le lien entre notre client et ses vues (ce que l'utilisateur voit) et ses demandes (exemple : calculer sa paye de ce mois ci...il envoie sa requête par un fichier paye.jsp, un contrôleur Servlet calcul_paye.java va recevoir sa requête et aller consulter le bon modèle qui serait par exemple une application de gestion des employés dans une entreprise et qui contient l'information. Une fois que la servlet calcul_paye a trouvé l'information, elle redirige la requête vers une réponse qui sera dirigée vers une page (vue) de réponse resultat.jsp). Le schéma ci dessous récapitule ce que nous venons d'aborder :

8 Partie 2 : Le modèle MVC et son implémentation pour notre projet 8 Nous avons introduit le modèle MVC, mais il faut maintenant posséder, comme en PHP, un serveur pouvant implémenter notre modèle MVC. On parle en langage informatique dans le domaine J2EE de «serveur d'applications». Il en existe plusieurs : JBoss ; Apache TomCat WebSphere ; GlassFish ; WebLogic server ;... Tous ces serveurs d'applications possèdent les mêmes spécifications! Ce sont tous des conteneurs de servlets, mais seulement certains d'entre eux peuvent contenir ce qu'on appelle des EJB (Enterprise JavaBeans) cf. ci dessous. Dans notre application Machiaconnect, nous avons utilisé Tomcat. Pour informations, TomCat n'est considéré que comme un simple «conteneur de servlet» car il permet de gérer le modèle MVC mais ne propose pas de fonctionnalités plus poussées telles que la gestion d'ejb (Enterprise JavaBeans) qui permettent de développer certains modèles sur des serveurs distants indépendants... Dans notre cas, notre serveur qui gère notre modèle (le Machiabot ) se trouve sur la même machine que l'application Machiabot, nous ne nécessitions donc pas de gestion d'ejb. C'est pourquoi, nous avons utilisé TomCat comme environnement d'exécution de notre application J2EE. Ces conteneurs de servlet permettent de faire le lien entre nos Modèles Vue Contrôleurs grâce à un petit fichier xml bien pratique : web.xml. Le fichier web.xml contient les informations pour rediriger les requêtes. Par exemple, le joueur clique sur le goban, il sera redirigé vers partie.do ce qui correspond à la servlet Jouer.java. Cela se fait grâce aux balises <servlet> et <servlet mapping>. <servlet> <servlet class>com.servlet.machiaconnect.jouer</servlet class> <servlet name>jouer</servlet name> </servlet> <servlet mapping> <servlet name>jouer</servlet name> <url pattern>/partie.do</url pattern> </servlet mapping>

9 Partie 2 : Le modèle MVC et son implémentation pour notre projet 9 Le nom qui sera affiché à l'utilisateur dans l'url apparaît dans la balise <url pattern>. Ce nom est totalement arbitraire, mais il peut s'avérer utilise de nommer les pages de traitements par un suffixe «.do» pour indiquer que l'on va vers une page de traitement (une servlet qui cherchera une information dans un modèle). 2.2 Notre implémentation : servlet Jouer.java, les modèles (Gestionnaire.java, Machiabot, Pierres) et vue jeu.jsp. Comme nous avons suivi le modèle MVC, notre application possède des vues JSP, des modèles (gestion d'une partie, lancement du Machiabot, communication avec lui) et des contrôleurs objets Servlet. Pour simplifier, nous allons présenter seulement les classes fondamentales à notre application. Le contrôleur principal est la classe Jouer.java héritant de la classe HttpServlet. Le modèle principal est une classe Gestionnaire.java qui permet de gérer la partie (les coups joués, le score, l'envoi à Machiabot du coup...) La vue principale est jeu.jsp qui affiche le goban mis à jour, les coups joués et d'autres informations. Procédons par ordre, l'utilisateur vient de s'identifier au travers d'une page d'authentification, si ses informations de compte sont valides (login, password), il est alors redirigé vers notre contrôleur Jouer.java. Tout se passe ensuite dans la méthode principale (rappel : la méthode doget est la méthode principale d'une servlet) doget(...). public void doget( HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException{ Dès que nous sommes redirigés par une vue (rappel : un fichier.jsp) vers partie.do, l'ensemble de la méthode doget(...) est exécuté. if(partie==null){ initialisation() ; Si aucune partie n'est en cours, on initialise une partie. L'initialisation consiste en l'instanciation d'un nouveau Gestionnaire dans l'attribut Gestionnaire partie. Le gestionnaire s'occupe de lancer Machiabot, du déroulement de la partie et du calcul des coups. Il fait le lien entre notre servlet Jouer.java et le jeu machiabot en lui même. Nous verrons après comment Machiabot tourne dans un processus et comment un modèle communique avec lui et envoie/reçoit les informations du Gestionnaire.

10 Partie 2 : Le modèle MVC et son implémentation pour notre projet 10 La servlet Jouer effectue diverses vérifications, c'est son rôle de contrôleur. Elle regarde si un coup est demandé, si la partie est finie, etc. Il est facile de passer des paramètres de requêtes par URL à la servlet en indiquant dans l'url par exemple partie.do?param1=xxx&param2=yyyyy. Par exemple, si un coup a été joué par l'utilisateur, le paramètre coupp est renseigné et dans ce cas, on envoie ce coup au Gestionnaire qui se chargera de communiquer avec l'instance du processus Machiabot. //on récupère le coup joué par le joueur s'il y en a un String coup = request.getparameter("coupp"); //on teste ici si le coup est valide ou non (utilisateur qui rentre dans l'url des coupp) if( partie!=null && partie.coupvalide(coup) &&!partie.getpartiefinie()){ coup=partie.jouer(coup); Rappel : Nous sommes dans Jouer.java et l'attribut partie est un objet de type Gestionnaire. Ensuite le goban mis à jour par le gestionnaire est récupéré. HashMap<String, Boolean> goban = this.partie.getgoban(); HashMap<String, String> played = this.partie.getplayed(); Puis, il est passé en attribut de requête pour qu'il puisse être utilisé par la vue (la.jsp) où sera redirigée la réponse. request.setattribute("goban", goban); request.setattribute("played", played); Ensuite, une fois le goban mis à jour passé en paramètre pour la réponse, nous pouvons rediriger la requête vers la JSP d'affichage principal jeu.jsp. request.getrequestdispatcher("jeu.jsp").forward(request, response); La vue jeu.jsp est capable de récupérer nos attributs goban et played pour afficher le goban mis à jour. Contenu extrait de jeu.jsp : <%HashMap<String, Boolean> goban = (HashMap<String,Boolean>)request.getAttribute("goban"); %> Les balises <% %> permettent d'insérer du code JAVA au sein du code HTML de la page JSP.

11 Partie 2 : Le modèle MVC et son implémentation pour notre projet 11 Le goban est ensuite affiché en fonction des informations contenues dans l'attribut goban. <% if((boolean)goban.get(colonne[j]+ligne[i])==false){ out.print("<a name=\"casevide\" href=\"#\" onclick=\"refresh_div_goban('"+colonne[j]+ligne[i]+"'); clicked('"+colonne[j]+ligne[i]+"', 'numcoup');return false;\" >"); %> On voit bien que la vue (.jsp) possède du HTML et génère aussi du HTML à partir de code JAVA d'où son nom de Java Server Page (JSP). Nous arrivons à l'affichage du résultat suivant : Ce screenshot représente la vue jeu.jsp pendant une partie. Lors du clic sur une intersection du goban, la requête de l'utilisateur sera redirigée vers Jouer.java (servlet) qui la traitera comme nous venons de le voir et renverra de nouveau vers jeu.jsp.

12 Partie 2 : Le modèle MVC et son implémentation pour notre projet 12 Le principe reste identique pour chaque fonctionnalité! Nous implémentons bel et bien le modèle MVC. Cependant, nous venons de voir le contrôleur (servlet) Jouer.java et la vue jeu.jsp mais, même si nous en avons parlé, il nous reste à voir un peu plus en détail un des modèles principaux : le modèle Gestionnaire. Ce modèle permet comme dit précédemment de gérer l'ensemble d'une partie, l'envoi des coups au bot, la récupération de la réponse du bot mais surtout il permet à notre Servlet Jouer.java de récupérer ses informations pour mettre la vue jeu.jsp à jour au fur et à mesure. Cette classe Gestionnaire possède un attribut de type Machiabot qui permet de lancer le Thread du jeu Machiabot. private Machiabot machiabot; private Thread m; Et donc, dans la méthode initialisation() de la classe contrôleur (servlet) Jouer.java instancie un nouveau Gestionnaire() qui lui lance le Thread de Machiabot (l'instance du programme Machiabot). Voici le constructeur de Gestionnaire() : machiabot = new Machiabot(); m = new Thread(machiabot); m.setpriority(thread.max_priority); m.start(); Une explication plus détaillée du fonctionnement des Threads sera faite à la partie suivante. Le schéma suivant résume le fonctionnement (très simplifié) de notre application. Un dernier modèle est présent dans notre application. Il s'agit de Pierre.java qui permet de calculer les pierres à enlever quand elles n'ont plus de libertés. Nous ne détaillons pas ici cette classe car elle fera l'objet d'une partie dans ce rapport par la suite.

13 Partie 3 : Le modèle fondamental : la classe Machiabot.java 13 Partie 3 : Le modèle fondamental : la classe Machiabot.java 3.1 Les Threads et le lancement du process de communication avec Machiabot. Afin d'exécuter des tâches en parallèle, JAVA nous donne la possibilité d'exécuter des Processus (Threads) grâce à des objets de la classe Thread. La classe Thread se compose comme une classe classique. Elle peut posséder des attributs, des méthodes private ou public mais l'essentiel réside dans sa méthode run(). C'est dans cette méthode que se font les traitements souhaités dans un processus séparé du Thread principal. Le Thread principal est par exemple pour une application classique la classe contenant la méthode main(). Pour créer un Thread, il faut créer un type d'objet héritant de la classe Thread. Exemple : public class Maclasse extends Thread{ private Type1 attribut1 ; private Type2 attribut2; private Type3 attribut3 ; public void methode1() {.. private void methode2(){.. public void run(){ /* Ici les actions qui seront traitées dans un processus différent */ Dans la classe appelant le thread (le démarrant), il faut instancier notre objet et démarrer le thread. Dans notre application il s'agit du Gestionnaire qui instancie un Thread de Machiabot. Cela se fait de la manière suivante : Dans la classe Appelante : Thread monthread = new Machiabot() ; monthread.start() ;

14 Partie 3 : Le modèle fondamental : la classe Machiabot.java 14 A l'appel de la méthode start(), le contenu de la méthode run() est exécuté dans un processus séparé. Le processus est tué une fois la méthode run() dépilée. Voici les explications importantes : Avant tout, il faut savoir que l'ordre d'exécution d'un Thread, si on en a plusieurs de lancés par leur méthode run(), est totalement aléatoire! Ceci car Java utilise un ordonnanceur. Il faut savoir également que si plusieurs threads sont lancés dans une application, ils ne s'exécuteront pas en même temps. Java utilise un ordonnanceur qui va gérer de façon aléatoire l'accès aux méthodes run() des différents Threads. Admettons, nous avons trois threads appelés t1, t2 et t3. Dans la classe appelante nous lançons les trois threads en même temps : t1.start() ; t2.start() ; t3.start() ; Là, trois processus sont créés et chacun va réaliser les instructions de leur méthode run(). Admettons que notre méthode run() de t1 possède 10 lignes, celle de t2, 15 lignes, et celle de t3, 20 lignes. Alors l'ordonnanceur va utiliser un des Threads, pendant un certain laps de temps, puis va passer à un autre, puis revenir à t1 et cela jusqu'à ce que toutes les instructions des méthodes run() de chaque thread soit terminée! Par exemple, t1 va voir 5 lignes exécutées, ensuite l'ordonnanceur passe à t2 et lance 8 lignes, revient à t1 et execute 2 lignes, ensuite passe à t3 et exécute 4 lignes...tout cela de façons aléatoires tant que chaque méthode run() n'est pas dépilée. Quand l'ordonnanceur passe d'un Thread à l'autre, le thread interrompu est mis en sommeil durant tout le temps où l'autre est en éveil. Voici les différents états que peut prendre un thread : NEW : quand il est instanciée Thread t1 = new Thread() ; RUNNABLE : quand la méthode start() est invoquée, il commence à s'exécuter méthode run(). TERMINATED : une fois que les tâches (toutes les lignes) de la méthode run() sont totalement exécutées, le Thread est mort. Subtilité, un thread mort ne peut pas être relancé par sa méthode start(). TIMED_WAITING : lorsque il est en en pause méthode sleep(). WAITING : il est en attente indéfinie... BLOCKED : c'est l'état qu'utilise l'ordonnanceur pour le mettre en sommeil le temps d' en utiliser un autre.

15 Partie 3 : Le modèle fondamental : la classe Machiabot.java 15 Comme dit précédemment : un thread est considéré comme terminé (MORT), seulement lorsque sa méthode run() est dépilée de la pile d exécutions! Le schéma précédent explique bien le rôle que jouent les Threads et comment ceux ci sont exécutés par l'ordonnanceur. Java nous propose également une interface pour rendre plus robuste l'utilisation de Threads. Il s'agit de l'interface Runnable. Cette classe se trouve également dans le package java.lang. L'interface Runnable permet d'éviter l'héritage systématique à la classe Thread dans le cas d'un Thread classique. Cela permet d'utiliser des objets qui héritent de n'importe quelle classe et il suffit d'implémenter l'interface Runnable. Surtout que le langage Java ne gère pas l'héritage multiple donc il est très facile de se retrouver coincé si nous voulons créer un Thread qui hérite d'une classe quelconque. Runnable règle le problème. Exemple : public Maclasse extends Maclasse2 implements Runnable{ /* Mes attributs et méthodes de classe */ public void run(){...

16 Partie 3 : Le modèle fondamental : la classe Machiabot.java 16 Le fait d'implémenter l'interface Runnable permet d'utiliser notre objet comme un objet quelconque tout en pouvant l'utiliser comme un Thread de la manière suivante : Thread t1 = new Thread(new Maclasse()) ; Notre application peut donc utiliser un ou plusieurs objets de type Thread. Nous avons vu que nos Thread sont exécutés de manière aléatoire. Il existe cependant une façon de synchroniser nos Threads. La solution consiste en prévenir l'ordonnanceur qu'un thread a besoin ou doit utiliser des données qu'un autre thread utilise ou a utilisé ou est en train d'utiliser. Lorque l'ordonnanceur mettra en sommeil un Thread t1 qui utilisait par exemple un objet o1, si pendant ce temps le Thread t2 veut accéder à ce même objet, il ne pourra pas si on synchronise les méthodes d'accès à notre objet o1. Tant que l'ordonnanceur ne reviendra pas sur le Thread t1 pour finir les traitements qu'il effectuait dessus, les autres Threads, ici t2, ne pourront pas y accéder. Cette technique s'appelle la synchronisation de Threads. Pour synchroniser des Threads il suffit de rajouter le mot clé synchronized devant les méthodes que l'on veut synchroniser. Cela se fait lors de la déclaration de la méthode, de la manière suivante : public synchronized void setobjet1(object po1){ o1 = po1 ;

17 Partie 3 : Le modèle fondamental : la classe Machiabot.java La classe Machiabot.java Maintenant que nous avons vu comment fonctionnent les Threads et surtout à quoi servent ils, nous pouvons maintenant voir en détails le modèle Machiabot.java qui implémente l'interface runnable. Nous savons (vu précédemment) que le modèle Gestionnaire.java possède un attribut de type Thread prenant comme objet un Machiabot. Cet objet Machiabot implémente l'interface Runnable pour lancer le programme Machiabot dans un Thread à partir de la classe Gestionnaire durant la durée de la partie. Nous allons voir en détails maintenant comment ce Thread est lancé et comment la communication se fait avec lui. Tout le voyage commence au niveau du constructeur de Gestionnaire qui lance le Thread Machiabot et effectue Machiabot.start() ; Si vous avez bien suivi notre explication sur les Threads citée précédemment, l'exécution de Machiabot.start() lance donc la méthode run() de la classe Machiabot.java dans un processus séparé. Cette méthode run() contient une boucle infinie. Le thread Machiabot se terminera une fois la fin de partie décelée par le gestionnaire. while(!gestionnaire.getfinpartie()){ PrintStream monfichier = new PrintStream(os); System.setOut(monfichier); this.process = new ProcessLauncher(os, os, this.fis); this.process.exec("../../../machiabot/trunk/expertbot/expertbot"); Le programme physique (exécutable) du jeu Machiabot est lancé par l'instruction this.process.exec(«chemin absolu ou relatif de l'exécutable» ). La partie est ainsi lancée, et nous utilisons des PrintStream (flux) pour communiquer avec le Machiabot (cette instance de process). Il faut noter que la méthode ne s'arrête jamais sauf si finpartie devient vrai ou que le process s'arrête (Machiabot plante, ou autre arrêt forcé de Machiabot...). Une méthode permet de passer finpartie à true pour arrêter le process, il s'agit de la méthode killmachiabot() de la classe Gestionnaire.

18 Partie 3 : Le modèle fondamental : la classe Machiabot.java 18 Nous allons voir maintenant dans le détail l'envoi et la réception des coups par Machiabot au travers des PrintStreams. Cela se déroule dans la méthode jouer() de la classe Gestionnaire qui est surchargée dans la classe Machiabot. 3.3 La méthode jouer(string coup) Elle est définie dans Gestionnaire puis dans Machiabot. Elle permet d'envoyer et de récupérer les coups de Machiabot. Voici le détail de la méthode setenvoi(coup) : public void setenvoi(string penvoi){ FileInputStream fis; try { fis = new FileInputStream(new File(pEnvoi)); this.process.setinputstream(fis); process.createstreamthread(fis, process.getprocess().getoutputstream()); catch (FileNotFoundException e) { e.printstacktrace(); fis = null; int nbreponses = this.reponses.size();

19 Partie 3 : Le modèle fondamental : la classe Machiabot.java 19 while(this.reponses.size()<(nbreponses+4)){ updatereponse(); System.out.println("nbRep"+nbReponses+"vector"+this.reponses.size() +this.reponses); updatereponse(); La méthode setenvoi(coup) utilise un FileInputStream pour communiquer avec le process physique Machiabot en définissant cet InputStream comme Entrée Standard du process Machiabot. process.createstreamthread(fis, process.getprocess().getoutputstream()); Un Thread est ainsi créé et enverra à Machiabot le coup. Ensuite on effectue des updatereponse() tant que le jeu Machiabot n'a pas répondu. while(this.reponses.size()<(nbreponses+4)){ updatereponse(); Une fois la réponse obtenu, le Gestionnaire l'aura automatiquement car sa méthode jouer(coup) fonctionne ainsi : Elle exécute setenvoi(coup) ; dernierereponse = machiabot.getreponse() ; Puis, elle attend la réponse while(!machiabot.getreponse()!=dernierereponse){ dernierereponse = machiabot.getreponse() ; Une fois que le Gestionnaire a récupéré la réponse, vous connaissez la suite. La méthode doget(..) de la servlet Jouer passe en attribut de requête la réponse et ensuite redirige vers la vue jeu.jsp.

20 Partie 4 : Les sessions 20 Partie 4 : Les sessions 4.1 Rôle des SESSIONS: Une des problématiques du projet était de pouvoir observer une partie quand quelqu'un joue, mais sans que l'on puisse jouer sur le même goban; il fallait donc pouvoir identifier les utilisateurs, et nous avons décidé d'utiliser les sessions. Une session est un objet Java HttpSession qui est valable tant que l'on ne ferme pas le navigateur ou que l'on ne l'invalide pas. Dès que l'on utilise une application Java, une session est créée automatiquement. La session créée possède un identifiant du type: "D3F760B4E2CD223C681B0CE17FFAA7C3" qui est unique mais dans une servlet, on peut récupérer cet objet HttpSession : HttpSession session=request.getsession(); On peut ensuite créer des attributs dans cette session qui seront donc transmis avec la session dans les autres servlets et valables durant toute la durée de la visite de l'utilisateur. Cela permet de retrouver, par exemple, le login que l'utilisateur a rentré pour se connecter. Comme tout objet Java, les Sessions ont un grand nombre de méthodes prédéfinies qui permettent de faire toutes sortes de traitements, mais pour notre projet nous n'en avons utilisé que 4 : getid(): pour récupérer l'identifiant; getattribute('nomattribut'): pour récupérer la valeur d'un attribut; setattribute('nomattribut', 'valeur'): pour créer ou modifier un attribut existant en lui attribuant une valeur ou un objet Java; invalidate(): pour clore la session (quand l'utilisateur se déconnecte "manuellement"). Il existe aussi une méthode setmaxinactiveinterval(int temps) qui permet de définir le temps d'inactivité avant que la session ne soit invalidée par le conteneur de servlet mais il existe d'autres moyens de paramétrer cela.

21 Partie 4 : Les sessions 21 Avec Tomcat, une session est invalidée automatiquement après 30 minutes d'inactivité mais nous avons réduit ce temps à 10 minutes en modifiant le fichier web.xml, qui vous a déjà été présenté, en ajoutant : <session config> <session timeout>10</session timeout> </session config> Comme une session doit pouvoir être invalidée à la demande de l'utilisateur sans que celui ci ne soit obligé de fermer son navigateur, nous avons créé une servlet FinSession.java contenant dans la méthode doget() : HttpSession session=request.getsession(); session.invalidate(); Suivi d'une redirection vers une jsp indiquant que le session a été fermée. Une nouvelle session est automatiquement créée pour succéder à la première mais elle ne contient aucun attribut concernant l'utilisateur. La principale utilité est pour reconnaître un utilisateur et savoir s'il est celui qui joue ou s'il regarde la partie. Dans la classe Jouer.java (servlet qui nous permet de jouer), quand on lance une partie on met la session en attribut : HttpSession sessionpartie = request.getsession(); On y met l'objet HttpSession, cela nous permet d'avoir l'identifiant et les attribut avec les différentes méthodes get(). Quand un joueur se connecte, on teste alors sa session pour savoir si la session sur laquelle il est connectée est celle qui a commencé la partie; si c'est le joueur on le redirige vers jeu.jsp, sinon on le redirige vers la page de visualisation de partie partieencours.jsp. Mais si la session qui a commencé la partie est invalidée, on ne pourra plus commencer de partie (car quand une session est close, la classe Jouer.java ne remet pas la session en attribut à NULL). La solution trouvée a été de créer une classe sessioncounter qui est un Listener qui peut réaliser une action à chaque ouverture et/ou fermeture de session.

22 Partie 4 : Les sessions 22 Nous l'avons codé de façon à ce que quand une session s'ouvre, on la récupère et on la met dans un tableau; et quand une session se ferme (manuellement ou par timeout), on la supprime du tableau. Ce tableau représente donc les sessions actives et on peut le récupérer dans la classe Jouer.java. //On récupère la liste des sessions actives ArrayList<HttpSession> listesessions = SessionCounter.getList(); //On teste si la session est nulle ou si elle a expiré if(this.sessionpartie == null!listesessions.contains(this.sessionpartie)){ A chaque fois que quelqu'un se connecte, on regarde si la session de la personne qui joue est encore active ou s'il est déconnecté. Dans ce dernier cas, on redémarre une partie (nouvelle instanciation de Gestionnaire, remise à zéro des variables score, goban,...) en mettant la session de celui qui vient de se connecter en attribut dans sessionpartie de Jouer.java. 4.2 Les attributs de session Comme nous l'avons vu, nous pouvons aussi mettre des attributs dans une session : Le fait de mettre un attribut de session "login" a plusieurs utilités: cela permet de vérifier que la session a été initialisée par un utilisateur qui s'est connecté. Car dès que l'on arrive sur la page d'accueil du site on a une session qui n'a qu'un identifiant tant qu'on ne se connecte pas, et tant qu'on ne se connecte pas on ne devrait pas avoir accès au site. Mais si on entre l'adresse d'une page telle que jeu.jsp dans l'url on pourrait y accéder si il n'y avait pas de vérification de la présence de l'attribut "login". cet attribut sert aussi à afficher le nom du joueur dans l'affichage du score de la partie et dans le chat, il est donc nécessaire que tous ceux qui observent la partie soient enregistrés pour être identifiable quand ils discutent. Sur le même principe, nous avons passé en attribut de session les gobans (donnés sous forme de tableau par Jouer.java) pour pouvoir les retrouver dans les JSP. // dans Jouer.java on met les attributs HashMap<String, Boolean> goban = this.partie.getgoban(); HashMap<String, String> played = this.partie.getplayed();

23 Partie 4 : Les sessions 23 request.getsession().setattribute("goban", goban); request.getsession().setattribute("played", played); // dans jeu.jsp on les récupère <%HashMap<String, Boolean> goban = (HashMap<String, Boolean>)request.getSession().getAttribute("goban"); %> <%HashMap<String, String> played = (HashMap<String, String>)request.getSession().getAttribute("played"); %> Une fois que l'on a les gobans sous forme de tableau dans les jsp, il est facile de les générer sous une forme plus explicite avec des images comme nous le verrons plus tard. Les dernières améliorations de notre application nous ont permis de rajouter quelques attributs pour les sessions qui seront abordés dans la partie sur l'interface WEB : Le dernier coup envoyé par le joueur, Le score (les pierres capturées) qui est calculé par la classe Pierre.java, Le tableau qui contient les messages du «chat».

24 Partie 5 : L'interface WEB 24 Partie 5 : L'interface WEB 5.1 La base en HTML/CSS Pour la partie WEB, nous avons donc utilisé le langage HTML avec un fichier CSS pour la présentation. La principale fonction de l'interface a été la génération d'un goban avec des images : <%String[] ligne = {"9", "8", "7", "6", "5", "4", "3", "2", "1"; String[] colonne = {"A", "B", "C", "D", "E", "F", "G", "H", "J"; %> <table cellspacing="0" cellpadding="0" > <tr> <td></td> // Première ligne on met les lettres <%for(int i=0; i<colonne.length; i++){ out.println("<td><div align=\"center\">"); out.print(colonne[i]+"</div></td>"); %> </tr> // puis pour chaque ligne suivante <%for(int i=0; i<ligne.length; i++){ out.println("<tr>"); // première colonne on met le chiffre correspondant à la ligne out.print("<td>"+ligne[i]+"</td>"); for(int j=0; j<colonne.length; j++){ out.print("<td>"); // si la case est libre (d'après le tableau goban) if((boolean)goban.get(colonne[j]+ligne[i])==false){ // on met le lien qui permettra de jouer sur cette case (représentant une intersection) out.print("<a name=\"casevide\" href=\"#\" onclick=\"fonctionsjavascript\" >"); // et on met l'image d'un intersection libre out.print("<img id=\""+colonne[j]+ligne[i]+"\" src=\"intersection.png\" />"); out.print("</a>"); else{ // sinon on regarde la couleur de la pierre (tableau played) et on met l'image //correspondante if((played.get(colonne[j]+ligne[i])).equals("black")){ out.print("<img src=\"intersection_b.png\" />"); else{

25 Partie 5 : L'interface WEB 25 out.print("<img src=\"intersection_w.png\" />"); out.print("</td>"); out.println("</tr>"); out.print("<br />"); %> </table> Cela nous génère donc un tableau d'images dont certaines ont des liens, et qui est mis en page avec quelques lignes de CSS (pour supprimer les marges et avoir un goban qui semble être en une pièce). Nous ne présenterons pas ici le reste du code HTML qui n'a que peu d'intérêt. 5.2 L'amélioration avec Javascript page. Le langage javascript nous a été utile pour améliorer l'affichage sans recharger une La première fonction que l'on a mise est celle qui affiche un message quand un utilisateur se connecte et que le Machiabot s'initialise (car cela prends plus de 10 secondes et l'utilisateur peut cliquer plusieurs fois si rien ne l'averti que le programme a bien reçu la demande de connexion). Il était inutile de rediriger l'utilisateur vers une page d'attente qui n'aurait rien apporté de plus. Là où le javascript est essentiel, c'est dans la fonction suivante: <script language=javascript> var click = new Boolean(); click=false; function clicked(coord, numcoup){

26 Partie 5 : L'interface WEB 26 document.getelementbyid('message').innerhtml="<h3> Machiabot réfléchit, merci de ne pas rafraichir la page</h3>"; // si premier clic if (click==false){ click=true; //actualisation au clic du coup joué et de l'image du goban //(sans attendre le rechargement de la page) document.getelementbyid(numcoup).innerhtml=" played "+coord; if(coord!="pass"){ document.getelementbyid(coord).setattribute("src", "intersection_w.png"); // désactivation de tous les liens de goban document.getelementsbyname("casevide").removeattribute("href"); </script> Cette fonction est appelée à chaque clic sur une position possible du goban ou sur le bouton "passer son tour". Dès que l'on a cliqué un message s'affiche pour prévenir le joueur, avec la fonction innerhtml; on met à jour les coordonnées du coup joué (affiché au dessus du score) et si le coup n'est pas "passer" on place la pierre sur le goban (en fait on change l'attribut "src" qui correspondait à une image d'intersection vide pour mettre une image d'intersection avec une pierre blanche). Nous ne le faisons pas pour les pierres noires car quand Machiabot envoie sa réponse on actualise le goban (et donc remise à "" du message et à false de la variable click). La dernière partie de la fonction sert à "désactiver" les liens: on retire les attributs "href" et donc si l'utilisateur clique dessus il ne se passe plus rien.

27 Partie 5 : L'interface WEB 27 Et si l'utilisateur est malveillant et entre un coup dans l'url quand Machiabot cherche un coup, c'est la servlet Jouer.java que le redirigera vers une page d'erreur qui réaffichera le goban quand Machiabot aura répondu. 5.3 Un nouveau modèle : algorithmes de retrait de Pierres. Nous avions terminé l'application mais cette dernière ne retirait pas les pierres et ne comptait pas le score. Si vous avez bien suivi et compris notre partie sur J2EE, vous devez deviner de quel type une classe retirant les pierres (Pierre.java) est? (Modèle, Vue ou Contrôleur)... Bien sur, il s'agit d'un modèle. Ce modèle s'appelle Pierre.java. Il est appelé et instancié par la méthode jouer(coup) du contrôleur (servlet) Jouer.java. la pierre noire est retirée quand 4 pierres blanches l'entourent totalement: elle n'a plus de liberté. Et cela se fait de manière récursive. Si une pierre est entourée, nous regardons d'abord si cette pierre possède des libertés (aucune pierre sur une intersection), sinon si elle possède une pierre de même couleur, et si c'est le cas nous relançons l'algorithme sur la pierre voisine jusqu'à ce qu'une liberté soit trouvée.

28 Partie 5 : L'interface WEB 28 Quand une pierre blanche sera posée sur l'intersection distinguée par la flèche rouge, toutes les pierres noires présentes sur l'image ci dessus seront retirées. Si une liberté est trouvée, la pierre (ou l'ensemble de pierres) n'est pas retirée ; sinon la pierre (ou l'ensemble de pierres) est retirée du Goban et le score mis à jour du nombre de Pierres retirées. Notre objet instancié du modèle Pierre.java met à jour le score automatiquement. Il remet à jour l'état du goban aussi dans le Gestionnaire de la partie avant que le contrôleur Jouer.java ne le transmette à la vue jeu.jsp. Le détail de notre algorithme et son implémentation est disponible en annexes dans le code de la classe Pierre.java. 5.4 Les dernières touches avec Ajax Une fois notre application fonctionnelle, nous avons voulu ajouter un module de Chat permettant aux utilisateurs (le joueur et les éventuels observateurs) de dialoguer entre eux. Le chat a été créé de la manière suivante : Un joueur saisit un message dans la zone input texte du formulaire. Il appuie sur entrée ou clique sur valider pour envoyer son message. La validation de ce formulaire ne redirige pas vers une page de traitement. La validation déclenche une fonction JavaScript AJAX qui va envoyer au serveur le message saisi et mettre à jour seulement le contenu de la balise <div id='message'></div>. Tout cela paraît simple dans le principe, mais voyons comment fonctionne l'ajax. Le principe de l'ajax est simple. Ajax est l'acronyme de ASYNCHRONOUS JavaScript And XML. Pour simplifier, il s'agit d'utiliser du XML de manière asynchrone pour communiquer avec le serveur sans avoir à recharger une page. Il faut savoir que l'ajax n'est pas un langage de programmation ni une technologie. Il s'agit d'un concept de programmation pour le Web qui évite le rechargement d'une page. L'information est mise à jour en temps réel et cette mise à jour est totalement transparente pour l'utilisateur. Ce dernier voit l'information apparaître sans qu'il n'ait à intervenir.

29 Partie 5 : L'interface WEB 29 Cela explique pourquoi JavaScript est utilisé dans l'ajax, car il permet de mettre à jour le contenu d'une division, d'un formulaire...grâce à l'arbre DOM. La méthode AJAX est simple, il suffit de déclarer une méthode JavaScript qui instancie un objet XMLHttpRequest. C'est cet objet qui transmettra au serveur sous forme de flux XML nos données et récupérera l'information de ce dernier. (En fait, comme si nous avions rechargé la page). L'objet XMLHttpRequest s'instancie de la manière suivante : var xhr = new XMLHttpRequest(); Pour rappel : le JavaScript possède des variables transtypés. C'est à dire, il n'y a pas de type associé aux variables JavaScript. Il y a une variante à l'objet XMLHttpRequest à ne pas négliger, car elle est indispensable sous Internet Explorer. Merci encore à Microsoft de compliquer les tâches! Tous les navigateurs utilisent XMLHttpRequest alors que sous Internet Explorer il faut utiliser un objet ActiveXObject.

30 Partie 5 : L'interface WEB 30 Il est donc nécessaire avant toute action, de détecter le navigateur de l'utilisateur. if (window.xmlhttprequest window.activexobject) { if (window.activexobject) { try { xhr = new ActiveXObject("Msxml2.XMLHTTP"); catch(e) { xhr = new ActiveXObject("Microsoft.XMLHTTP"); else { xhr = new XMLHttpRequest(); On rafraichit la page en AJAX en récupérant les informations de XMLHttpRequest par une Java Server Page (JSP) chat.jsp qui elle récupère dans le contrôleur (servlet) adéquat le contenu des messages de chat. Voici la fonction JavaScript AJAX s'occupant de mettre à jour nos informations de chat : function refresh_div(message) { var xhr_object = null; if(window.xmlhttprequest) { // Firefox xhr_object = new XMLHttpRequest(); else if(window.activexobject) { // Internet Explorer xhr_object = new ActiveXObject('Microsoft.XMLHTTP'); var method = 'GET'; var filename = 'display.do?'; filename+="chat=ok"; if(message!=null)filename+="&chat_message="+message; if(navigator.appname=='microsoft Internet Explorer'){

31 Partie 5 : L'interface WEB 31 var dattmp = new Date(); filename+="&dattmp="+dattmp; xhr_object.open("get", filename, false); else{ xhr_object.open(method, filename, true); xhr_object.onreadystatechange = function() { if(xhr_object.readystate == 4) { var tmp = xhr_object.responsetext; document.getelementbyid('tchat middle').innerhtml = tmp; xhr_object.send(null); settimeout('refresh_div()', 2000); Pour finir, on demande au navigateur de relancer cette méthode JavaScript AJAX toutes les 2 secondes pour actualiser le chat. settimeout('refresh_div()', 2000); Nous utilisons également l'ajax pour mettre à jour le score de la même manière.

32 Partie 6 : Principaux problèmes rencontrés 32 Partie 6 : Principaux problèmes rencontrés 6.1 Les erreurs Java En programmant notre application, nous avons eu un certain nombre d'erreurs Java qui redirigeaient vers une page du type : Ce type de message d'erreur n'est pas pratique pour un utilisateur car il n'a pas d'autres choix que de cliquer sur la touche retour du navigateur ou d'entrer une autre adresse dans l'url. Notre application est maintenant fonctionnelle et ne devrait plus renvoyer d'erreurs, cependant nous ne sommes pas à l'abri d'un dysfonctionnement du serveur (empêchant de lancer le programme) ou d'un plantage de Machiabot en cours de partie. Nous avons donc mis en place des structures try/catch à toutes les étapes susceptibles de renvoyer une erreur dans Jouer.java : try { initialisation(); request.getrequestdispatcher("jeu.jsp").forward(request, response); catch (InitException e) { e.printstacktrace(); detruire(); request.setattribute("exception", e); request.getrequestdispatcher("exception.jsp").forward(request, response);

33 Partie 6 : Principaux problèmes rencontrés 33 Dans cet exemples, le programme va essayer de lancer la méthode initialisation(), si ça marche, il redirige vers la page jeu.jsp ; sinon, il «catch» l'erreur, l'imprime dans un journal d'erreur de Tomcat (avec e.printstacktrace()) puis détruit la partie en cours (qui est pour le moment irrécupérable en cas de bug) et envoie l'erreur vers une page exception.jsp qui l'affichera comme cela : L'utilisateur est toujours ennuyé mais il a la possibilité de recommencer une partie (sans avoir à se reconnecter) ou de se déconnecter pour quitter l'application. 6.2 Le cas du serveur Nous avons aussi eu de nombreux problèmes avec la mise en place du serveur de projets. C'est un serveur destiné au étudiants du Master IC que devait mettre en place l'administrateur réseau de l'université. Ce dernier étant très pris par la gérance du réseau UFR, il était peu disponible pour nous recevoir et pour nous renseigner sur les conditions nécessaires au déploiement de notre application. Nous avons donc installé notre application mi avril et découvert de nombreux dysfonctionnements que nous n'avions pas en faisant tourner l'application sur nos machines. Après avoir corrigé la quasi totalité des bugs apparus, nous avons remarqué que le serveur rebootait quand nous lancions le Machiabot (trop gourmand en mémoire semble t il). Il a donc fallu que Guillaume Tisserant modifie son programme pour pouvoir paramétrer la mémoire nécessaire au fonctionnement du jeu.

34 Partie 6 : Principaux problèmes rencontrés 34 Et une fois que nous avons eu ce programme «allégé» et les clés pour accéder au serveur, il semblerai que nous n'ayons plus les droit pour mettre le nouveau programme sur le serveur ; et donc à l'heure qu'il est notre application qui fonctionne sans problème en réseau local sur nos machines personnelles, tourne avec un générateur de coups aléatoires sur le serveur de projets, ce qui permet de tester toutes les fonctionnalités présentées dans ce rapport. 6.3 Les améliorations à apporter Malgré le temps passé sur le projet, nous nous sommes rendu compte qu'il y aurait encore beaucoup d'améliorations à faire et cela pourrait même être l'objet de prochains TER : lier l'application avec une base de données (pour l'instant seuls 3 utilisateurs sont enregistrés : Gael, Yvan et invite), garder un historique des messages du chat, sauvegarder les parties terminées(au format SGF), ajouter un forum pour pouvoir discuter des parties jouées, ajout d un module servant de Modèle d analyse des coups (pour intégrer un aspect didactique et aider les joueurs débutants), sauvegarder une partie en cours pour la reprendre plus tard (ou sauver la partie en cas de plantage de Machiabot), afficher plusieurs gobans, dont celui généré par le Machiabot qui affiche les pondérations de chaque intersection en fonction des probabilités de victoire, créer un fichier de configuration pour pouvoir changer la configuration du goban (9*9, 13*13 ou 19*19) sans avoir à chaque fois à chercher dans tous le code là ou il faut modifier des valeurs, ou encore améliorer l'affichage des bords du goban... Ce sont des pistes auxquelles nous avons pensé mais que nous n'avons pas eu le temps de mettre en place.

35 Conclusion 35 Conclusion Malgré la difficulté du sujet et les problèmes rencontrés, notre motivation a été récompensée. Ce projet nous a appris de nombreuses choses que nous ne verrons peut être pas en cours et qui pourrons nous être très utiles, comme la programmation d'application WEB en Java JEE, la communication avec un programme lancé par un Thread, les bases de l'ajax ainsi que l'utilisation d'un conteneur de servlet. Nous avons également eu un aperçu d'un congrès scientifique sur l'intelligence informatique en allant à Paris pour l'ieee SSCI (détails en annexe), ce qui nous a introduit aux méthodes de calculs de l'intelligence Artificielle (principalement pour le jeu de GO mais aussi pour d'autres applications).

36 Annexes 36 Annexes Annexe 1 : la conférence à Paris Les 13 et 14 avril dernier, nous sommes allés à Paris pour la conférence SSCI (Symposium Series on Computational Intelligence), dont une partie était dédiée à l'homme contre l'intelligence artificielle dans le jeu de GO. Cela ne nous a pas aidé dans notre projet mais nous avons assisté à un tutoriel, présenté par Chang Shing Lee et Olivier Teytaud, qui nous a permis de comprendre un peu mieux quelles sont les différentes méthodes de calculs des coups et surtout, cela nous a permis de voir plus en détails comment fonctionne le Machiabot en combinant plusieurs techniques : UCT et le système expert.