PROJET DE GENIE LOGICIEL 2005 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 Serveur Player.java Client (Player + GUI) Manager.java 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 ::= nom de l’utilisateur qui a exécuté l’action code ::= code de l’action params ::= 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) :)