Slide 1 - The IC Home Page is in:ic.epfl.ch

POLYPOLY
PROJET DE GENIE LOGICIEL
2005
Table des matières
Introduction
 WebLang
 Diagrammes
 Machines d’états
 Topics dynamiques
 Communications
 Conclusion

Introduction

Nous avons utilisé WebLang jusqu’à la fin
du projet. Cela nous a permis de n’avoir
que quatre fichiers :

Application.la


Player.java


Client (Player + GUI)
Manager.java


Serveur
Pages Web pour gérer les parties (Servlet).
C.java

Classe contenant les constantes d’application
WebLang

Avantages


Ça nous a permis de n’avoir qu’un fichier
principal (Application.la) quasiment jusqu’à la
fin du projet.
Nous n’avons pas eu à nous occuper des
interactions, des relations entre les classes du
côté serveur, ni de tout ce qui était particulier
aux CMP Beans, ce qui nous a permis de nous
concentrer sur l’architecture.
WebLang

Désavantage

A chaque modification, il faut compiler
plusieurs fichiers au lieu d’un. Cela était peu
pratique pour nous car nous devions en plus
corriger des erreurs causées par quelques bugs
de WebLang après chaque compilation.
Diagramme de collaboration
Diagramme de classes

Serveur (CMPBeans)
Machines d’états du serveur
Machine d’états du client
Topics dynamiques




Nous avons utilisé les « topics » dynamiques.
Il y a un « topic » permanent utilisé notamment
pour la communication entre le serveur et les
clients qui ne font pas encore partie d’un jeu.
Les autres « topics » sont créés et détruits à la
création et destruction de chaque partie par le
Manager. Le nom du « topic » porte le nom du
jeu auquel il est associé.
Les clients connectés à un jeu communiquent
avec le serveur en utilisant le « topic » du jeu.
Communications

Les communications sont faites par l’appel
aux fonctions (RMI) et par les « topics »
dynamiques.
Communication Serveur-Client
Le Jeu envoie les messages textes à tous
les utilisateurs du même jeu sur le topic
du jeu.
 Le format de message est :



MSG := CODE USERNAME {PARAMS}
Le Player reçoit grâce à un « listener » :

receiverFromAListener
et transmet les ordres à exécuter selon le
message à la GUI.
Communication Client-Serveur
Le Player communique avec le serveur par
RMI (Remote Method Invocation) en
faisant appel à la fonction « action » de
« Game »
 Le format de cette fonction est:


void action(String username, int code, String params)



username
::=
code
params
::=
::=
nom de l’utilisateur qui a exécuté
l’action
code de l’action
paramètres de l’action, séparés
par des espaces
Communication Player - GUI
Player fait appel à différentes méthodes de
PlayerGUI, en utilisant « invokeLater »
pour assurer l’exécution dans l’ordre
donné.
 PlayerGUI fait appel à la fonction
« action » de Player :



action(String source)
source ::= indique l’action exécutée sur la
GUI par l’utilisateur (générée par
les « listeners »).
Conclusion

Ce projet nous a permis d’approfondir nos
connaissances sur les sujets suivants :









JMS(Topiques, Queues, etc. )
JBoss
J2EE (CMP Beans, MDBs, etc.)
Weblang
Interfaçage graphique avec Swing/AWT
Eclipse (gestion de projets, plugins)
Le travail en groupe
Représentation formelle de l’architecture d’application
(Diagramme des classes, diagramme de
collaboration, etc.)
Les règles de Monopoly (certains membres de
l’équipe n’ayant jamais joué à ce jeu) :)