POLYPOLYPROJET 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) :)