Rapport Madviworld

Dpartement dInformatique Universit de Fribourg - Suisse
MADVIWORLD : ETUDE DU FRAMEWORK ET CRATION DUN GUIDE DU PROGRAMMEUR DOBJETS

Fabrice Marchon
fabrice.marchon@unifr.ch
Travail de Diplme en Informatique Superviseur : Prof. Jacques Pasquier-Rocha
Septembre 2002
Dpartement dInformatique Universit de Fribourg Rue Faucigny 2 CH-1700 Fribourg
Tl. : +41 26 300 83 22 Fax : +41 26 300 97 26 http://www.unifr.ch/informatics/
Table des Matires

1 Introduction............................................................................................................................................. 4 1.1 Prsentation du travail....................................................................................................................... 4 1.2 Objectif du travail .............................................................................................................................. 4 1.3 Structure du document ....................................................................................................................... 4 1.4 Conventions........................................................................................................................................ 5 2 MaDViWorld........................................................................................................................................... 6 2.1 Introduction MaDViWorld .............................................................................................................. 6 2.1.1 Prsentation de MaDViWorld..................................................................................................... 6 2.1.2 Concept dobjet ........................................................................................................................... 6 2.2 Architecture........................................................................................................................................ 7 2.2.1 Applications ................................................................................................................................ 8 2.2.2 Layers.......................................................................................................................................... 9 2.3 Packages .......................................................................................................................................... 10 2.3.1 Package myobj ........................................................................................................................ 10 2.3.2 Package event ........................................................................................................................ 14 3 Objets dvelopps pour MaDViWorld................................................................................................ 16 3.1 Dmineur.......................................................................................................................................... 16 3.1.1 But............................................................................................................................................. 16 3.1.2 Structure .................................................................................................................................... 16 3.1.3 Bilan.......................................................................................................................................... 18 3.2 Bataille navale ................................................................................................................................. 19 3.2.1 But............................................................................................................................................. 19 3.2.2 Structure .................................................................................................................................... 20 3.2.3 Bilan.......................................................................................................................................... 22 4 Guide du programmeur dobjets MaDViWorld ................................................................................ 24 4.1 Objectifs ........................................................................................................................................... 24 4.2 Design du guide ............................................................................................................................... 24 4.2.1 Convivialit et accessibilit....................................................................................................... 25 4.2.2 Conception ................................................................................................................................ 25 4.2.3 Navigation................................................................................................................................. 28 4.3 Programmation du site..................................................................................................................... 30 4.3.1 Structure du site......................................................................................................................... 30 4.3.2 Avantages.................................................................................................................................. 31 4.3.3 Technologies ............................................................................................................................. 31 4.3.4 Tests de compatibilit ............................................................................................................... 33 4.4 Bilan................................................................................................................................................. 35 5 Conclusion ............................................................................................................................................. 36 5.1 Bilan du travail ................................................................................................................................ 36 5.1.1 Ralisation................................................................................................................................. 36 5.1.2 Amliorations............................................................................................................................ 36 5.2 Critique du framework ..................................................................................................................... 37 5.2.1 Points forts ................................................................................................................................ 37 5.2.2 Extensions souhaitables ............................................................................................................ 37 Rfrences................................................................................................................................................. 39
1 Introduction
Appendice A : Software et Hardware .................................................................................................... 40 Software ................................................................................................................................................. 40 Programmation dobjets ..................................................................................................................... 40 Programmation du site ....................................................................................................................... 40 Hardware ............................................................................................................................................... 40 Appendice B : Guide dinstallation et dutilisation ............................................................................... 41 Guide dinstallation ............................................................................................................................... 41 Guide dutilisation ................................................................................................................................. 42 Appendice C : Version imprimable du "MaDViWorld Object Programmers Guide" .................... 44 1 Introduction......................................................................................................................................... 46 1.1 The Research Group..................................................................................................................... 46 1.2 About MaDViWorld .................................................................................................................... 46 1.3 About this Guide .......................................................................................................................... 46 2 Objects ................................................................................................................................................ 48 2.1 The Whole Context ...................................................................................................................... 48 2.2 Object Package............................................................................................................................. 50 3 Tutorial ............................................................................................................................................... 57 3.1 The HelloWorld Example ............................................................................................................ 57 3.2 The WhiteBoard Example............................................................................................................ 61 3.3 The WhiteBoard 2 Example......................................................................................................... 69 3.4 Other Objects ............................................................................................................................... 74 3.5 Summary ...................................................................................................................................... 78 Bibliography .......................................................................................................................................... 80 MaDViWorld official papers ............................................................................................................. 80 Java and RMI ..................................................................................................................................... 80 Design Patterns .................................................................................................................................. 80 Appendice D : Site internet du travail.................................................................................................... 81 Appendice E : CD-Rom ........................................................................................................................... 82
1 Introduction
1 INTRODUCTION
Le chapitre 1 sert dintroduction au prsent document. Il prsente tout dabord le cadre du travail, puis en expose les objectifs. Finalement, il dcrit la structure du document et les conventions utilises.
1.1 Prsentation du travail

Le projet MaDViWorld est dvelopp au sein du groupe de recherche Software Engineering du Dpartement dInformatique de lUniversit de Fribourg (cf. http://diuf.unifr.ch/softeng/). Il sagit dune architecture logicielle destine accueillir des systmes de mondes virtuels massivement distribus. Le software framework MaDViWorld est bas sur le modle client-serveur avec la particularit de ninclure aucun serveur centralis ; en effet, le ct serveur peut tre rparti sur un nombre arbitraire de machines. Chacune delles est connecte aux autres laide dinternet et hberge une partie du monde virtuel, de la mme manire que des serveurs http. Brivement, dans le contexte des mondes virtuels, de multiples utilisateurs et objets actifs interagissent dans le mme espace. Ils sinfluencent directement les uns et les autres. Si un utilisateur apporte quelque modification au monde virtuel, les autres utilisateurs prsents dans le mme sous-espace (cest--dire dans la mme pice) en sont immdiatement avertis.
1.2 Objectif du travail

Lobjectif de ce travail est ddoubl de la manire suivante : Dans un premier temps, programmer deux objets pour MaDViWorld afin de simprgner de lutilisation du framework. Dans un second temps, fort de lexprience acquise, concevoir et raliser le guide du programmeur dobjets. Ainsi, le guide devra prsenter le software framework MaDViWorld, son architecture et le concept dobjet tel quil est conu dans MaDViWorld. Ensuite, le guide devra galement inclure un tutorial de programmation laide dexemples dobjets concrets. Enfin, la forme du guide sera celle dun site internet convivial, rdig en anglais pour toucher un maximum de public.
1.3 Structure du document

Le prsent document est dcompos comme suit : Le premier chapitre introduit ce travail et en donne les objectifs. Il fournit galement les informations relatives la structure et aux conventions de ce document.
1 Introduction
Le deuxime chapitre prsente brivement le projet MaDViWorld qui est le support de ce travail. Les diffrentes sections de ce chapitre abordent les caractristiques du projet, son architecture, ses applications, ses couches et ses principales composantes. Dans le troisime chapitre sont exposs les objets qui ont t dvelopps pour MaDViWorld dans le cadre de ce travail. Il sagit des clbres jeux Dmineur et Bataille Navale. Le quatrime chapitre aborde la partie du travail consacre au guide du programmeur dobjets MaDViWorld. Il prsente tout dabord les objectifs du guide, puis son design, et enfin la programmation du site internet et ses outils. La conclusion et les perspectives de ce travail se trouvent dans le cinquime chapitre. Lappendice A renferme toutes les informations relatives aux logiciels, aux programmes et aux outils qui ont t utiliss, ainsi que les configurations des machines de dveloppement et de tests. Lappendice B explique comment installer et utiliser le framework MaDViWorld et ses applications. Lappendice C contient la version imprimable du guide du programmeur dobjets MaDViWorld. Le site internet de ce travail est prsent dans lappendice D. Lappendice E indique le contenu du CD-Rom fourni en annexe de ce document.
1.4 Conventions
Ce document est divis en chapitres, qui eux-mmes peuvent tre diviss en sections, voire en sous-sections. Les diffrentes figures sont numrotes lintrieur de chaque chapitre. Par exemple, une rfrence la Figure j du chapitre i sera note Figure i.j. La bibliographie est classe par ordre alphabtique du nom de lauteur ou de lorganisation. A lintrieur du texte, les mots importants sont en gras ou en italique. La police Letter Gothic MT est utilise pour les liens hypertextes, les noms de classes, de packages et de rpertoires.
2 MaDViWorld
2 MADVIWORLD
Le chapitre 2 est entirement ddi au projet MaDViWorld. Tout dabord, il prsente le projet dans sa globalit, puis expose son architecture, ses applications et ses couches, et termine en dvoilant quelques-uns des packages qui composent le framework logiciel.
2.1 Introduction MaDViWorld

Le projet MaDViWorld est dvelopp au sein du groupe de recherche Software Engineering du Dpartement dInformatique de lUniversit de Fribourg (cf. [2]). Les domaines de recherche de ce groupe sont la programmation distribue oriente objet, les mondes virtuels, la programmation de composants ractifs et la scurit dans des environnements Java et Jini.
2.1.1 Prsentation de MaDViWorld

MaDViWorld est lacronyme pour Massive Distributed Virtual World. Il sagit dune architecture logicielle destine accueillir des systmes de mondes virtuels massivement distribus. Ce framework est bas sur le modle client-serveur avec la particularit de ninclure aucun serveur centralis ; en effet, le ct serveur peut tre rparti sur un nombre arbitraire de machines. Un monde virtuel est compos de pices et dobjets actifs distribus sur diverses machines, qui vont hberger chacune une application serveur. Les pices peuvent tre interconnectes entre elles par lintermdiaire de simples portes et elles sont capables dtre peuples avec des objets. Puis, les utilisateurs sont reprsents par des avatars au travers dune application cliente. Ces avatars possdent la capacit de visiter les pices et dinteragir avec les objets contenus dans celles-ci, ainsi quavec les autres avatars se trouvant dans la mme pice au mme moment. Une terminologie plus dtaille est prsent dans [6]. Le software framework MaDViWorld est dvelopp laide du langage de programmation Java (cf. [3] et [4]) de Sun MicroSystems, dans la version 1.4. De plus, il tire normment parti des technologies RMI (cf. [8] et [9]) et Jini (cf. [10] et [13]). Pour de plus amples informations, le lecteur peut consulter la documentation officielle du projet MaDViWorld dans [2], [5], [6] et [7].
2.1.2 Concept dobjet

Il est important de prciser le concept dobjet tel quil est prsent et interprt au sein de MaDViWorld. Dans le contexte des mondes virtuels, la dfinition dun objet ne se restreint pas une chose qui peut tre seulement manipule. Il existe plusieurs sortes dobjets : certains sont passifs, cest--dire quils peuvent tre modifis par linteraction humaine, plus prcisment par linteraction dun avatar ; certains sont ractifs, parce quils changent lorsque dautres objets
2 MaDViWorld
changent ; dautres sont encore actifs, car ils ont la capacit de se transformer eux-mmes. Le software framework MaDViWorld accepte ces trois catgories dobjets. De plus, comme un monde virtuel est rparti sur une multitude de machines, il est logique quun objet donn puisse tre transport dune pice de la machine A vers une pice de la machine B. De la sorte, comme dans le monde rel, les objets sont galement mobiles, sans tre statiques ou rattachs une unique pice. Un avatar ne dplace pas seulement des objets, mais il peut galement les copier (cloner) avec toutes leurs proprits. En effet, certains objets sont dots dun tat interne qui peut tre sauvegard et restaur, par exemple en cas de "crash" de la machine qui hberge la pice qui les contient. Les objets ont encore la possibilit dtre excuts soit sur la machine distante o ils se trouvent, soit sur la machine locale de lutilisateur. La dernire caractristique est quun utilisateur interagit avec lobjet au moyen dun GUI (Graphical User Interface) simple ou sophistiqu. Cette interface graphique est toujours excute du ct client, sur sa machine locale qui hberge une application cliente. Le mcanisme de tlchargement du code vers la machine de lutilisateur est entirement automatis et gr par le framework MaDViWorld lui-mme.
2.2 Architecture
Le framework MaDViWorld est compos de 10 packages qui contient toutes les classes ncessaires aux diffrentes composantes de MaDViWorld afin de crer, grer et utiliser un monde virtuel. Au total, cela reprsente plus de 100 classes et plus de 14'000 lignes de code source Java. Si lon considre encore les objets dj disponibles, le nombre de classes slve plus de 200 et le tout totalise plus de 37'000 lignes de code. Afin davoir une meilleure ide et un meilleur aperu du projet, la Figure 2.1 rsume larchitecture globale du framework MaDViWorld. Les divers blocs qui le composent sont spars par des lignes blanches et leurs rles sont illustrs par diffrentes couleurs.
2 MaDViWorld
core
avatar
room wobject util event
Default avatar
Default room
Avatar
Room
Object
Framework packages
Default Implementation packages Specific Implementation packages
Figure 2.1: Architecture du projet MaDViWorld (cf. [7])
2.2.1 Applications
Si les blocs de la Figure 2.1 sont dcomposs verticalement, cest--dire, de gauche droite, les trois premires sparations correspondent respectivement aux trois applications indpendantes du software framework MaDViWorld : client application, room server application et room setup utility. Le package event est abord dans la sous-section 2.3.2. Quant au package restant util, il met disposition des classes utilitaires que le framework utilise et qui grent des aspects de plus bas niveau (transfert de classes, administration du rseau, etc.). Si le lecteur dsire avoir plus de dtails sur les applications de MaDViWorld, il les trouvera dans [5] et [6].
"Client application"
Cette application reprsente lutilisateur sous forme davatar afin de lui permettre de visiter le monde virtuel et ses sous-espaces : les pices. Elle lui confre galement la possibilit dinteragir avec les objets contenus dans celles-ci (les excuter, les copier, les dplacer, ), ainsi quavec les autres avatars (leur parler, les voir, ). De plus, elle est excute localement, sur la machine de lutilisateur. Pour se connecter une pice, elle requiert simplement les coordonnes de celle-ci, savoir ladresse IP de la machine qui hberge la pice et son nom. Dans la prochaine version du framework, les avatars pourront galement faire des recherches de pices par critres. Par exemple, trouver toutes les pices qui sappellent donjon ou toutes les pices qui sont destines des jeux.
2 MaDViWorld
"Room server application"

Comme le monde virtuel est constitu de pices, il faut bien les hberger : cest le rle de cette application, qui recueille et gre les pices dune partie du monde virtuel sur une machine donne. Cette application offre de surcrot un systme de persistance qui, en cas de "crash" de la machine, permet de reconstituer les pices et leurs objets.
"Room setup utility"

Cette simple application permet lutilisateur de crer et dadministrer des pices sur nimporte quelle machine, locale ou distante, qui excute lapplication room server. Cet utilitaire est aussi intitul room wizard. Elle contient les classes ncessaires la cration dobjets en vue de peupler les pices. Ainsi, elle offre la possibilit dintroduire de nouveaux objets dans une pice pendant la phase de cration de cette dernire.
2.2.2 Layers
Si lon considre la Figure 2.1 horizontalement, il en ressort trois niveaux hirarchiques qui sont respectivement de haut en bas : specification layer, system implementation layer et specific implementation layer. Chaque niveau hirarchique possde son propre rle et sa propre fonction au sein du software framework. Si le lecteur dsire avoir de plus amples informations sur les niveaux hirarchiques du framework MaDViWorld, il les trouvera dans [5] et [6].
"Specification layer"
Le specification layer est reprsent par le package core1 de la partie suprieure de la Figure 2.1. Il est commun aux trois applications, car il en dfinit le protocole de communication entre ces composantes. En effet, les classes de ce package renferment toutes les rgles (et plus particulirement toutes les interfaces) que doivent respecter les applications cliente, room server et room wizard dans le but de communiquer correctement entre elles. Idalement, le package core reprsente le protocole abstrait minimal implmenter afin de constituer un monde virtuel compatible avec MaDViWorld.
"System implementation layer"

Le niveau situ au milieu de la Figure 2.1 contient des classes abstraites et des packages dimplmentation par dfaut du framework. Le system implementation layer est divis en trois parties, une pour chaque application. En fait, les composantes de ce niveau hirarchique symbolisent lensemble basique des rgles pour chaque implmentation spcifique dune application : le package avatar pour lapplication cliente, le package room pour room server et le package wobject pour room wizard. Les applications cliente et room server sont dotes en plus dune implmentation par dfaut.
ch.unifr.madviworld
Pour des raisons de lisibilit et de simplification, dans la suite de ce document, le prfixe sera omis dans les noms du packages du framework. 9
2 MaDViWorld
"Specific implementation layer"

Le troisime et dernier niveau de la Figure 2.1 correspond limplmentation concrte, o se trouvent toutes les classes spcifiques dune application ; le lecteur remarque nouveau quil y a un package pour chaque application. Cette implmentation spcifique est une implmentation possible parmi beaucoup dautres, parce que cette partie du framework MaDViWorld est totalement libre. Nimporte quel dveloppeur peut proposer une implmentation relle ce niveau si cette dernire respecte les contraintes du framework. Par exemple, une direction peut tre denrichir le monde virtuel laide de nouveaux objets actifs. Pour ce faire, il suffit de fournir les implmentations appropries du package wobject (voir la sous-section 2.3.1) et dutiliser les applications par dfaut du framework. Il est tout fait intelligible doffrir une version plus riche et meilleure des applications cliente et room server soit en tendant les implmentations par dfaut dj existantes, soit en crant une nouvelle implmentation qui hrite des classes du framework, voire les deux en mme temps.
2.3 Packages
Aprs que la section prcdente a prsent larchitecture gnrale du MaDViWorld, ses applications et ses niveaux hirarchiques, cette section expose plus en dtails deux package essentiels du framework, savoir les packages myobj, implmentation concrte de nouveaux objets, et event, qui offre tout le mcanisme dvnements.
2.3.1 Package myobj

Si un programmeur souhaite peupler le monde virtuel avec de nouveaux objets, il doit tre en mesure de le faire en utilisant simplement une technologie standard et en respectant un ensemble minimal de rgles. Evidemment, le processus de cration dun objet doit rester trs simple et le moins contraignant que possible. En voici grossirement la solution : Utiliser le langage de programmation Java et les classes du framework MaDViWorld; Possder un ensemble de rgles afin de crer un objet compatible avec MaDViWorld, ensemble qui est reprsent par le package wobject; Crer pour le nouvel objet un nouveau package qui hrite du package wobject.
Lappendice C contient le guide qui explique "pas par pas" les diffrentes tapes. Sa version en ligne se trouve dans [2]. Nanmoins, reprenons brivement les principaux concepts impliqus. La cration du package dun nouvel objet MaDViWorld doit se raliser selon certaines conditions et certaines contraintes. Examinons le cas de la cration dun hypothtique objet intitul myobj. La Figure 2.2 prsente un aperu du package myobj. Ce package est un simple package Java qui doit respecter la structure interne du framework MaDViWorld : wobject.myobj.
10
2 MaDViWorld
Ce package contient: Une interface appele MyObj, Un package myobj.impl, qui correspond la partie dimplmentation, Un package myobj.gui, qui correspond la partie GUI.
interface java.rmi.Remote
ch.unifr.diuf.madviworld.core ch.unifr.diuf.madviworld.event
RemoteEvent interface WObjectGUI interface WObject
framework classes
ch.unifr.diuf.madviworld.wobject
interface RemoteEventListener +notify(in theEvent : RemoteEvent) : void WObjectGUIImpl +initComponents() : void WObjectImpl
ch.unifr.diuf.madviworld.wobjects.myobj
interface MyObj
ch.unifr.diuf.madviworld.wobjects.myobj.gui
1 MyObjGUIImpl 1
ch.unifr.diuf.madviworld.wobjects.myobj.impl
implementation classes
+initComponents() : void MyObjRemoteEventListener 1 1 +notify(in theEvent : RemoteEvent) : void MyObjPanel MyObjRemoteEventListener +notify(in theEvent : RemoteEvent) : void MyObjImpl
java.rmi.server.UnicastRemoteObject
javax.swing.JPanel
Figure 2.2:Aperu du package myobj (cf. [7])
Cette dcomposition nest pas accidentelle, car elle reprsente la solution la plus approprie afin de remplir toutes les caractristiques que le projet MaDViWorld propose pour un objet. En fait, comme les objets peuvent tre excuts localement ou distance, la partie dimplmentation sexcute respectivement soit sur la machine locale de lutilisateur, soit sur la machine o est excut le room server. Dautre part, lapplication cliente transfre toujours la partie GUI sur sa machine et lexcute localement. Telle est la raison pour laquelle les parties implmentation et GUI dun objet ne peuvent tre regroupes. Elles doivent tre spares dans deux diffrents packages.
11
2 MaDViWorld
ch.unifr.diuf.madviworld.core
interface WObject
framework classes
WObjectImpl
interface MyObj
MyObjRemoteEventListener +notify(in theEvent : RemoteEvent) : void
MyObjImpl
Figure 2.3:Aperu de linterface MyObj et du package myobj.impl
Interface MyObj
Comme le montrent les Figures 2.2 et 2.3, linterface wobject.myobj.MyObj hrite des interfaces java.rmi.Remote et core.WObject. Linterface MyObj a pour dessein de dclarer des mthodes qui doivent tre implmentes par le package wobject.myobj.impl, et plus particulirement par la classe wobject.myobj.impl.MyObjImpl. La partie GUI peut invoquer ds lors ces mthodes de la partie implmentation au travers de linterface MyObj. Ces mthodes peuvent tre assimiles des fonctionnalits que propose la partie dimplmentation.
Package myobj.impl
Ce package est essentiellement constitu de la classe MyObjImpl qui implmente linterface MyObj. Cette classe doit fournir une implmentation concrte pour toutes les mthodes
12
2 MaDViWorld
dclares par linterface. De plus, cette mme classe hrite de la classe WObjectImpl, qui implmente linterface WObject du package core. La Figure 2.3 prsente un zoom sur linterface MyObj et le package myobj.impl par rapport la Figure 2.2. Tout le traitement (cest--dire tous les calculs, tous les tests, toutes les donnes) est ralis au sein de la partie dimplmentation, au cur du package myobj.impl. Ainsi, lexcution de la partie dimplmentation se droule soit sur la machine qui hberge la pice et son objet, soit sur la machine locale de lutilisateur sil le souhaite. Le lecteur peut remarquer sur la Figure 2.2 que le package myobj.impl contient encore une classe appele MyObjRemoteEventListener. Cette dernire est utilise lorsque lobjet souhaite tre inform dvnements provenant de la pice qui le contient. Cela est plus amplement expliqu dans la sous-section suivante 2.3.2.
ch.unifr.diuf.madviworld.event
interface RemoteEventListener +notify(in theEvent : RemoteEvent) : void
framework classes
WObjectGUIImpl +initComponents() : void
ch.unifr.diuf.madviworld.wobjects.myobj ch.unifr.diuf.madviworld.wobjects.myobj.gui
1 1 MyObjGUIImpl +initComponents() : void 1 1 MyObjPanel
javax.swing.JPanel
Figure 2.4: Aperu du package myobj.gui
Package myobj.gui
Ce package correspond la partie GUI (Graphical User Interface) dun objet. Il faut rappeler que lutilisateur contrle chaque objet laide de son GUI. Ainsi, la partie GUI est responsable de procurer linteractivit avec lavatar. Le package myobj.gui est illustr par la Figure 2.4.
13
2 MaDViWorld
La premire classe qui compose ce package est la classe MyObjGUIImpl qui hrite de WObjectGUIImpl du package wobject (qui implmente linterface WObjectGUI de core). Cette classe instancie les classes MyObjRemoteEventListener et MyObjPanel. La classe MyObjRemoteEventListener gre les vnements destination de la partie GUI de lobjet. Cette classe est prsente plus en dtails dans la sous-section suivante 2.3.2. Linterface graphique relle et concrte se trouve dans la classe MyObjPanel qui hrite de javax.swing.JPanel, ce qui est lunique contrainte. En effet, le crateur de lobjet est tout fait libre de concevoir son GUI sa propre convenance pour autant quelle hrite de la classe JPanel. Finalement, le package myobj.gui peut inclure un rpertoire nomm resources. Ce dernier renferme tous les fichiers ncessaires au GUI : images, sons, vidos, etc. Lorsque lapplication cliente transporte dynamiquement la partie GUI dun objet de la machine room server vers la machine de lavatar, ce dossier est automatiquement transfr avec tout son contenu. Le framework MaDViWorld offre la possibilit davoir plusieurs parties GUI pour le mme objet, mais seulement une et une seule partie dimplmentation. En consquence, lintrieur du package myobj, on peut trouver plusieurs packages tels que myobj.gui, myobj.gui_2, myobj.gui_3, et ainsi de suite. Les classes de ces packages sont numrotes de la mme manire. Par exemple, le package myobj.gui_2 peut contenir les classes MyObjGUIImpl_2, MyObjPanel_2 et MyObjRemoteEventListener_2. Lapplication cliente permet lutilisateur de choisir le GUI quil souhaite utiliser lorsque plusieurs sont disposition.
2.3.2 Package event

Dans la Figure 2.1, il reste encore un package qui nappartient ni lapplication cliente, ni au room server, ni au room wizard : event. Ce package est commun aux couches system implementation et specific implementation. Il faut savoir que les vnements jouent un rle essentiel au cur du framework MaDViWorld (cf. [7]). Chaque fois que ltat dune composante du monde virtuel change, le sujet affect gnre lvnement correspondant, qui est capt par tous ceux qui sont lcoute de ce type dvnement, ce qui leur permet de ragir en fonction. Bas sur le mcanisme vnementiel de Java (cf. [4]), il offre les vnements aux objets, aux pices et aux avatars. En effet, comme le monde virtuel est rparti sur une multitude de machines, les vnements doivent tre propags et reus parmi diffrentes applications et machines. Ainsi, le software framework MaDViWorld offre son propre mcanisme vnementiel distance, son propre modle vnementiel distribu. A noter quil prsente des analogies avec le systme dvnements distribus de Jini (cf. [10]). Comme il existe une multitude dobjets, de pices et davatars dans le monde virtuel, il faut recourir une identification unique si lon souhaite adresser un vnement un lment en particulier ou seulement un certain groupe dlments. Ainsi le framework gnre un identifiant unique pour chaque objet, chaque avatar et chaque pice (cf. [7]).
Evnements et objets
Le package event est compos de plusieurs classes. Par exemple, si ce package est utilis pour la cration dun objet, il suffit au programmeur de crer une classe MyObjRemoteEventListener pour son objet myobj. Cette classe doit tendre java.rmi.server.UnicastRemoteObject et implmenter linterface
14
2 MaDViWorld
RemoteEventListener du package event. En bref, le dveloppeur dobjet cre le code qui
gre
les
vnements
que
reoit
son
objet
lintrieur
de
la
classe
MyObjRemoteEventListener.
Si la partie GUI dun objet souhaite recevoir des vnements, elle doit inclure un remote event listener (MyObjRemoteEventListener) dans son propre package. Si un objet souhaite recevoir des vnements en provenance dautres objets (communication inter-objets), il a besoin dun remote event listener2 (MyObjRemoteEventListener) dans le package de sa partie dimplmentation. Les vnements possdent des attributs qui peuvent tre nimporte quel objet Java srialisable. Ainsi, ils ont la possibilit de contenir des informations, des donnes ou tout autre chose que lobjet peut rutiliser.
Communication intra-objet
La sparation entre la partie dimplmentation dun objet et sa partie GUI ne fournit pas une communication bidirectionnelle entre les deux. La relation de clientle entre la classe MyObjGUIImpl et linterface MyObj produit un canal de communication unidirectionnel (de la partie GUI vers la partie dimplmentation), tandis que la partie dimplmentation est incapable denvoyer des informations la partie GUI correspondante. Cette lacune est comble par le modle vnementiel distribu du framework (cf. [7]). En effet, si la partie GUI dun objet peut recevoir des vnements (cest--dire quelle possde un remote event listener), la partie dimplmentation peut produire des vnements afin de lui envoyer des informations. Ainsi, une communication bidirectionnelle est tablie entre les deux parties constituantes dun objet. Les objets pourraient tre classs en quatre catgories en fonction de leur utilisation des vnements : Sans aucun vnement; Avec des vnements entre lobjet et son GUI (communication intra-objet); Avec des vnements entre des objets identiques (communication inter-objets); Avec des vnements entre lobjet et son GUI et entre des objets identiques.
Les listeners seront ensuite enregistrs auprs de producteurs dvnements (remote event producer) tels que les pices, les avatars ou les parties dimplmentation des objets. 15
3 Objets dvelopps pour MaDViWorld
3 OBJETS DVELOPPS POUR MADVIWORLD

Le prcdent chapitre a prsent le projet MaDViWorld et entre autre le package dun nouvel objet myobj. Le chapitre 3 prsente les deux objets MaDViWorld concrets qui ont t dvelopps dans le cadre de ce travail. Cest sur la base de cette exprience de programmation que doit tre ralis par la suite le guide du programmeur dobjets MaDViWorld. Les deux objets sont les jeux du dmineur et de la bataille navale. Le lecteur peut trouver dans lappendice A les outils qui ont t utiliss pour la programmation de ces deux objets.
3.1 Dmineur
Cette section prsente le premier objet qui a t programm dans le cadre de la partie de programmation de ce travail : lobjet miner, cest--dire le jeu du dmineur.
3.1.1 But
Lobjet miner reprsente une adaptation du jeu du dmineur au framework logiciel MaDViWorld. Il permet un seul avatar de jouer, mais aussi dautres avatars de regarder la partie en cours. De plus, pour grer le jeu et les avatars, il emploie le mcanisme vnementiel du framework.
Rgles du jeu
Ce jeu est destin un seul joueur, dont le but est de dcouvrir entirement une grille truffe de mines, qui y sont places alatoirement. Chaque fois que le joueur dcouvre une case, cette dernire peut contenir une mine ; si tel nest pas le cas, la case contient le nombre total de mines qui se trouvent dans son voisinage proche (cest--dire dans les huit cases qui lentourent, dans toute direction). Le joueur a la possibilit de marquer les emplacements des mines laide de drapeaux pour se souvenir de leur position. Le joueur termine la partie lorsquil russit dcouvrir toute la grille ou lorsquil tombe sur une mine.
3.1.2 Structure
Lobjet miner respecte la structure dun objet MaDViWorld telle quelle a t prsente dans la sous-section 2.3.1. Le package de lobjet porte le mme nom que lobjet, savoir miner et contient linterface Miner. En outre, les parties implmentation et GUI sont spares dans deux packages distincts, respectivement miner.impl et miner.gui.
Interface Miner
Cette interface hrite des interfaces core.WObject et java.rmi.Remote, comme sur la Figure 2.2. Elle dfinit les mthodes que la partie GUI peut invoquer partir de la partie
16
dimplmentation ; toutefois, linterface ne fait que de dclarer les mthodes sans en fournir une implmentation concrte, car cela est le rle de la partie implmentation. De plus, linterface dfinit les diffrents types dvnements qui intressent lobjet ; ces derniers sont gnrs par la partie dimplmentation et sont rcuprs par la partie GUI : RESET, GAME_STARTED, GAME_OVER et FIELD_CLICKED.
Package miner.impl
Ce package correspond la partie dimplmentation qui a la tche de grer le jeu, les avatars et lobjet. Il est uniquement compos de la classe MinerImpl qui hrite de la classe wobject.WObjectImpl. Afin de grer le droulement du jeu, la partie implmentation a recours au mcanisme vnementiel fourni par le framework (cf. 2.3.2). Les types dvnements quutilise la classe MinerImpl sont dfinis dans linterface Miner et sont :
RESET : lorsque le joueur choisit de recommencer la partie depuis le dbut; GAME_STARTED : lorsque le joueur a dbut la partie; GAME_OVER : lorsque le joueur a termin la partie;
FIELD_CLICKED : lorsque le joueur a dcouvert ou marqu une case. Comme lobjet miner naccepte quun seul avatar comme joueur, les autres avatars (qui excutent le mme objet et dans la mme pice que le joueur actif) sont automatiquement spectateurs de la partie en cours. Ils restent informs ainsi de lvolution de la partie grce aux vnements prsents ci-dessus et quils reoivent. Si le joueur quitte la partie en cours sans lavoir termine ou sans lavoir rinitialise, celle-ci reste bloque jusqu ce que le joueur revienne. En effet, la partie dimplmentation permet au joueur actif de revenir dans la partie quil a pralablement quitte, pour lui permettre de la terminer ou de la rinitialiser. La classe MinerImpl sauvegarde le moment laquelle la partie dbute et laquelle elle se termine. Ainsi, le score est affich en fin de partie dans un panneau dinformation (cf. Figure 3.2). La partie dimplmentation a la facult de sauvegarder et restaurer ltat de lobjet en cas de destruction de lobjet, de crash de la machine qui hberge la pice, etc. Ainsi, le joueur a la possibilit de commencer une partie dans la pice A, puis de dplacer lobjet de la pice A vers une pice B et enfin de terminer la partie dans la pice B. Cette aptitude est fournie par le framework MaDViWorld.
Package miner.gui
Linterface graphique de lutilisateur est dfinie dans ce package, qui contient trois classes : La classe MinerGUIImpl (qui hrite de la classe wobject.WObjectGUIImpl) sert instancier les classes MinerRemoteEventListener et MinerGamePanel. La classe MinerRemoteEventListener implmente linterface RemoteEventListener du package event et hrite de la classe java.rmi.server.UnicastRemoteObject. Elle gre les vnements destins la partie GUI de lobjet, et permet au GUI de ragir en fonction des types dvnements reus. Le vrai et concret GUI est renferm dans la classe MinerGamePanel qui hrite de la classe javax.swing.JPanel.
17
Le GUI de lobjet miner comprend deux boutons (Start et Reset), une grille de jeu, un chronomtre, un indicateur de drapeaux et un panneau dinformation. La Figure 3.1 prsente la dcomposition du GUI de lobjet miner. Le GUI nest pas simplement constitu de composantes graphiques Java ordinaires (telles que des boutons, des zones de texte), mais il recourt galement des images GIF pour dessiner les mines et les drapeaux, ce qui est illustr par la Figure 3.2. Les images mine.gif et flag.gif se trouvent dans le dossier resources du package miner.gui.
Bouton Start
Bouton Reset Grille de jeu Chronomtre
Nombre de drapeaux disposition
Panneau dinformation
Figure 3.1: Dcomposition du GUI de lobjet miner
3.1.3 Bilan
Lobjet miner, adaptation du jeu du dmineur, se rvle tre un objet concret de MaDViWorld, car il respecte sa structure et use de plusieurs fonctionnalits quoffre le framework. Voici une numration de ses principales caractristiques : Utilisation du mcanisme vnementiel afin de grer lobjet et les avatars; Sparation entre les parties implmentation et GUI; Possibilit de sauvegarder et restaurer ltat de lobjet; Jeu du dmineur pour un seul avatar (en tant que joueur) et pour les autres (en qualit de spectateurs); Possibilit pour le joueur de revenir dans une partie pralablement quitte; Chronomtre et affichage du score; Cohrence du chronomtre, mme en cas de dplacement de lobjet vers une autre pice (le joueur ne peut arrter le chronomtre lors dune partie); Marquage des mines laide de drapeaux; Utilisation dimages au format GIF.
18
Concernant cet objet, les amliorations suivantes sont possibles: Indiquer le nombre dobservateurs; Conserver dans une table les meilleurs scores des joueurs; Personnaliser du jeu (taille de la grille, nombre de mines); Dcouvrir automatiquement le voisinage dune case sans mine; Afficher une fentre daide offrant des indications sur la manire de jouer.
Case avec une mine
Case avec un drapeau
Case vide, avec 2 mines dans son voisinage
Figure 3.2: Exemple de fin de partie pour lobjet miner
3.2 Bataille navale

Cette section prsente le second objet qui a t programm dans le cadre de la partie de programmation de ce travail : lobjet battleship, cest--dire le jeu de la bataille navale.
3.2.1 But
Lobjet battleship reprsente une adaptation du jeu de la bataille navale au framework logiciel MaDViWorld. Lvolution majeure par rapport au premier objet est que cet objet est destin deux joueurs cette fois-ci. Bien sr, il permet dautres avatars de regarder la partie qui est en cours. Le mcanisme vnementiel du framework est une nouvelle fois employ pour grer le jeu et les avatars. En outre, le second objet doit proposer un GUI plus labor, plus sophistiqu que celui du premier objet.
19
Rgles du jeu
Deux joueurs saffrontent en tentant de couler la flotte de leur adversaire. Chaque joueur peut disposer son gr sur sa grille de dfense les cinq bateaux qui composent sa flotte ; il sagit dun porte-avions (dune longueur de cinq cases), dun croiseur (dune longueur de quatre cases), dun destroyer (dune longueur de trois cases), dun sous-marin (dune longueur de trois cases) et dune vedette (dune longueur de deux cases). Puis, lorsque les deux joueurs ont termin de positionner leurs navires, ils tentent chacun leur tour de toucher la flotte ennemie, cest--dire les navires sur la grille dfensive de ladversaire. Le premier joueur qui russit coul tous les bateaux de son adversaire remporte la partie.
3.2.2 Structure
Lobjet est compos du package intitul battleship, qui renferme linterface BattleShip et les packages battleship.impl et battleship.gui.
Interface BattleShip
Elle dclare les mthodes (ou les fonctionnalits) qui sont disposition de la partie GUI. Pour ce faire, elle hrite des interfaces core.WObject et java.rmi.Remote. Linterface BattleShip dfinit encore les types dvnements que peut recevoir lobjet, qui sont : RESET, GAME_INIT, GAME_STARTED, GAME_OVER et ATTACK.
Package battleship.impl
La partie dimplmentation a pour tche de grer le jeu, les avatars et lobjet. Le package battleship.impl est uniquement compos de la classe BattleShipImpl qui hrite de la classe wobject.WObjectImpl. La partie implmentation use du mcanisme vnementiel du framework (cf. 2.3.2) dans le but dinformer les joueurs et les autres avatars de ltat et du droulement de la partie. Les types dvnements quutilise la classe BattleShipImpl sont dfinis dans linterface BattleShip et sont gnrs dans les situations suivantes :
RESET: lorsque le joueur actif, qui cest le tour de jouer, choisit de rinitialiser la partie; GAME_INIT: lorsque deux avatars se sont enregistrs comme joueurs, de telle sorte que
chacun peut positionner sa flotte;

GAME_STARTED: lorsque les deux joueurs ont termin de placer leurs navires et quun des
deux peut commencer tirer sur la flotte ennemie;

GAME_OVER: lorsque le premier des deux joueurs a coul la totalit de la flotte de son
adversaire; ATTACK: lorsquun des joueurs attaque son adversaire. Chaque joueur possde ses propres grilles de dfense et dattaque. Sur la grille de dfense est dispose non seulement sa flotte, mais aussi les tentatives fructueuses ou infructueuses de son adversaire. Quant sa grille dattaque, elle contient ses propres tirs. Comme le jeu de la bataille navale n'autorise que deux avatars comme joueurs, les autres avatars (qui excutent le mme objet dans la mme pice) sont automatiquement spectateurs de la partie en cours ; en effet, ces derniers voient la grille dattaque de chaque joueur, au lieu dune grille de dfense et une grille dattaque comme laccoutum pour les joueurs.
20
Si un des joueurs (voire tous les deux) quitte la partie en cours sans lavoir termine ou sans lavoir rinitialise, celle-ci demeure bloque jusqu ce que ledit joueur revienne. Les joueurs ont la possibilit de revenir dans la partie quils ont pralablement quitte. Par contre, si un joueur (voire tous les deux) quitte la partie sans avoir termin de placer ses bateaux, il peut revenir dans la partie, mais il devra toutefois recommencer positionner ses navires depuis le dbut. La partie dimplmentation a la facult de sauvegarder et restaurer ltat de lobjet en cas de destruction de lobjet, de crash de la machine qui hberge la pice, etc. Ainsi, le joueur a la possibilit de commencer une partie dans la pice A, puis de dplacer lobjet de la pice A vers une pice B et enfin de terminer la partie dans la pice B. Cette aptitude est fournie par le framework MaDViWorld.
Package battleship.gui
Ce package contient linterface graphique de lutilisateur (GUI) et est compos des quatre classes suivantes : La classe BattleShipGUIImpl (qui hrite de la classe wobject.WObjectGUIImpl) sert instancier les classes BattleShipRemoteEventListener et BattleShipPanel. La classe BattleShipRemoteEventListener implmente linterface RemoteEventListener du package event et hrite de la classe java.rmi.server.UnicastRemoteObject. Elle gre les vnements destins la partie GUI de lobjet, et lui permet de ragir en fonction des types dvnements reus. La classe BattleShipPanel hrite de la classe javax.swing.JPanel. Elle construit le GUI de lobjet, notamment laide de la classe GridPanel.
La classe GridPanel est la composante principale du GUI, car elle contient le panneau de jeu renfermant les grilles de dfense et dattaque, ainsi que le panneau servant placer les bateaux sur la grille de dfense. Le GUI nest pas dfini dans une classe unique, mais dans deux classes distinctes : BattleShipPanel et GridPanel. En effet, comme la gestion et laffichage du panneau de jeu sont relativement longs et complexes (positionnement des bateaux, calcul des coordonnes, affichages des tirs, etc), cette partie de linterface a donc t spare dans une autre classe, afin de ne pas alourdir et allonger une classe unique. Le GUI concret est bien construit par la classe BattleShipPanel qui instancie la classe GridPanel pour crer le panneau de jeu. Sur la Figure 3.3, il est possible de distinguer les deux parties du GUI appartenant chacune une classe diffrente ; les lments en orange appartiennent la classe GridPanel, tandis que ceux en violet la classe BattleShipPanel. Revenons plus en dtail sur la dcomposition du GUI de lobjet battleship, illustre par la Figure 3.3. Les principales composantes sont les panneaux de jeu, de positionnement des navires et dattaque, qui tous sont partie intgrante de la classe GridPanel. Ces derniers utilisent des images (aux formats GIF et JPEG) aussi bien pour les boutons de placement des navires que pour dessiner les deux grilles. Il faut encore noter que les bateaux sont galement reprsents dans la grille de dfense sous forme dimages, comme le dmontre la Figure 3.4. Ensuite, le reste du GUI concerne la classe BattleShipPanel. Il sagit des boutons Start, Reset, ? (fentre daide) et About (fentre dinformation sur lobjet battleship), des labels Player 1 (nom du 1er joueur), Player 2 (nom du 2me joueur) et Observers (nombre total actuel de spectateurs), ainsi que dun panneau dinformation o sont diffuss lavatar diffrents messages. Finalement, le dernier lment du GUI est une case option intitule Sound enable.
21
Cette dernire composante est intressante, car elle permet dactiver ou de dsactiver les sons. En effet, le GUI (et plus particulirement la classe BattleShipPanel) intgre et utilise des sons pour confrer au jeu un aspect plus ludique et plus convivial. Ces derniers, comme les images, se trouvent dans le rpertoire resources du package battleship.gui et sont jous dans les situations suivantes :
Hit.wav: lorsquun tir touche un bateau; Splash.wav: lorsquun tir atterrit dans locan, sans toucher un bateau; Bomb.au: lorsquun navire est coul aprs un tir;
Gameover.mid: lorsque le jeu est termin, cest--dire quand un joueur a coul la flotte ennemie. Les joueurs ont la possibilit de revenir dans une partie quils ont pralablement quitte, ce qui inclut de rafficher les bateaux (ou plutt les images des bateaux) tels quils taient positionns dans leur grille de dfense, avant leur dpart, ainsi que les diffrents tirs effectus. Hlas, les coordonnes des images des navires ne sont pas sauvegardes lorsque le joueur quitte le jeu. Donc, il est ncessaire davoir un mcanisme de repositionnement des images par rapport aux navires dans la grille de dfense ; un tel mcanisme est inclus dans la classe GridPanel.
Panneau de placement des bateaux et dattaque
Panneau de jeu
Panneau dinformation
Bouton Start Bouton Reset Nom du 1er joueur Nom du 2me joueur Case option pour le son Nombre de spectateurs
Bouton daide Bouton dinformation
Figure 3.3: Dcomposition du GUI de lobjet battleship
3.2.3 Bilan
Lobjet battleship adapte le jeu de la bataille navale en tant quobjet concret du frameworkd MaDViWorld. Voici une numration de ses principales caractristiques : Utilisation du mcanisme vnementiel afin de grer lobjet et les avatars;
22
Sparation entre les parties implmentation et GUI; GUI complet et volu; Possibilit de sauvegarder et restaurer de ltat de lobjet; Jeu de la bataille navale pour deux avatars (en tant que joueurs) et pour les autres (en qualit de spectateurs); Possibilit pour les joueurs de revenir dans une partie pralablement quitte avec le raffichage de leurs bateaux; Affichage du nombre dobservateurs; Mise disposition dune fentre daide pour le placement des bateaux; Utilisation dimages aux formats JPEG et GIF. Utilisation de sons aux formats WAV, MID et AU.
Concernant cet objet, les amliorations suivantes sont encore possibles: Personnalisation du jeu (taille de la grille, nombre de bateaux); Ajustement du GUI la taille souhaite par lutilisateur (agrandissement ou rduction automatique du panneau de jeu et des ses images); Affichage des bateaux couls.
Porte-avions Cible actuelle Tir dans "leau"
Tir ennemi dans leau
Dernier tir ennemi
Navire "touch"
Coordonnes de la cible
Tir "touch"
Figure 3.4: Exemple dune partie pour lobjet battleship
23
4 Guide du programmeur dobjets MaDViWorld
4 GUIDE DU PROGRAMMEUR DOBJETS MADVIWORLD

Grce lexprience acquise en programmant les deux objets prsents dans le prcdent chapitre, le but principal de ce travail est la conception et la ralisation dun guide du programmeur pour des objets MaDViWorld. Le chapitre 4 prsente tout dabord les objectifs du guide, puis son design et les choix conceptuels, et enfin la programmation du site internet du guide.
4.1 Objectifs
Le guide a pour dessein dinstruire des programmeurs sur la cration dobjets compatibles avec le projet MaDViWorld. Il doit donc tre accessible pour toutes sortes de programmeurs, expriments ou non, et il se doit de prsenter clairement le projet MaDViWorld. Le guide du programmeur doit galement remplir plusieurs exigences quant son contenu, sa forme, sa lisibilit, etc.: Prsentation du projet MaDViWorld; Description du concept dobjet dans MaDViWorld; Illustration du concept dobjet avec des exemples concrets et dtaills sous forme de tutorial; Version imprimable du guide; Clart, lisibilit et efficacit du guide; Sobrit esthtique du guide; Guide lectronique, en ligne sur internet; Guide indpendant du type de navigateur; Accessibilit du guide; Rdaction du guide en anglais.
Toutes ces exigences dterminent laudience, le contenu, la fonctionnalit, le design et la mise en page du guide et de son site, de telle sorte quelles vont influencer les choix et dcisions qui interviennent dans la conception et la ralisation du guide.
4.2 Design du guide

Afin de raliser lobjectif du guide et den remplir les exigences, il nexiste pas une mthodologie bien dfinie et tablie, mais une multitude qui peuvent tre complmentaires ou
24
opposes. Comme il est impossible de toutes les satisfaire, il sagit de faire les choix les plus pertinents et les plus appropris en vue de la ralisation du guide du programmeur dobjets. Diverses mthodologies et considrations pour la cration dun site internet sont prsentes dans [1], [11], [12] et [18].
4.2.1 Convivialit et accessibilit

Le guide du programmeur dobjets MaDViWorld est destin une large audience et de ce fait il doit tre accessible par tous. Une dfinition de laccessibilit du contenu dun site ainsi que des techniques associes se trouvent dans [15], [17] et [18]. Voici en rsum les primordiaux critres : Dabord, le guide doit supporter tout type de navigateur, rcent ou moins rcent, avec ou sans cadres, avec ou sans images, etc. Donc, il faut que le guide soit semblable en contenu et en forme malgr le type du navigateur utilis. Ensuite, le site doit tre lisible indpendamment des polices et des tailles utilises sur les machines des internautes. Par exemple, les units de mesures changent dun systme dexploitation lautre. Donc, il est important de recourir des units de mesure et des polices standard aux diffrentes plate-formes. Puis, le site doit proposer plusieurs alternatives pour le contenu visuel. Par exemple, une image doit avoir un quivalent textuel, afin de ne pas dcourager les visiteurs qui usent dun navigateur textuel. Il est important de sparer au maximum la prsentation des pages de leur contenu. Les documents sont alors de plus petite taille, donc plus rapide daccs. La prsentation des pages est contrle laide de feuilles de style qui peuvent sappliquer pour un site entier. Il y a un gain norme de temps lorsquil sagit de faire une modification dans une feuille de style qui va affecter la prsentation de tous les documents, au lieu de modifier tous les documents les uns aprs les autres. Enfin, le site doit fournir un mcanisme de navigation clair et consistant, pour que le visiteur ait de la facilit rechercher les informations souhaites (cf. 4.2.3 Navigation).
Tous les points prsents ci-dessus peuvent tre considrs comme des exigences ou des contraintes dont il est ncessaire de tenir compte non seulement dans la conception du guide du programmeur dobjets MaDViWorld, mais surtout dans sa ralisation.
4.2.2 Conception
Tout dabord, il est ncessaire de dterminer quelle va tre lapparence gnrale du guide. Il ne faut pas oublier le fait quune page internet est la merci des logiciels et de la configuration matrielle de chaque utilisateur. Par exemple, une page peut sembler superbe sur une machine et totalement diffrente, voire mme affreuse, sur une autre. Cela est d aux fonctionnalits des navigateurs et aux prfrences de lutilisateur en ce qui concerne les polices, les couleurs, la taille, etc. Afin dassurer une visibilit adquate chaque visiteur indpendamment de sa machine et de sa configuration, il est ncessaire de dfinir des conditions dans lesquelles lutilisateur va visiter le guide.
25
Rsolution dcran
Les fentres des navigateurs peuvent tre redimensionnes dans nimporte quelle dimension, qui est seulement limite par la rsolution de lcran. Donc, la taille dcran influence videmment la visibilit dune page au travers de la rsolution quutilise linternaute. Il existe plusieurs tailles dcrans comme 15, 17, 19, 20 et 21 pouces. A ces tailles correspondent diverses rsolutions dcran, qui limitent le nombre de pixels disponibles pour laffichage ; voici les plus frquentes : 640x480, 800x600, 1024x768, 1280x1024, 1600x1200. De plus, la rsolution dcran est aussi caractrise par la carte graphique de lordinateur, plus particulirement par les possibilits techniques de cette dernire. Ainsi, une carte graphique peut proposer diffrentes rsolutions dcran. Ds lors, il faut dlimiter la partie minimale visible par lutilisateur afin de rserver au guide une surface daffichage dpourvue derreur, de distorsion, dinconsistance. Connatre la taille de lcran nest pas encore suffisant, car le systme dexploitation et le navigateur occupent une bonne part de lcran. Ainsi, la partie visible ddie laffichage du guide se restreint fortement. Il est obsolte de considrer une rsolution dcran de 640x480 pixels pour le guide, car cette dernire est largement trop troite et trop rductrice. Par contre, il parat judicieux de choisir une rsolution de 800x600 pixels comme zone minimale daffichage du guide.
Mise en page
Comme il est vident que les internautes ne se contentent actuellement pas seulement dune rsolution dcran 800x600 pixels, mais plutt 1024x768 ou suprieure, il est ncessaire de pouvoir adapter la page internet la configuration de lutilisateur. Si la mise en page dune page est fixe, il est certes plus facile den contrler le contenu et lapparence. Cependant, plus lutilisateur utilise une rsolution leve, plus il y a despaces non-utiliss et perdus. Donc, il est prfrable dajuster automatiquement les pages du site de telle manire quelles soient affiches correctement sur nimporte quel type dcran et avec nimporte quelle rsolution (pour autant que cette dernire respecte la limite infrieure de 800x600 pixels). On parle alors de pages fluides. Ainsi, le design du guide doit tre flexible pour permettre tout utilisateur de le parcourir indpendamment de son navigateur, de son cran et de sa configuration matrielle.
Frames
Obtenir une mise en page et un contenu flexible requiert lutilisation de mesures relatives pour les lments des pages, afin quils se redimensionnent proportionnellement les uns par rapport aux autres. Pour ce faire, il existe deux techniques : les tableaux et les cadres. Les tableaux permettent de crer des colonnes de texte et de diviser une page en plusieurs sections. En utilisant des mesures relatives (en loccurrence des pourcentages), les tableaux sadaptent la fentre du navigateur en garantissant que les colonnes et les lments du tableau restent proportionnels. Les cadres (en anglais frames) sont utiliss pour confrer une structure un design flexible. En effet, ils divisent la fentre du navigateur en plusieurs sous-fentres, qui peuvent afficher diffrents contenus. Ces sous-fentres peuvent tre cres laide de mesures proportionnelles pour conserver la flexibilit du site.
26
Les deux techniques sont utiles, dune part, les cadres structurent la fentre du navigateur afin de pouvoir afficher simultanment plusieurs pages ou lments, et dautre part, les tableaux structurent logiquement le contenu de chacune des pages. Lutilisation des cadres comporte les avantages suivants : Division de la fentre du navigateur pour afficher plusieurs pages; Diminution de la taille des pages; Possibilit de changer une partie de la fentre sans en changer les autres; Possibilit de faire dfiler une partie sans dplacer en mme temps les autres parties.
Bien sr, les cadres apportent les inconvnients suivants : Gestion plus difficile de la structure et des documents du site; Difficult de navigation pour certains utilisateurs; Difficult de crer un raccourci vers un document contenu lintrieur dun ensemble de cadres; Augmentation de la charge du serveur en cas de nombreuses requtes pour des documents constitus de cadres; Incompatibilit avec certains navigateurs.
Dans le but de fournir un guide agrable visiter, les cadres sont une bonne solution, mais il est ncessaire den limiter les inconvnients avec les trois propositions suivantes : 1. Le nombre de cadres contenu dans une fentre est limit trois : dabord un cadre suprieur, puis un cadre du ct gauche et enfin un cadre principal. Ainsi, la charge du serveur hbergeant le site est rduite, ce qui lui permet dassurer une vitesse optimale pour lexcution des requtes des documents. 2. Tout document affich dans la partie centrale du navigateur est rfrenc par une page unique pour permettre lutilisateur de crer un raccourci sur ce document. 3. Si le navigateur de lutilisateur ne supporte pas les cadres, linternaute est redirig vers une version sans cadre du document quil recherche. En ce qui concerne les trois cadres, voici une brve description de chacun : Le cadre suprieur accueille le titre du site (en loccurrence MaDViWorld Object Programmers Guide), un lien vers la page daccueil, un lien vers le plan du site (cf. 4.2.3 Plan du site), un lien permettant denvoyer un message au responsable du projet MaDViWorld et un lien permettant daccder la version imprimable du site. Ce cadre reste identique pour tous les documents du site. Le cadre de gauche est ddi la navigation et aux menus (cf. 4.2.3 Navigation). Le dernier cadre est le lieu o sont affichs les documents du site.
La Figure 4.1 prsente un aperu de la page daccueil du guide, ainsi que sa dcomposition en trois cadres.
27
Figure 4.1: Aperu de la page daccueil du site
4.2.3 Navigation
Pour visiter un site, lutilisateur a besoin dune aide visuelle, de repres pour parcourir les pages qui composent le site ; cela est ralis par les moyens de navigation qui lui sont proposs tels que des menus, des icnes, des images, des liens, des plans du site, etc. La difficult est de regrouper les pages du site en rubriques tout en respectant une logique comprhensible par les visiteurs. Ainsi, ce regroupement sous la forme de menus rend la navigation plus intuitive et facilite la recherche dinformations. De plus, il est ncessaire dinstruire lutilisateur sur les aides la navigation qui sont sa disposition pour parcourir le site ; cela est assum par la page daccueil du site comme le montre la Figure 4.1. Les aides la navigation du site sont prsents dans les trois paragraphes qui suivent.
Menus
Comme le contenu du guide est dcompos en rubriques, il est possible dy associer pour chacune un menu. De plus, comme le guide est construit hirarchiquement, cest--dire,
28
laide de chapitres, de sections et de sous-sections, il faut respecter cette hirarchisation galement dans la construction des menus du guide, afin que la navigation demeure cohrente pour lutilisateur. Les menus (et ses sous-menus) de navigation sont situs dans le ct gauche de la fentre du navigateur de telle manire tre rapidement accessible. Pour un meilleur aperu global du contenu des rubriques, toutes les sections sont galement visibles. Chaque fois que lutilisateur clique sur une section, celle-l se dveloppe et affiche les soussections qui la composent le cas chant. La Figure 4.2 prsente le cadre gauche contenant les menus de navigation ; cette figure permet galement de prsenter le contenu du guide du programmeur dobjets MaDViWorld.
Figure 4.2: Menus de navigation
Navigation interne
Pour faire gagner du temps au visiteur, chaque document du cadre central contient un systme de navigation interne. Cette dernire est constitue de diffrents liens vers les autres documents : Un lien vers le prcdent document Un lien vers le prochain document Un lien vers le haut du courant document Un lien vers la page daccueil du guide
29
De plus, les liens vers les documents suivants et prcdents sont ddoubls, une fois dans len-tte du document principal et une fois la fin du document.
Plan du site
En complment la navigation du site se trouve un plan du site qui prsente larborescence globale du site, autrement dit de son contenu. Ce plan est accessible droite du cadre suprieur sous la forme du lien hypertexte intitul Sitemap (voir Figure 4.1).
4.3 Programmation du site

Il sagit de passer la cration du guide et de son site, tout en respectant les diverses exigences de la section 4.1 et les considrations prsentes dans la section 4.2. Pour y parvenir, cette section expose tout dabord la structure du site, puis les techniques qui ont t utilises pour la programmation du site, et enfin les tests de compatibilit de divers navigateurs.
4.3.1 Structure du site

Le site est dcompos en plusieurs rpertoires contenant diverses catgories dlments. Ces rpertoires sont par ordre alphabtique : Le dossier appendices contient les pages relatives aux annexes du guide. Le dossier chapter1 contient les pages du premier chapitre du guide. Le dossier chapter2 contient celles du deuxime chapitre. Le dossier chapter3 contient celles du troisime chapitre. Le dossier code renferme le code source de chaque exemple qui est prsent dans le tutorial du guide. Les feuilles de styles utilises dans le site se situent dans le dossier css. Le dossier download possde les lments qui sont tlchargeables, tels que des objets du projet MaDViWorld (sous forme darchives Zip), un quick reference et la version imprimable du site au format PDF. Tous les documents du site se trouvent dans le dossier frames. Il sagit de toutes les informations qui sont affiches dans les trois cadres qui constituent le site. Le dossier images contient quant lui toutes les images du guide. Le dossier javadoc renferme les documentations en ligne des trois exemples du tutorial. Le dernier dossier javascript recueille tous les scripts labors pour le site.
Ainsi, la dcomposition du site en plusieurs parties permet de regrouper les lments selon leurs fonctionnalits afin den amliorer la gestion, lutilisation et la maintenance.
30
4.3.2 Avantages
Cette structure permet de rsoudre deux problmes prsents prcdemment : les raccourcis vers une page donne malgr lutilisation de frames et la gestion de navigateurs ne supportant pas les frames.
Raccourcis
Dans la section 4.2.1 et son paragraphe ddi aux frames, il a t remarqu que lutilisation de cadres dans un site internet empche le visiteur de crer un raccourci sur un document contenu dans un cadre. Cependant, les principaux navigateurs dans leurs versions les plus rcentes permettent doutrepasser cette restriction et offrent la possibilit de crer un raccourci pour tout document affich dans une page web. Malgr cela, ce nest pas le cas des navigateurs moins rcents ou de plus faible notorit. Donc, il est ncessaire de remdier ce manque afin dassurer une accessibilit totale au site, sans que lutilisateur doive passer par une mise jour de son navigateur. Ainsi, chaque document qui est affich dans le cadre central est associe sa propre page web afin de pouvoir crer un raccourci sur ledit document. Cest pourquoi dans la structure du site les pages des diffrents chapitres (les dossiers chapter1, chapter2, chapter3 et appendices) sont spares de leurs contenus (le dossier frames). En effet, cette page web renferme non seulement une rfrence vers son contenu, mais aussi des rfrences vers les menus correspondants et vers le cadre suprieur. La principale consquence de cette solution est que la gestion du site salourdit et que le nombre de requtes de pages est plus lev du ct du serveur. Cependant, cette dernire remarque est attnue par les constatations suivantes : Dune part, un tiers des requtes concerne une demande dune page internet contenant le cadre suprieur. Comme ce dernier demeure toujours identique, la page web correspondante se trouve alors dans le tampon du navigateur aprs son premier tlchargement, ce qui la rend immdiatement accessible. Dautre part, le deuxime tiers des requtes est destin obtenir la page web qui contient les menus de navigation, cest--dire le cadre situ gauche. Hors, les menus de navigations sont presque tous semblables, seuls certains menus associs une section sont susceptibles de changer. Donc, le nombre de trafic li la requte du cadre des menus naugmente que trs peu.
Cadres
La solution possde un avantage majeur dans le fait que pour chaque document il est possible den dfinir une nouvelle version nusant pas de cadres. En loccurrence, lutilisateur qui utilise un navigateur sans cadre est redirig vers le document principal, dpourvu du cadre suprieur et du cadre des menus.
4.3.3 Technologies
Cette sous-section prsente les outils, les techniques et les langages utiliss dans la phase de programmation du site. La liste des logiciels et outils qui ont t employs est disponible dans la section Software de lappendice A.
31
HTML
Le langage HTML (Hypertext Markup Language) est utilis pour crer et structurer des documents web laide de balises, ce qui permet aux navigateurs dafficher le contenu des pages internet. Comme tout langage, il existe plusieurs versions de HTML et le dernier standard dvelopp par le World Wide Web Consortium (W3C) est HTML 4.01 (cf. [16]). La principale caractristique de cette spcification par rapport aux prcdentes versions est leffort fourni afin de sparer la structure des documents de leurs prsentations. Ainsi, la mise en page des documents est confre aux feuilles de style, qui soccupent uniquement de laspect et de la prsentation des documents. La spcification HTML 4.01 est dcline en trois diffrentes versions, qui dfinissent chacune les balises, les attributs et leurs rgles dutilisation : 1. HTML 4.01 Strict Document Type Definition (DTD) exclue toutes balises et attributs obsoltes ; cette version est la plus restrictive et ne contient plus aucun lment de mise en page. 2. HTML 4.01 Transitional DTD est moins restrictive que la premire, car elle accepte les balises et attributs obsoltes, afin dassurer la compatibilit avec les navigateurs moins rcents qui ne supportent pas encore lutilisation de feuilles de style. 3. HTML 4.01 Frameset DTD est identique Transitional DTD, sauf quelle permet lutilisation de cadres (frames) dans les pages web. HTML 4.01 est le langage choisi pour programmer le guide du programmeur dobjets MaDViWorld. Ds lors, les pages requrant des cadres respectent la version Frameset DTD, tandis que toutes les autres la version Transtional DTD. Tous les documents et toutes les pages du site ont t contrles et valides comme ralisatrices de la norme HTML 4.01. La conformit HTML 4.01 est affich sur la page daccueil du site sous la forme dune image fournie par W3C, illustre par la Figure 4.3.
Figure 4.3: Standard HTML 4.01
CSS
Comme le langage HTML est utilis pour la structure des pages, il faut encore une technique qui assume la prsentation du site : les feuilles de style. Ces dernires offrent la possibilit dappliquer des styles et des instructions de mise en page pour tout lment dune page web. Lutilisation des feuilles de style procure les avantages suivants : Un plus grand contrle de la typographie et de la mise en page, tels que les polices de caractres, leur taille, leur alignement, les marges, le positionnement, etc. Sparation du style et du contenu des pages. Diminution de la taille des documents, car ils ne contiennent plus aucune information de mise en page. Maintenance du site facilite, car il est possible de lier plusieurs pages HTML une seule feuille de style.
32
La technique des feuilles de style est dfinie par le langage CSS (Cascading Style Sheets) dvelopp par W3C. La version de CSS employe dans le site est le standard CSS Level 2 (cf. [14]). Toujours dans loptique de supporter le maximum de navigateurs (aussi bien les plus rcents que les moins rcents), deux feuilles de style ont t cres et sont localises dans le rpertoire css du site : 1. Le fichier simplestyles.css contient tous les styles destins aux plus anciens navigateurs, afin doffrir une prsentation basique, claire et lisible du site. 2. Le fichier mystyles.css contient des styles plus labors dans le but damliorer la prsentation du site sur des navigateurs rcents. En outre, ces deux feuilles de styles ont t soumises avec succs au test de validit de la norme CSS Level 2 fourni par le W3C. Cette information est galement affiche sur la page daccueil du site, au ct de la validation HTML 4.01 ; la Figure 4.4 prsente limage attestant de la conformit la norme CSS.
Figure 4.4: Standard CSS
JavaScript
Le langage JavaScript est un langage de script ct client qui permet de contrler diffrents aspects des navigateurs. Par exemple, il est possible dafficher des informations supplmentaires aux liens hypertextes, de crer de nouvelles fentres ou de changer le contenu des pages. Ce langage permet entre autre de dtecter les navigateurs et leurs versions. Cette particularit est fort intressante dans le cas du guide du programmeur dobjets ; elle permet de choisir les feuilles de style appliquer pour la prsentation du site en fonction du type de navigateur quutilise linternaute. Le script dtectant le type et la version du navigateur sintitule sniffer.js et se trouve dans le dossier javascript, qui compte encore cinq autres scripts : Les scripts cssadapter.js et cssadapter2.js testent la version du navigateur et, en fonction de cette dernire, rfrencent une des deux feuilles de style. Ainsi, le navigateur utilise simplestyles.css ou mystyles.css afin de dterminer la prsentation des pages. Les scripts windowstate.js et windowfull.js soccupent douvrir une nouvelle fentre respectivement soit en prcisant les dimensions, soit en plein cran selon la taille et la rsolution dcran disponibles. Le dernier script intitul effect.js est troitement corrl une fonctionnalit propre Internet Explorer 5.5 et version suprieure ; cette fonctionnalit offre plusieurs effets de transition entre chaque page. Dans le cas de ce script, il sagit dun effet de fondu enchan o la vieille page sefface pour laisser la place la nouvelle.
4.3.4 Tests de compatibilit

Une fois le site ralis laide des technologies prsentes dans la sous-section prcdente, il faut le mettre lpreuve de nombreux navigateurs. Cest la seule manire de tester la compatibilit du site avec les navigateurs existants.
33
Pour ce faire, il est ncessaire de choisir non seulement plusieurs types et versions de navigateurs, mais aussi diverses plate-formes. Puis, les critres de compatibilit sont bass sur le support des trois techniques de programmation du site, savoir HTML 4.01, CSS et Javascript. Pour HTML 4.01 ne sont prises en compte dans le cadre des tests que les versions Transitional et Frameset qui ont t employes pour la construction du site. En effet, ces dernires assurent une compatibilit avec les navigateurs qui ne supportent pas le standard HTML 4.01 ou seulement une version antrieure. Le bilan des tests de compatibilit est positif dans la majorit des cas. En effet, la plupart des navigateurs affichent correctement les pages du site et ce avec ou sans lutilisation des feuilles de style CSS. La seule incohrence qui est survenue lors des tests est que certains navigateurs alignent quelque peu diffremment des listes puces. Il est noter que pour les navigateurs qui affichent les pages web sous forme de texte, sans cadres ou sans feuilles de style, le contenu du site demeure tout fait cohrent et comprhensible. Le tableau de la Figure 4.5 rsume les rsultats des tests de compatibilit.
Caractristiques du site Navigateur HTML Frames Javascript CSS 4.01
ok ok ok ok ok ok ok non ok ok ok ok non ok ok ok ok ok ok ok ok ok ok ok ok non ok non ok ok ok ok non ok non ok ok ok ok ok ok ok ok ok ok non ok non ok ok ok ok non ok non ok ok ok ok ok ok ok ok ok ok ok ok non ok ok ok ok non ok ok ok ok ok ok ok
Plateforme
Remarque
listes puces dplaces listes puces dplaces listes puces dplaces listes puces dplaces listes et tableaux dplacs listes puces dplaces -
Windows Internet Explorer 5.0/5.5/6.0 Netscape 4.75/4.79 Netscape 6.2/7.0 Mozilla 1.0/1.1 Opera 6.05 Amaya 6.3 1 WebTV 1.0 Build 210 Lynx 2.8.3 2 Unix Netscape 4.76 Opera 5 Mozilla 1.0 Konqueror 2.2 Lynx 2.8.1 2 Macintosh Netscape 4.79 iCab preview 2.8.1 OmniWeb 4.1 Internet Explorer 5.2 Linux Netscape 4.79 Mozilla 1.1 Konqueror 3.0
Figure 4.5: Rsultats des tests
Les configurations des machines sur lesquelles les tests ont t effectus se trouvent dans la section Hardware de lappendice A.
1 2
Navigateur ne supportant pas les cadres. Navigateur purement textuel. 34
4.4 Bilan
Le site du guide du programmeur dobjets MaDViWorld rpond aux principaux critres daccessibilit (cf. 4.2.1). En bref, il supporte tout type de navigateurs, les plus rcents comme les moins rcents : La prsentation sadapte automatiquement selon les navigateurs. La mise en page flexible que procurent les tableaux et les cadres permet dafficher le site dans nimporte quelle fentre de navigateur, pour autant quil y ait un espace de 800x600 pixels disposition. La prsentation du site est spare de son contenu grce aux feuilles de style. Ces dernires assurent une prsentation du contenu cohrente et lisible en recourant des units de mesure et des polices standard aux diffrentes plate-formes. Les trois mcanismes de navigation savoir les menus, la navigation interne et le plan du site dotent le site dune navigation claire et consistante. Le site supporte la majorit des navigateurs existants.
La version imprimable du site du guide du programmeur pour des objets MaDViWorld est disponible dans lappendice C.
35
5 Conclusion
5 CONCLUSION
Le chapitre 5 sert de conclusion ce document en dressant le bilan du travail et en prsentant les amliorations envisageables. Il contient galement une critique du software framework MaDViWorld.
5.1 Bilan du travail

5.1.1 Ralisation
Lobjectif de ce travail tait ddoubl de la manire suivante : Dans un premier temps, programmer deux objets pour MaDViWorld afin de simprgner de lutilisation du framework. Dans un second temps, fort de lexprience acquise, concevoir et raliser le guide du programmeur dobjets.
Il a t montr, tout au long de cette documentation, que les buts voqus ci-dessus ont t atteints. Tout dabord, les deux objets programms ont t des adaptations au framework MaDViWorld des jeux du dmineur et de la bataille navale. Le premier est conu pour un seul avatar, tandis que le second pour deux avatars ; cependant, tous les deux acceptent dautres avatars en qualit de spectateurs. De plus, ces deux objets respectent les caractristiques dun objet MaDViWorld: sparation des parties implmentation et GUI, sauvegarde et restauration de ltat interne de lobjet, communication intra-objet laide du mcanisme vnementiel distribu offert et utilisation de ressources diverses (images, voire mme sons). En rsum, tous deux illustrent les principales qualits que confre le framework ses objets. Le site du guide du programmeur dobjets MaDViWorld remplit entirement sa fonction en prsentant tout dabord MaDViWorld, puis son architecture, ensuite le concept dobjet au sein du projet et enfin un tutorial de programmation bas sur trois exemples concrets. De plus, le site fournit une version imprimable de son contenu et a t rdig intgralement en anglais afin de toucher un large public. Pour ce faire, il est dot dun design flexible (utilisation de cadres et de tableaux) et dun mcanisme vari daide la navigation pour le rendre convivial. En outre, sa structure est spare de sa prsentation grce l'usage du standard HTML 4.01 et des feuilles de style CSS. Ainsi, le site adapte sa prsentation et sa mise en page selon les navigateurs rcents ou moins rcents par lintermdiaire des scripts Javascript. En dautres termes, le site du guide du programmeur dobjets se rvle accessible un large public et compatible pour tout type de navigateurs.
5.1.2 Amliorations
Concernant les deux objets programms dans le cadre de ce travail, il reste encore maintes amliorations possibles, qui ont t prsentes dans le chapitre 3.
36
5 Conclusion
Le site du guide du programmeur dobjets propose accessibilit, convivialit et cohrence tel quil a t montr dans le chapitre 4. Cependant, le guide peut tre amlior sur les plans interaction et mthodologique. Une bonne ide serait dinclure quelques animations que le lecteur pourrait lancer afin de prsenter certaines caractristiques du framework ou certaines tapes du tutorial ; le site pourrait inclure des animations sous forme dapplets ou dimages animes. De la sorte, le lecteur deviendrait plus quun simple lecteur et serait plus actif.
5.2 Critique du framework

5.2.1 Points forts
Quant au framework logiciel MaDViWorld, il possde les points forts suivants: La cration dobjets est simple et peu contraignante ; il suffit de respecter un nombre restreint de rgles, comme la sparation entre le GUI et limplmentation, lobligation du GUI dhriter de la classe javax.swing.JPanel (cf. 2.3.1). Le programmeur est totalement libre de faonner les objets selon ses dsirs et ses souhaits. Le framework logiciel est extensible par le fait quun programmeur puisse non seulement crer ses propres objets, mais galement repenser lapplication cliente, voire mme dfinir de nouvelles sortes de pices. De plus, lavatar a la capacit dinteragir avec les objets et les autres avatars prsents dans la pice de manire simple et intuitive. Tout ce qui se passe derrire reste pour lui transparent. Par exemple, lorsquil veut dplacer un objet vers une autre pice, il le met dans son "sac" et change de pice. Le monde virtuel se base sur une architecture entirement distribue compose dun nombre arbitraire de machines, faisant partie aussi bien dun rseau local que dInternet et sans recourir un systme de serveur centralis. Dans ce domaine, MaDViWorld use des avantages des dernires technologies RMI et Jini. Les applications sont de leur ct peu gourmandes en ressources et ne ncessitent pas de machines ddies ou spcifiques leur utilisation. Par exemple, lapplication room server utilise le mcanisme dactivation dobjets distants fourni par RMI (cf. [3] et [9]). Un des principaux points forts de MaDViWorld rside dans son modle dvnement distribu. En effet, son mcanisme vnementiel distribu est utilisable tous les niveaux qui composent le framework logiciel, car il est non seulement simple dutilisation mais galement efficace et trs avantageux. Le framework offre encore un mcanisme de sauvegarde et de restauration automatique permettant de remdier aux ventuels "crashs" des machines hbergeant les pices. Il prsente ainsi persistance et robustesse.
5.2.2 Extensions souhaitables

Dans le but de diminuer lutilisation de la bande passante entre les machines, il serait non ngligeable de compresser les transferts de fichiers et de classes entre les diffrentes applications. Il est possible dintroduire la compression de donnes au niveau le plus bas, cest--dire les sockets en utilisant le package java.util.zip. En effet, sur Internet, plus un type de connexion utilise la bande passante disposition, plus le rseau est satur et moins
37
5 Conclusion
rapide. Il faut avoir lesprit que chaque utilisateur ne dispose pas forcment dune connexion Internet haut dbit. Un autre point amliorer est le domaine de la scurit soit pour le modle de scurit au sein du monde virtuel, soit un plus bas niveau tel que les autorisations daccs. Le recours au Secure Sockets Layer (SSL) est une possibilit pour authentifier les utilisateurs et crypter leurs donnes (cf. [9]). Limplmentation de SSL se situerait au niveau de lemploi des sockets laide du package javax.net.ssl. En restant dans loptique dune utilisation de SSL, le serveur HTTP qui transporte les classes et les fichiers entre les applications devrait tre converti en une version scurise, cest--dire un serveur HTTPS. En effet, pour linstant, les "firewalls" protgeant le rseau Internet empchent le framework dutiliser certains ports de communication des machines ; pour rsoudre ce problme, la solution la plus rpandue est la mthode "HTTP tunneling" (cf. [9]), qui consiste contourner les "firewalls" en utilisant le port traditionnel HTTP 80. Hlas, le dsavantage de cette technique rside dans le fait quil serait ncessaire de reprogrammer le serveur HTTP du framework. Cependant, comme les "firewalls" permettent laccs aux applications passant au travers de ports scuriss, la conversion du serveur en HTTPS est une solution envisageable, car elle vite de recourir la mthode "HTTP tunneling". Le software framework MaDViWorld est entirement crit en Java, langage qui offre portabilit et indpendance vis--vis des plate-formes des machines. Cependant, il serait acceptable d'autoriser au sein du monde virtuel des objets crits dans dautres langages de programmation (par exemple C++, Ada, Smalltalk) laide de larchitecture CORBA. En outre, cette technique pourrait tre applique lapplication cliente ( lavatar) en vue de fournir une reprsentation du monde virtuel en 3D.
38
Rfrences
RFRENCES
[1] [2] G. Collaud, J. Monnard, H. Platteaux, La convivialit dun site web : cl dune plus grande efficacit, Centre NTE, Universit de Fribourg, janvier 2002. Dpartement dInformatique, Universit de Fribourg (CH), Software Engineering Group, MaDViWorld : a Software Framework for Massively Distributed Virtual Worlds, http://diuf.unifr.ch/softeng/projects/madviworld/ [25 septembre 2002]. D. Flanagan, J. Farley, W. Crawford, K. Magnusson, Java Enterprise in a Nutshell, O'Reilly & Associates, 1999. D. Flanagan, J. Farley, W. Crawford, K. Magnusson, Java in a Nutshell, O'Reilly & Associates, 1999. P. Fuhrer, G. Kouadri Mostfaoui and J. Pasquier-Rocha, The MaDViWorld Software Framework for Massively Distributed Virtual Worlds: Concepts, Examples and Implementation Solutions, Department of Informatics Internal Working Paper no 01-23, University of Fribourg, Switzerland, July 2001. P. Fuhrer, G. Kouadri Mostfaoui and J. Pasquier-Rocha, MaDViWorld: a Software Framework for Massively Distributed Virtual Worlds, Software - Practice and Experience, 2002, 32:645-668. P. Fuhrer, Massively Distributed Virtual Worlds: a Framework Approach, FIDJI2002 International Workshop on scientiFic engIneering of Distributed Java applIcations, Luxembourg, November 28-29, 2002. P. Fuhrer, RMI Overview, Department of Informatics, University of Fribourg, http://diuf.unifr.ch/~fuhrer/publications/others/RMI.pdf, January 2002. W. Grosso, RMI in a Nutshell, O'Reilly & Associates, 2002.
[3] [4] [5]
[6]
[7]
[8] [9]
[10] S. Li, Professional Jini, Wrox Press Ltd.:Birmingham, 2002. [11] National Cancer Institute, Research-Based Web Guidelines, http://usability.gov/guidelines/ [25 septembre 2002]. [12] J. Niederst, Web Design in a Nutshell, Second Edition, OReilly & Associates, 2001. [13] S. Oaks, H. Wong, Jini in a Nutshell, O'Reilly & Associates, 2000. [14] W3C, CSS 2.0 Specification; http://www.w3.org/TR/REC-CSS2/ [25 septembre 2002]. [15] W3C, CSS Techniques for Web Content Accessibility Guidelines 1.0, http://www.w3.org/TR/WCAG10-CSS-TECHS/ [25 septembre 2002]. [16] W3C, HTML 4.01 Specification, http://www.w3.org/TR/html401/ [25 septembre 2002]. [17] W3C, HTML Techniques for Web Content Accessibility Guidelines 1.0, http://www.w3.org/TR/WCAG10-HTML-TECHS/ [25 septembre 2002]. [18] W3C, Web Content Accessibility Guidelines 1.0, http://www.w3.org/TR/WCAG10/ [25 septembre 2002].
39
Appendice A : Software et Hardware
APPENDICE A : SOFTWARE ET HARDWARE

Software
Programmation dobjets
SunOne CE 4, Sun MicroSystems, http://forte.sun.com [25 septembre 2002]. JDK 1.4, Sun MicroSystems, http://java.sun.com [25 septembre 2002]. Jini 1.2, Sun MicroSystems, http://wwws.sun.com/software/jini/ [25 septembre 2002]. JBuilder 5, Borland, http://www.borland.com/jbuilder/ [25 septembre 2002].
Programmation du site
UltraEdit 32, IDM Computer Solutions, http://www.ultraedit.com [25 septembre 2002]. Dreamweaver 4/MX, Macromedia,
http://www.macromedia.com/software/dreamweaver/ [25 septembre 2002].
WebEditor 5, Namo, http://www.namo.com/products/webeditor/ [25 septembre 2002]. Photoshop 5.5, Adobe, http://www.adobe.com/products/photoshop/ [25 septembre 2002]. Acrobat 5, Adobe, http://www.adobe.com/products/acrobat/ [25 septembre 2002].
Hardware
Configurations de dveloppement et de test : PC Pentium III 500 MHz, 512 Mo RAM, Microsoft Windows 98/2000. Compaq DeskPro Pentium III 650 MHz, 384 Mo RAM, Microsoft Windows NT 4. Dell Optiplex GX240 Pentium IV 1,6 GHz, 512 Mo RAM, Microsoft Windows XP Professional/Red Hat Linux 7.3. Sun Ultra 10 440 MHz, 128 Mo RAM, SunOS 5.8. Sun Blade 100 500 MHz, 512 Mo RAM, SunOS 5.8. Apple G3 400 MHz, 128 Mo RAM, Mac OS 9.2. Apple iMac PowerPC G4, 384 Mo RAM, Mac OS 10.1.5.
40
Appendice B : Guide dinstallation et dutilisation
APPENDICE B : GUIDE DINSTALLATION ET DUTILISATION

Guide dinstallation
Prrequis
Un compilateur Java pour la version 1.4.0 (ou suprieure) est requis pour la compilation des classes du framework.
Tlchargements des fichiers

Les applications peuvent tre tlcharges en [2] sous la forme darchives ZIP ; chaque fichier archive contient toutes les classes et les fichiers de lancement pour chaque application.
Extractions des fichiers

Il faut choisir un rpertoire o vont tre extraites les trois applications. Par exemple, supposons que le rpertoire dinstallation soit d:\. Aprs extraction des fichiers dans ce rpertoire, celui-ci possde la structure suivant : Le rpertoire racine de lapplication "room server" est d:\MaDViWorlds et contient un dossier MaDViWorld qui contient le package MaDViWorld et tous les sous-packages relatifs cette application; Le rpertoire racine de lapplication "avatar" est d:\MaDViWorldc et contient un dossier MaDViWorld qui contient le package MaDViWorld et tous les sous-packages relatifs lapplication cliente; Le rpertoire racine de lapplication "room wizard" est d:\MaDViWorldw et contient un dossier MaDViWorld qui contient le package MaDViWorld et tous les sous-packages relatifs cette application.
Compilation de lapplication "room server"

Dans le rpertoire racine de cette application, excuter le fichier cpws.bat.
Compilation de lapplication "avatar"

Dans le rpertoire racine de cette application, excuter le fichier cpwc.bat.
Compilation de lapplication "room wizard"

Dans le rpertoire racine de cette application, excuter le fichier cpww.bat.
41
Guide dutilisation
Prrequis
JRE 1.4 doit tre install sur la machine locale pour excuter les applications ; il peut tre tlcharg ladresse http://java.sun.com/j2se/1.4/. De plus, lapplication "room server" ncessite linstallation pralable de Jini qui est disponible ladresse http://wwws.sun.com/software/communitysource/jini/.
Excution de lapplication "room server"

1. Dans le rpertoire racine de lapplication, diter le fichier setmvwenvvar.bat. Dans ce fichier sont dfinir trois variables (cf. Figure B.1):
MVHOME dtermine le rpertoire o a t installe lapplication; JINI_HOME dtermine le rpertoire o est install Jini; HOST contient ladresse IP de la machine locale. Si cette dernire ne fait pas partie
dun rseau, ladresse IP est par dfaut 127.0.0.1 ; sinon pour trouver ladresse IP de la machine, excuter la commande ipconfig.
Figure B.1: Edition du fichier setmvenvvar.bat
2. Dans une console, excuter dans le rpertoire racine de lapplication le fichier sserver.bat (cf. Figure B.2).
42
Figure B.2: Lancement de lapplication "room server" dans une console
Excution de lapplication "avatar"

1. Dans le rpertoire racine de lapplication, diter le fichier setmvwenvvar.bat.et dfinir les trois variables locales MVHOME, JINI_HOME et HOST (cf. Figure B.1). Puis sauvegarder et fermer le fichier. 2. Excuter dans le rpertoire racine de lapplication le fichier sclient.bat.
Excution de lapplication "room wizard"

1. Dans le rpertoire racine de lapplication, diter le fichier setmvwenvvar.bat.et dfinir les trois variables locales MVHOME, JINI_HOME et HOST (cf. Figure B.1). Puis sauvegarder et fermer le fichier. 2. Dans une console, excuter dans le rpertoire racine de lapplication le fichier swizard.bat.
43
Appendice C : Version imprimable du "MaDViWorld Object Programmers Guide"
APPENDICE C : VERSION IMPRIMABLE DU "MADVIWORLD OBJECT PROGRAMMERS GUIDE"

MADVIWORLD OBJECT PROGRAMMER'S GUIDE
Fabrice Marchon September 2002 Department of Informatics - University of Fribourg - Switzerland
Table of Contents
1 Introduction........................................................................................................................................... 46 1.1 The Research Group ........................................................................................................................ 46 1.2 About MaDViWorld ......................................................................................................................... 46 1.3 About this Guide............................................................................................................................... 46 1.3.1 Purpose of the Guide................................................................................................................. 46 1.3.2 Prerequisites .............................................................................................................................. 47 1.3.3 Structure of the Guide ............................................................................................................... 47 1.3.4 Conventions .............................................................................................................................. 47 2 Objects ................................................................................................................................................... 48 2.1 The Whole Context ........................................................................................................................... 48 2.1.1 Architecture............................................................................................................................... 48 2.1.2 Applications .............................................................................................................................. 49 2.1.3 Layers........................................................................................................................................ 49 2.2 Object Package ................................................................................................................................ 50 2.2.1 Features ..................................................................................................................................... 50 2.2.2 Structure .................................................................................................................................... 51 2.2.3 Events........................................................................................................................................ 54 2.2.4 Runtime..................................................................................................................................... 55 3 Tutorial .................................................................................................................................................. 57 3.1 The HelloWorld Example................................................................................................................. 57 3.1.1 HelloWorld Goals ..................................................................................................................... 57 3.1.2 HelloWorld Interface ................................................................................................................ 58 3.1.3 HelloWorld Implementation ..................................................................................................... 58 3.1.4 HelloWorld GUI........................................................................................................................ 59 3.1.5 HelloWorld Code and Javadoc.................................................................................................. 61 3.1.6 HelloWorld Benefits ................................................................................................................. 61 3.2 The WhiteBoard Example ................................................................................................................ 61 3.2.1 WhiteBoard Goals..................................................................................................................... 61 3.2.2 WhiteBoard Interface ................................................................................................................ 62 3.2.3 WhiteBoard Implementation ..................................................................................................... 62
44

3.2.4 WhiteBoard GUI ....................................................................................................................... 64 3.2.5 WhiteBoard Code and Javadoc ................................................................................................. 69 3.2.6 WhiteBoard Benefits................................................................................................................. 69 3.3 The WhiteBoard 2 Example ............................................................................................................. 69 3.3.1 WhiteBoard 2 Goals.................................................................................................................. 69 3.3.2 WhiteBoard 2 Interface ............................................................................................................. 70 3.3.3 WhiteBoard 2 Implementation .................................................................................................. 70 3.3.4 WhiteBoard 2 GUI .................................................................................................................... 70 3.3.5 WhiteBoard 2 Code and Javadoc .............................................................................................. 74 3.3.6 WhiteBoard 2 Benefits .............................................................................................................. 74 3.4 Other Objects ................................................................................................................................... 74 3.4.1 Fibonacci................................................................................................................................... 74 3.4.2 Clock ......................................................................................................................................... 75 3.4.3 TicTacToe ................................................................................................................................. 76 3.4.4 Minesweeper ............................................................................................................................. 76 3.4.5 Tamagotchi................................................................................................................................ 77 3.4.6 BattleShip.................................................................................................................................. 78 3.5 Summary .......................................................................................................................................... 78 Bibliography ............................................................................................................................................. 80 MaDViWorld official papers.................................................................................................................. 80 Java and RMI......................................................................................................................................... 80 Design Patterns...................................................................................................................................... 80
45
1 Introduction
This document is a printable version of the site of the MaDViWorld Object Programmer's Guide. http://diuf.unifr.ch/softeng/projects/madviworld/guide
1.1 The Research Group

The developing team for the MaDViWorld project is the Software Engineering group of the Department of Informatics of the University of Fribourg, Switzerland. The research topics of this group are distributed object-oriented programming, virtual worlds, reactive components programming and security in Java/Jini environments. The group is mainly composed of Prof. Jacques Pasquier-Rocha, and of PhD students Ghita Kouadri Mostfaoui, Patrik Fuhrer and Adrian Sieber. For more information, follow the official link of the research group: http://diuf.unifr.ch/softeng/
1.2 About MaDViWorld

The MaDViWorld project is a software framework that is developed in the Software Engineering group. It represents a software architecture for supporting massively distributed virtual worlds systems. The software framework is based on a client-server model, but there is no centralized server, since the server side can be distributed on arbitrarily many machines. A virtual world is composed of rooms and active objects distributed on several machines, each running a server application. The rooms can be connected together by way of simple doors and they can be populated with objects. Then, avatars represent the users through the client's application. The latter allow for visiting the rooms and for interacting with the objects and the other users. The MaDViWorld software framework is implemented in Java (Sun JDK 1.4) and is based on RMI and Jini technologies. If the reader has more interest for the MaDViWorld project, she can consult the official papers about MaDViWorld (see [1], [2] and [3]).
1.3 About this Guide

1.3.1 Purpose of the Guide
This guide will neither discuss, nor explain, nor justify the MaDViWorld software framework. The idea of the present guide is to show programmers how to create suitable active objects for the MaDViWorld project.
46
1.3.2 Prerequisites
The reader must have some notions of o.o. programming ; Java is recommended. A full mastering of RMI and Jini is not required. It is however, suggested to check the bibliography or the links in the appendices of the website, in order to have a working comprehension for the rest of the guide.
1.3.3 Structure of the Guide

In order to fulfil its goal, the guide is divided in four main chapters: Chapter 1 serves as introduction to the guide. It presents first the research group involved in the MaDViWorld project, then the project and finally the site. Chapter 2 introduces the notion of Object within the MaDViWorld software framework. Therefore, it outlines first the entire software architecture of MaDViWorld, before focusing on its object package. The programmers' tutorial itself begins with Chapter 3, which presents three concrete examples of objects. It finishes with an overview of other MaDViWorld objects and with a summary.
1.3.4 Conventions
The following formatting conventions are used throughout the present guide: The bold and italic fonts are used for emphasis. All Java code and generally anything which would be a package, constants, method names, variables, class names and interfaces names are represented as code. The Figures that appear in the guide are numbered within each chapter. For example, Figure i of Chapter j will be Figure j.i. As far as gender is concerned, the feminine is systematically selected when possible.
47
2 Objects
As it was previously said, the MaDViWorld project is a software framework, which is not composed of a single software unit, but of several distinct parts. The section 2.1 The Whole Context gives a description of the framework global architecture. It introduces the various applications and layers within the whole context. The section 2.2 Object Package focuses then on the object package. It exposes at first the idea and the features of an object, then its internal structure, its event mechanism and, finally, its behaviour and communication process at runtime.
2.1 The Whole Context

2.1.1 Architecture
The MaDViWorld framework is a collection of about 10 packages, which contain all the classes needed by the different parts of MaDViWorld in order to set up, manage and use a virtual world. All together, it represents more than 100 classes and more than 14000 lines of Java source code. For a better idea and overview of the software framework, Figure 2.1 summarizes the software architecture of the entire MaDViWorld framework. The different packages of MaDViWorld are separated by white spaces and their roles are illustrated by different colors.
core
avatar
room wobject util event
Default avatar
Default room
Avatar
Room
Object
Framework packages
Default Implementation packages Specific Implementation packages
Figure 2.1: The MaDViWorld framework software architecture
48
By studying Figure 2.1 from the left to the right, the reader sees the independent applications of MaDViWorld. On the other hand, by analyzing it from the top to bottom, this same reader distinguishes three hierarchical layers, into which the packages are distributed.
2.1.2 Applications
The MaDViWorld software framework is divided into three independent applications: the client application the room server the room setup utility
a) The client application

This application, called avatar, allows its user to visit the virtual world and its subspaces (i.e. the rooms). It also lets its user interact with active objects of the world and with other avatars.
b) The room server application

It hosts and manages the rooms of a part of the world on a given machine.
c) The room setup utility

This simple application allows its user to create and manage rooms on any machine (local or remote) running the server application. It offers the possibility to introduce new objects in a given room during their creation phase. This utility is called the room wizard.
2.1.3 Layers
In Figure 2.1, the user distinguishes three different vertical levels: the specification layer the system implementation layer the specific implementation layer
a) The specification layer

The MaDViWorld specification layer is shown in the upper part of Figure 2.1. This layer is common to the three applications. Its classes encapsulate the conventions that each avatar, room server and room setup applications must respect in order to function and communicate with one another correctly. Ideally, it represents the minimal abstract protocol to be implemented in order to create a MaDViWorld compatible virtual world.
b) The system implementation layer

The middle section of Figure 2.1 corresponds to this layer. The reader discovers that the system implementation layer is divided into three parts, one for each application. In fact, the packages composing this layer represent the basic set of rules for each specific implementation of any application: the avatar package for the client application, the room package for the room server, and the wobject package for the room wizard.
c) The specific implementation layer

This last layer is shown in the lower part of Figure 2.1. As the reader can notice, there is one package for each application. They correspond to a concrete implementation for each application. It can be one possible implementation among many, because that part of the
49
MaDViWorld framework is totally free. Anyone can propose a real implementation of this layer if it respects the framework constraints. The object package of the specific implementation layer is further described in great details in the section 2.2 Object Package. Further information about the various layers of applications of MaDViWorld can be found by consulting the project official papers (see [1], [2] and [3]).
2.2 Object Package

The programmer who wishes to populate the world with new types of objects must be able to do so by using a standard technology and by respecting a small set of rules. Of course, the object creation process must be kept very simple and as little constraining as possible. Here is the solution: At first, she must use the Java programming language and the MaDViWorld framework classes. Then she must have at her disposition a structured set of abstract interfaces and concrete classes, that have to be implemented and inherited from in order to create a vi-world compatible object. The wobject package from the system implementation layer represents such a set. Finally, she must create a package for her new object, which must inherit of the wobject package.
2.2.1 Features
Before presenting the Object package in details it is important to spend some time exposing the concept of object in MaDViWorld. In the context of virtual worlds, the definition of an object does not limit itself to a thing that can be only manipulated. There are several types of objects; some are passive (i.e. changed through a human or better said through an avatar's interaction), some are reactive (they change when other objects have changed) and some are active (i.e. they can transform themselves). The MaDViWorld software framework allows these three categories of objects. Furthermore, as a virtual world is distributed on many machines, it is logical that a given object can be transported from a room on machine A to a room on machine B. So, an object is mobile (not static and not bound to a unique machine). An avatar does not only move objects, she can also copy (clone) them. Some objects have an internal state that can be saved and restored, for example when a new instance of an object is created. Moreover, these objects can be executed either on the remote machine where they are located or on the local machine of the user. The last feature is that an object can interact with the user through a simple or an arbitrarily sophisticated graphical user interface. The GUI is always executed on the user's side, i.e. on her local machine hosting the client application. The code downloading needed to offer this interaction to the user is done automatically and is managed by the MaDViWorld framework.
50
2.2.2 Structure
From the global software architecture of MaDViWorld shown in Figure 2.1, let's take a closer look to an object, represented by the myobj package in Figure 2.2 (it is supposed that the object name myobj has been chosen by its programmer for this new type of object). The myobj package is a sample Java package and it must just respect the internal structure of the MaDViWorld software framework as follows: madviworld.wobject.myobj.
interface java.rmi.Remote
ch.unifr.diuf.madviworld.core ch.unifr.diuf.madviworld.event
RemoteEvent interface WObjectGUI interface WObject
framework classes
interface RemoteEventListener +notify(in theEvent : RemoteEvent) : void WObjectGUIImpl +initComponents() : void WObjectImpl
interface MyObj
ch.unifr.diuf.madviworld.wobjects.myobj.gui
1 MyObjGUIImpl 1
+initComponents() : void MyObjRemoteEventListener 1 1 +notify(in theEvent : RemoteEvent) : void MyObjPanel MyObjRemoteEventListener +notify(in theEvent : RemoteEvent) : void MyObjImpl
javax.swing.JPanel
Figure 2.2: The myobj package
The myobj package contains: one interface called MyObj one package called myobj.impl, corresponding to the implementation part one package called myobj.gui, corresponding to the GUI part
This decomposition is not an accident. It represents the most appropriate solution in order to fulfil all features and requirements that the MaDViWorld framework proposes for an object. In fact, as objects can be executed locally or remotely, the implementation part runs respectively on the user's local machine or on the machine where the room server is running. On the other hand, the client application always downloads the GUI part on its machine and
51
executes it locally. This is the reason why the implementation and the GUI parts cannot be joined together. They must be separated in two different packages.
a) The MyObj interface

As shown on Figures 2.2 and 2.3, the MyObj interface inherits both from the java.rmi.Remote and from the madviworld.core.WObject interfaces. Its purpose is to provide methods that have to be implemented by the myobj.impl package, especially by the MyObjImpl class.
b) The myobj.impl package

This package is essentially composed of the MyObjImpl class that implements the MyObj interface. That class must provide a concrete implementation for all the methods of the interface. Moreover, the same class inherits from the WObjectImpl class, that itself implements the WObject interface of the madviworld.core package. Figure 2.3 represents a zoom on the MyObj interface and on the myobj.impl package of Figure 2.2. The entire processing (all the calculations, all the tests, all the data...) is done in the implementation part, inside the myobj.impl package. Note that the MyObjImpl class must invoke the constructor of its superclass with the keyword super() in its own constructor. The reader can notice on Figure 2.2 that there is another file in the myobj.impl package: MyObjRemoteEventListener. The latter is useful if the object needs to be informed of the events coming from its containing room. This is further explained in the next subsection 2.2.3 Events.
52
ch.unifr.diuf.madviworld.core
interface WObject
framework classes
WObjectImpl
interface MyObj
MyObjImpl
Figure 2.3: Zoom on the MyObj interface and on the myobj.impl package
c) The myobj.gui package

This package corresponds to the GUI part of an object. It is good to remember that the user controls each object through its GUI. So, the GUI part is responsible for providing the interaction with the avatar. The first file composing the myobj.gui package is the MyObjGUIImpl class that extends the WObjectGUIImpl from the madviworld.wobject package (the latter implements the WObjectGUI interface from the madviworld.core). The MyObjGUIImpl class has to call the keyword super() in its constructor and has to contain a method called initComponents(), where it instantiates the MyObjRemoteEventListener and the MyObjPanel classes. The MyObjRemoteEventListener class handles all the events concerning the GUI part; a new instance of it is created in the method initComponents() of the MyObjGUIImpl class . The RemoteEventListener is explained in details in the next subsection 2.2.3 Events. The concrete GUI is contained in the MyObjPanel class that extends javax.swing.JPanel.
53
Figure 2.4 illustrates the myobj.gui package. Finally, the myobj.gui package can include a folder called resources. The latter contains all the files needed for the GUI: images, sounds, videos, etc. When the client application dynamically downloads the GUI of the object from the room server machine to the avatar machine, this folder is automatically downloaded with its entire content.
ch.unifr.diuf.madviworld.event
interface RemoteEventListener +notify(in theEvent : RemoteEvent) : void
framework classes
WObjectGUIImpl +initComponents() : void
ch.unifr.diuf.madviworld.wobjects.myobj ch.unifr.diuf.madviworld.wobjects.myobj.gui
1 1 MyObjGUIImpl +initComponents() : void 1 1 MyObjPanel
javax.swing.JPanel
Figure 2.4: Overview of the myobj.gui package
The MaDViWorld framework offers the possibility to have many GUIs for the same object, but just one implementation part. So, inside the myobj package one can find several packages like myobj.gui, myobj.gui_2, myobj.gui_3, and so on. The classes are numbered with the same scheme. For example, inside the package myobj.gui_2, there would be the classes MyObjGUIImpl_2, MyObjPanel_2 and MyObjRemoteEventListener_2. The client application allows the user to choose a GUI for an object when there are many of them.
2.2.3 Events
In Figure 2.1, there is a package that does not belong to the client application, neither to the room server application, nor to the room setup utility, but it is common to the system implementation and specific implementation layers: the madviworld.event package. Based on the Java event mechanism (see [4]), it offers events for objects, avatars and rooms. As the virtual world is distributed on many machines, the events must be fired or caught
54
between the different applications. Thus MaDViWorld offers its own remote event mechanism (see [3]). The madviworld.event package is composed of several classes, but in order to use it, the programmer must just create a MyObjRemoteEventListener class for her object MyObj. The class has to extend java.rmi.server.UnicastRemoteObject and to implement the RemoteEventListener interface from the madviworld.event package. Within MyObjRemoteEventListener, the programmer creates the rest of the code where she manages the events for her object. If a GUI part is interested in any event, it must have a remote event listener (MyObjRemoteEventListener) inside its own package. If an object must listen to events from other objects, it needs a remote event listener (MyObjRemoteEventListener) within its implementation part. Moreover, events can contain some information, some data or anything else that the programmer can reuse later. Thus, events have attributes that can be any serializable java object. With regard to the events, there are four possible kinds of objects: without event with events between the object and its GUI with events between similar objects with events between similar objects and between the object and its GUI
2.2.4 Runtime
When the user wants to create a room and an object on a running room server, she uses the room setup utility. That step done, she can enter the room with the client application and launch the object. At this stage, two ways of execution are possible: local: the client application downloads the entire object package on the user's machine. Thus, the implementation and GUI parts run on her machine.
remote: the client application downloads only the GUI part of the object and runs it on the user's machine. On the other side, the implementation part of the object runs on the machine that hosts the room. Although the GUI and the implementation parts are either on the same computer or distant from each other, they can always communicate with one another as it is shown in Figure 2.5.
55
Figure 2.5: Communication between the GUI and the implementation parts
Figure 2.5 is further explained below: 1. The MyObjImpl from the implementation part implements the MyObj interface. 2. The GUI part can call all the methods defined in the MyObj interface. 3. The implementation part cannot communicate directly with the GUI, but if the latter can receive events (i.e. it owns a RemoteEventListener), the implementation part can produce events to send some information or some data to the GUI.
56
3 Tutorial
Chapter 2 has presented the MaDViWorld software framework and more especially the package dedicated to objects. It is time for the reader to see concrete examples of MaDViWorld objects; in other words: MaDViWorld objects by examples. The examples are composed of three objects, each illustrating different features and possibilities of the MaDViWorld object concept: First example: the classical HelloWorld that is the simplest object for MaDViWorld. Second example: a whiteboard, an object with an interface and events. Third example: a whiteboard 2, the same as above but with an additional GUI.
Other objects developed for MaDViWorld, are provided with a less extensive documentation. The examples are systematically presented in the same way in order to facilitate their assimilation by the reader, i.e.: 1. Definition of the objectives and functions of the new object. 2. Creation of an interface declaring the object functions. 3. Implementation part of the new object. 4. Design and conception of the object GUI. 5. Code and javadoc. 6. Benefits.
3.1 The HelloWorld Example

Now that the concept and the structure of a MaDViWorld object have been exposed (section 2.2 Object Package), the tutorial begins with the first concrete object, the classical HelloWorld example. At first sight, it seems to be a trivial case, but it serves well in order to illustrate some of the main benefits of the MaDViWorld framework, i.e. object mobility, separation of the implementation and the GUI...
3.1.1 HelloWorld Goals

The first goal of this example is to show a welcome message to the user through a simple window. So, it does not need to handle events or anything else. The second goal is to show the programmer the concrete structure of an object, how it is decomposed with more details than the subsection Structure of the section 2.2 Object Package. In order to fulfil these goals, a package called helloworld has to be created in the madviworld.wobject package. Then, inside this package, the impl and the gui subpackages are created to complete the structure of HelloWorld. Figure 3.2 presents the file structure of the helloworld package.
57
Figure 3.1: File structure of the helloworld package
3.1.2 HelloWorld Interface

The role of the interface is to contain methods that the GUI part can invoke on the implementation part. It finds itself directly in the helloworld folder. First, the code begins with the package declaration that it belongs to:
package ch.unifr.diuf.madviworld.wobject.helloworld;
Then, all other needed packages and interfaces must be imported:

import ch.unifr.diuf.madviworld.core.WObject; import java.rmi.RemoteException; import java.rmi.Remote;
Here is the declaration of the interface:

public interface HelloWorld extends WObject, Remote {
In the body of the interface, methods can now be declared. But before, one thing must be noticed: every method declared within the interface of an object must throw a java.rmi.RemoteException, as everything is distributed in the virtual world. For the HelloWorld example, a getText() method is declared in order to retrieve the text (as string), which will be shown to the user:
public String getText() throws RemoteException; }//end of class
3.1.3 HelloWorld Implementation

The implementation part of an object is responsible for making all calculations and the entire processing job, as well as for implementing its interface. Thus, the helloworld.impl package contains only one class: HelloWorldImpl.java. First, it begins with the package declaration that it belongs to, then with the import statement of the required packages and interfaces:
package ch.unifr.diuf.madviworld.wobject.helloworld.impl; import import import import ch.unifr.diuf.madviworld.core.WContainer; ch.unifr.diuf.madviworld.wobject.WObjectImpl; ch.unifr.diuf.madviworld.wobject.helloworld.HelloWorld; java.rmi.RemoteException;
Then, the HelloWorldImpl class must imperatively implement its HelloWorld interface:
public class HelloWorldImpl extends WObjectImpl implements HelloWorld {
58
The class has to provide a constructor without arguments in order to create new instances (the framework calls this constructor to dynamically instantiate this class). Thus, its constructor must call the constructor of its superclass (WObjectImpl) with the keyword super:
public HelloWorldImpl() throws RemoteException{ super(); this.description="A simple helloworld"; }
Moreover, the class must provide another constructor but this time with parameters, where name corresponds to the name of the instance, host to the name of the hosting machine, and container to the container of the object:
public HelloWorldImpl(String name,String host,WContainer container) throws RemoteException{ super(name,host,container); this.description="A simple helloworld"; }
Then, the methods of the interface must be defined. For the helloworld example, the HelloWorld interface contains the getText() method, which just returns a text as a string:
public String getText() {return "Hello the World!";} }//end of class
3.1.4 HelloWorld GUI

The GUI part consists of providing a graphical interface to the user in order to allow her some interaction with the object. The helloworld.gui package contains two classes, HelloWorldGUIImpl.java and HelloWorldPanel.java.
a) HelloWorldGUIImpl
The HelloWorldGUIImpl class is used to instantiate a graphical user interface for HelloWorldImpl. First, it begins with the package declaration that it belongs to, then with the interface to import:
package ch.unifr.diuf.madviworld.wobject.helloworld.gui; import ch.unifr.diuf.madviworld.wobject.WObjectGUIImpl;
Then, the HelloWorldGUIImpl class must just extend WObjectGUIImpl (which itself extends javax.swing.JPanel):
public class HelloWorldGUIImpl extends WObjectGUIImpl {
The class has to provide a constructor, which invokes the constructor of its superclass:
public HelloWorldGUIImpl() { super(); }
Finally, there is a method called initComponents() that creates new instances of the concrete GUI and adds them to the current container. This method is invoked by the framework.
public void initComponents() content = new HelloWorldPanel(this); add (content); } }//end of class
59
b) HelloWorldPanel
The HelloWorldPanel is really containing the graphical user interface for a HelloWorldImpl. Of course, the first steps are the package declaration and the import of the necessary packages and interfaces:
package ch.unifr.diuf.madviworld.wobject.helloworld.gui; import ch.unifr.diuf.madviworld.wobject.helloworld.HelloWorld; import java.rmi.RemoteException;
Next, the HelloWorldPanel class extends javax.swing.JPanel:

public class HelloWorldPanel extends javax.swing.JPanel {
Then, two variables have to be declared for further use:

private HelloWorldGUIImpl context; private HelloWorld impl;
Of course, the constructor is obligatory and it takes as parameter a HelloWorldGUIImpl (that embeds this panel). Furthermore, within the constructor, the two variables context and impl must be initialized:
public HelloWorldPanel(HelloWorldGUIImpl c) { this.context=c; this.impl = (HelloWorld)c.getWObjectImpl(); initComponents(); }
The initComponents() method refers to the interface creation phase, i.e. the definition of the graphical user interface. The following code generates a panel that contains a text area where the welcome message is displayed to the user. It was automatically generated by the Forte IDE from Sun Microsystems:
private javax.swing.JPanel mainPanel; private javax.swing.JTextArea text; private void initComponents() { mainPanel = new javax.swing.JPanel(); text = new javax.swing.JTextArea(); setLayout(new java.awt.GridBagLayout()); java.awt.GridBagConstraints gridBagConstraints1; mainPanel.setMaximumSize(new java.awt.Dimension(310, 110)); text.setBackground(java.awt.Color.lightGray); text.setEditable(false); text.setFont(new java.awt.Font("Verdana", 1, 14)); text.setForeground(java.awt.Color.blue); text.setText(readMessage()); text.setMaximumSize(new java.awt.Dimension(300, 100)); text.setMinimumSize(new java.awt.Dimension(200, 50)); text.setPreferredSize(new java.awt.Dimension(200, 50)); mainPanel.add(text); gridBagConstraints1 = new java.awt.GridBagConstraints(); gridBagConstraints1.gridx = 0; gridBagConstraints1.gridy = 1; add(mainPanel, gridBagConstraints1); }
Another important method in the previous lines of code is:

text.setText(readMessage());
It asks the implementation part for the string, which must be displayed to the user. It cannot be done directly, but only through the interface by invoking its getText() method. The interface corresponds to the impl variable (declared of type HelloWorld):
60

private String readMessage() { String message = ""; try { message = impl.getText(); } catch (RemoteException e) {} return message; } }//end of class
The programmer has to pay attention to the try-catch clause, because the getText() method of the interface throws a java.rmi.RemoteException, that has to be handled. At this moment, the GUI is finished and looks like Figure 3.2 at runtime.
Figure 3.2: GUI of the HelloWorld example
3.1.5 HelloWorld Code and Javadoc

By following the links on the website, the programmer can find the entire source code of all the files composing the HelloWorld example and visit its javadoc.
3.1.6 HelloWorld Benefits

The HelloWorld example is the first object of the tutorial. The reader can see how an object is concretely programmed inside the MaDViWorld software framework. The GUI and implementation parts are physically distinct, which is much appropriate and well designed. Although the GUI and the implementation parts are separated, using an interface allows the GUI to invoke methods of the implementation. This first object contains a few lines of codes and it is easy to understand the concept of object as it is the case in the MaDViWorld project.
3.2 The WhiteBoard Example

This second example represents a more advanced object for the MaDViWorld framework than the academic one, HelloWorld. Indeed, it uses several elaborate features of MaDViWorld objects. This example represents the realization of a blackboard object, renamed here WhiteBoard.
3.2.1 WhiteBoard Goals

The WhiteBoard object is a concrete implementation of a blackboard, where the avatars can write some text that is visible for all. So, the whiteboard can be shared between several users and its contents can be changed or updated by anyone through its graphical user interface. If somebody changes the contents of the object, the other users present in the room must be informed about the change and their WhiteBoard object needs to be updated. This task is accomplished using the remote events mechanism.
61
It would be good to be able to backup the contents of the whiteboard in case of a machine crash or something like that. Thus a recovery system of the object internal state is desirable too. In order to create the WhiteBoard object, a new package called whiteboard is created in the madviworld.wobject package. Then, inside this package, the subpackages impl and gui are created to complete the structure of WhiteBoard. Figure 3.3 presents the file structure of the whiteboard package.
Figure 3.3: File structure of the whiteboard package
3.2.2 WhiteBoard Interface

The first step to build the WhiteBoard object is to create its WhiteBoard.java interface inside the whiteboard package. The code with the package declaration, the packages importation and the interfaces declaration is presented below:
package ch.unifr.diuf.madviworld.wobject.whiteboard; import ch.unifr.diuf.madviworld.core.WObject; import java.rmi.RemoteException; import java.rmi.Remote; public interface WhiteBoard extends WObject, Remote {
Then, one must define methods that allow the users to get or change the contents of the WhiteBoard object. Therefore, the getText and setText methods are declared (without forgetting than they must throw a java.rmi.RemoteException):
public String getText() throws RemoteException; public void setText(String s) throws RemoteException;
The WhiteBoard object uses the remote event mechanism offered by the MaDViWorld framework. So, one also has to define the different kinds of events of the WhiteBoard (these will be later used):
protected static final long CONTENT_CHANGED = 1; }//end of class
3.2.3 WhiteBoard Implementation

The next step is to build the implementation part. The WhiteBoardImpl.java class is created inside the whiteboard.impl package.
62
The needed packages are imported, as well as the WhiteBoard interface. Moreover, the RemoteEvent class from the package madviworld.event has to be imported in order to use events:
package ch.unifr.diuf.madviworld.wobject.whiteboard.impl; import import import import import import import import ch.unifr.diuf.madviworld.core.EventIDs; ch.unifr.diuf.madviworld.core.WContainer; ch.unifr.diuf.madviworld.core.WObject; ch.unifr.diuf.madviworld.wobject.WObjectImpl; ch.unifr.diuf.madviworld.wobject.whiteboard.WhiteBoard; ch.unifr.diuf.madviworld.event.RemoteEvent; java.rmi.RemoteException; java.util.Hashtable;
Then, the WhiteBoardImpl class must implement its interface, WhiteBoard:

public class WhiteBoardImpl extends WObjectImpl implements WhiteBoard {
For the Whiteboard object, it is better to conserve the contents of the whiteboard somewhere. Thus, a variable of type String needs to be created:
private String content;
Of course, the class has to provide a constructor without arguments (the framework calls this constructor to dynamically instantiate this class) that invokes the constructor of its superclass (WObjectImpl):
public WhiteBoardImpl() throws RemoteException { super(); this.description="A simple whiteboard"; content = ""; }
The class must also provide another constructor with arguments, where name corresponds to the name of the instance, host to the name of the hosting machine, and container to the container of the object:
public WhiteBoardImpl(String name,String host,WContainer container) throws RemoteException { super(name,host,container); this.description="A simple whiteboard"; content = ""; }
The getText() method of the WhiteBoard interface can be implemented. It only returns the contents of the object as a string:
public String getText() {return content;}
Concerning the setText(String s) method , it is a bit more complicated. Of course, this method must replace the contents of the object with the string in parameter, but after that, the other avatars which are sharing the whiteboard object must be informed about the change. Events must be used in order to achieve this goal. Before using events, however, especially the RemoteEvent class, it is needed to define one field that will be used later to hold the sequence number of the last fired event:
private long seqNum = 0;
Now, the setText() method can be defined as follows :

public void setText(String s) { content = s; seqNum++; RemoteEvent evt = new RemoteEvent(this, WhiteBoard.CONTENT_CHANGED, seqNum); evt.addAttribute("eventType", EventIDs.OBJECT_EVENT_S);
63

evt.addAttribute("content", content); notifyAllListeners(evt);
The major point is the creation of the remote event with the source object (this), the kind of event (CONTENT_CHANGED from the WhiteBoard interface) and the sequence number (seqNum) as arguments. Then, two attributes are added to the new event. Later, these attributes will be extracted by the objects, which will receive the event. Finally, the event is sent to all registered listeners. It would be a pity if the contents of the whiteboard would be lost when the object is destroyed or when the room server crashes! Therefore, one must be able to store the state of an object and to use a recovery system. This is possible by using a hashtable containing the crucial object data. To achieve this, two methods have to be declared, getState() and setState(). The getState() method saves the state of the whiteboard object in putting its content variable (or any other java object) with a string key ("content") in a hashtable:
public Hashtable getState() { Hashtable s = new Hashtable(); s.put("content", this.content); return s; }
The recovery of an object state is done by the setState() method that needs the object whose state is recovered from as argument. This object must respect the WObject interface of the madviworld.core package:
public void setState(WObject otherObject) { System.out.println("Setting the state of Whiteboard!"); try { Hashtable s = otherObject.getState(); this.content = (String)(s.get("content")); } catch (RemoteException re) { re.printStackTrace(); } } }//end of class
For the state recovery mechanism, the first phase is to retrieve the state of the object (Hashtable s = otherObject.getState()). The second phase is to update the state (or the variables) of the current object with the retrieved state. For the whiteboard, only the content field matters (this.content = (String)(s.get("content"))).
3.2.4 WhiteBoard GUI

Within this section, we shall create, step by step, the whiteboard.gui package containing the graphical user interface of the WhiteBoard object. This package is composed of three classes: WhiteBoardGUIImpl.java, WhiteBoardPanel.java and WhiteBoardRemoteEventListener.java.
a) WhiteBoardGUIImpl
The WhiteBoardGUIImpl class is used to instantiate a graphical user interface for WhiteBoardImpl and to create a remote event listener for the graphical interface. First, it begins with the package declaration that it belongs to, then with the interface to import:
package ch.unifr.diuf.madviworld.wobject.whiteboard.gui; import ch.unifr.diuf.madviworld.wobject.WObjectGUIImpl;
64
Then, the WhiteBoardGUIImpl class must just extend WObjectGUIImpl class (which itself extends javax.swing.JPanel):
public class WhiteBoardGUIImpl extends WObjectGUIImpl {
The class has to provide a constructor, which invokes the constructor of its superclass:
public WhiteBoardGUIImpl() { super(); }
Finally, the initComponents() method creates new instances of the concrete GUI (WhiteBoardPanel) and of the remote event listener, before adding the GUI to the current container.
public void initComponents () { content = new WhiteBoardPanel(this); try { evtListener = new WhiteBoardRemoteEventListener((WhiteBoardPanel)content); } catch (Exception e) {e.printStackTrace();} add (content); } }//end of class
b) WhiteBoardPanel
The WhiteBoardPanel is really containing the graphical user interface for a WhiteBoardImpl. Of course, the first steps are the package declaration and the import of the necessary packages and interfaces:
package ch.unifr.diuf.madviworld.wobject.whiteboard.gui; import ch.unifr.diuf.madviworld.wobject.whiteboard.WhiteBoard; import java.rmi.RemoteException;
Next, the WhiteBoardPanel class extends javax.swing.JPanel:

public class WhiteBoardPanel extends javax.swing.JPanel {
Then, two variables have to be declared for further use:

private WhiteBoardGUIImpl context; private WhiteBoard impl;
The constructor is obligatory and it takes as parameter a WhiteBoardGUIImpl (that embeds this panel). Furthermore, within the constructor, the two variables context and impl must be initialized:
public WhiteBoardPanel(WhiteBoardGUIImpl c) { this.context=c; this.impl = (WhiteBoard)c.getWObjectImpl(); initComponents(); }
The initComponents() method refers to the interface creation phase, i.e. the definition of the graphical user interface. The following code generates a panel that contains a text area (where the user can write her text) and a button, which allows the user to set the contents of the whiteboard. It was automatically generated by the Forte IDE from Sun Microsystems:
private private private private private private javax.swing.JPanel titlePanel; javax.swing.JLabel title; javax.swing.JPanel mainPanel; javax.swing.JTextArea text; java.awt.Panel buttonPanel; javax.swing.JButton setTextButton;
65
private void initComponents() { titlePanel = new javax.swing.JPanel(); title = new javax.swing.JLabel(); mainPanel = new javax.swing.JPanel(); text = new javax.swing.JTextArea(); buttonPanel = new java.awt.Panel(); setTextButton = new javax.swing.JButton(); setLayout(new java.awt.GridBagLayout()); java.awt.GridBagConstraints gridBagConstraints1; titlePanel.setLayout(new java.awt.GridBagLayout()); java.awt.GridBagConstraints gridBagConstraints2; titlePanel.setMinimumSize(new java.awt.Dimension(80, 22)); title.setFont(new java.awt.Font("Verdana", 1, 14)); title.setText("A simple Whiteboard"); gridBagConstraints2 = new java.awt.GridBagConstraints(); titlePanel.add(title, gridBagConstraints2); gridBagConstraints1 = new java.awt.GridBagConstraints(); gridBagConstraints1.gridx = 0; gridBagConstraints1.gridy = 0; gridBagConstraints1.insets = new java.awt.Insets(25, 20, 25, 20); gridBagConstraints1.anchor = java.awt.GridBagConstraints.SOUTH; add(titlePanel, gridBagConstraints1); mainPanel.setLayout(new java.awt.GridBagLayout()); java.awt.GridBagConstraints gridBagConstraints3; text.setFont(new java.awt.Font("Verdana", 0, 12)); text.setText(readboard()); text.setMinimumSize(new java.awt.Dimension(200, 240)); text.setPreferredSize(new java.awt.Dimension(200, 240)); gridBagConstraints3 = new java.awt.GridBagConstraints(); gridBagConstraints3.gridx = 1; gridBagConstraints3.gridy = 1; mainPanel.add(text, gridBagConstraints3); buttonPanel.setBackground(new java.awt.Color(204, 204, 204)); buttonPanel.setFont(new java.awt.Font("Dialog", 0, 11)); buttonPanel.setForeground(java.awt.Color.black); setTextButton.setFont(new java.awt.Font("Verdana", 0, 12)); setTextButton.setText("Set Text"); setTextButton.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(java.awt.event.ActionEvent evt) { setTextButtonActionPerformed(evt); } }); buttonPanel.add(setTextButton); gridBagConstraints3 = new java.awt.GridBagConstraints(); gridBagConstraints3.gridx = 1; gridBagConstraints3.gridy = 0; gridBagConstraints3.fill = java.awt.GridBagConstraints.VERTICAL; mainPanel.add(buttonPanel, gridBagConstraints3); gridBagConstraints1 = new java.awt.GridBagConstraints(); gridBagConstraints1.gridx = 0; gridBagConstraints1.gridy = 1; add(mainPanel, gridBagConstraints1); } private void setTextButtonActionPerformed (java.awt.event.ActionEvent evt) { try { impl.setText(text.getText()); } catch (RemoteException e) {} }
Within the above code, an important line is:

text.setText(readBoard());
The readBoard() method asks the implementation part for the contents of the whiteboard by invoking the getText() method from the WhiteBoard.java interface. The interface corresponds to the impl variable (declared of type WhiteBoard):
66

private String readBoard() { String message = ""; try { message = impl.getText(); } catch (RemoteException e) {} return message; }
The programmer has to pay attention to the try-catch clause, because the getText() method of the interface throws a java.rmi.RemoteException, that has to be handled. Finally, one wants to define a public method that replaces the text area content with a new string:
public void setText(String s) { text.setText(s); } }//end of class
At this moment, the GUI is finished and looks like Figure 3.4 at runtime.
Figure 3.4: GUI of the WhiteBoard example
c) WhiteBoardRemoteEventListener
The WhiteBoardRemoteEventListener class manages the events intended for the GUI. Thanks to it, the GUI part can be notified of a remote event from the implementation part of the object. Moreover, it offers the possibility for the GUI to react according to the kind of the received remote event. The necessary packages and interfaces to import are:
package ch.unifr.diuf.madviworld.wobject.whiteboard.gui; import import import import ch.unifr.diuf.madviworld.event.RemoteEventListener; ch.unifr.diuf.madviworld.event.UnknownEventException; ch.unifr.diuf.madviworld.event.RemoteEvent; ch.unifr.diuf.madviworld.wobject.whiteboard.WhiteBoard;
67

import java.rmi.server.UnicastRemoteObject; import java.rmi.RemoteException;
The
WhiteBoardRemoteEventListener class inherits from the java.rmi.server.UnicastRemoteObject class and implements the RemoteEventListener interface from the madviworld.event package: public class WhiteBoardRemoteEventListener extends UnicastRemoteObject implements RemoteEventListener {
Each event has its own sequence number. Therefore, it is a good practice to keep the number of the last received event in a private field:
private long receivedSeqNum = 0;
In addition, the WhiteBoardRemoteEventListener class receives remote events and according to the nature of event fulfils the appropriate tasks. Most of the time, the WhiteBoardRemoteEventListener invokes methods on the concrete WhiteBoardPanel, its event consumer:
private WhiteBoardPanel eventConsumer;
The constructor takes the event consumer object as parameter:

public WhiteBoardRemoteEventListener(WhiteBoardPanel c) throws RemoteException { this.eventConsumer = c; }
As
WhiteBoardRemoteEventListener implements the madviworld.event.RemoteEventListener interface, it is necessary to define its "synchronized" notify() method. Within the latter the received remote event is decomposed in order to extract its own sequence number (seqNum) and its type (id). The sequence number
determines if the event must be consumed or not (for example, if the sequence number of the new event is lower than the last one received, the new event is omitted because it is deprecated):
public synchronized void notify(RemoteEvent clevt) throws UnknownEventException, RemoteException { long seqNum = clevt.getSequenceNumber(); long id = clevt.getID(); if (seqNum > receivedSeqNum) { if (clevt.getID() == WhiteBoard.CONTENT_CHANGED) { String c = (String)(clevt.getAttribute("content")); eventConsumer.setText(c); } receivedSeqNum = seqNum; } else { //do nothing, the event is deprecated } } }//end of class
If the received event is recent enough (if (seqNum > receivedSeqNum)), it is an appropriate event to consume! According to the kind of the event (if (clevt.getID() == WhiteBoard.CONTENT_CHANGED)), the WhiteBoardRemoteEventListener does the appropriate work. Moreover, if the event has attributes, they can be extracted (String c = (String)(clevt.getAttribute("content"))) and used (eventConsumer.setText(c)). In order to update the whiteboard contents, the public setText() method of the WhiteBordPanel class is invoked with the new contents variable (String c) as parameter:
eventConsumer.setText(c);
68
Thus, whenever the contents of the WhiteBoard changes, an event with its new contents as attribute is fired to all avatars who are sharing this same WhiteBoard object in a room and their GUIs are automatically updated. Avatars are always informed about every change of their WhiteBoard.
3.2.5 WhiteBoard Code and Javadoc

By following the links on the website, the programmer can find the entire source code of all the files composing the WhiteBoard example and visit its javadoc.
3.2.6 WhiteBoard Benefits

The WhiteBoard example is a richer object than the simple HelloWorld one. Of course, it contains an interface, a GUI part and an implementation part like HelloWorld, but it goes a little further. First, its GUI is more sophisticated, since it allows the avatar to interact with other ones, although it contains just a text area and a button. Then, its GUI can be updated with the help of its remote event listener and of the remote event mechanism. The implementation part can generate remote events in order to communicate with the GUI. Finally, the whiteboard object has a recovery state system.
3.3 The WhiteBoard 2 Example

The previous example explained the creation of a blackboard object, called WhiteBoard. That object can be shared by several avatars populating the same room and when one user changes its contents the other were automatically informed thanks to the remote event mechanism. In addition, its state can be easily saved and restored if necessary. This third example extends the WhiteBoard example by adding a second GUI to it. This is the reason why it is renamed WhiteBoard 2.
3.3.1 WhiteBoard 2 Goals

The WhiteBoard 2 example is based on the addition of a new graphical interface to the WhiteBoard object. Indeed, a MaDViWorld object can have one or more graphical interfaces for a given implementation part. Thus, the objective of this third example is to define a second GUI for our well-known WhiteBoard object. In order to reach this goal, the whiteboard package needs to be slightly changed, but without removing anything from the object itself or from its code. The WhiteBoard.java interface, the whiteboard.gui and the whiteboard.impl packages remain the same, but it is required to create a new package for the second GUI: whiteboard.gui_2. The new file structure of the whiteboard package is illustrated by Figure 3.5.
69
Figure 3.5: New file structure of the whiteboard package
3.3.2 WhiteBoard 2 Interface

The WhiteBoard 2 interface exactly remains the same as the WhiteBoard one (see 3.2.2 WhiteBoard Interface).
3.3.3 WhiteBoard 2 Implementation

The WhiteBoard 2 implementation exactly remains the same as the WhiteBoard one (see 3.2.3 WhiteBoard Implementation).
3.3.4 WhiteBoard 2 GUI

The whiteboard.gui_2 package can contain the new GUI, but the new files of this package have to be named with the string "_2" at the end of their name, which identifies files belonging to the second GUI. In summary, the new classes are the following: WhiteBoardGUIImpl_2.java, WhiteBoardPanel_2.java and WhiteBoardRemoteEventListener_2.java. The same constraints hold when other additional GUIs are created. For example, the classes of a potential third GUI would have to be called WhiteBoardPanel_3, WhiteBoardGUIImpl_3 and WhiteBoardRemoteEventListener_3. And so on for a fourth or fifth GUI.
a) WhiteBoardGUIImpl_2
The WhiteBoardGUIImpl_2 class is similar to the WhiteBoardGUIImpl class. The only modifications are the names of the classes:
package ch.unifr.diuf.madviworld.wobject.whiteboard.gui_2; import ch.unifr.diuf.madviworld.wobject.WObjectGUIImpl; public class WhiteBoardGUIImpl_2 extends WObjectGUIImpl { public WhiteBoardGUIImpl_2() { super(); } public void initComponents () { content = new WhiteBoardPanel_2(this); try { evtListener = new WhiteBoardRemoteEventListener_2((WhiteBoardPanel_2)content); } catch (Exception e) {e.printStackTrace();} add (content); }
70
}//end of class
b) WhiteBoardPanel_2
The first WhiteBoard GUI is quite limited for the user. For instance, the text area is too small and the user cannot write a long message in it. In order to improve it, it would be wise to provide some scrollbars to the text area and to move the setText button under the text area. The last two points represent the modifications between the WhiteBoardPanel and the WhiteBoardPanel_2 classes. As always, the first steps are the package declaration, as well as the import of the necessary packages and interfaces:
package ch.unifr.diuf.madviworld.wobject.whiteboard.gui_2; import ch.unifr.diuf.madviworld.wobject.whiteboard.WhiteBoard; import java.rmi.RemoteException;
The WhiteBoardPanel_2 class extends javax.swing.JPanel:

public class WhiteBoardPanel_2 extends javax.swing.JPanel {
The context variable changes to WhiteBoardGUIImpl_2, while the impl variable remains of type WhiteBoard (the same interface):
private WhiteBoardGUIImpl_2 context; private WhiteBoard impl;
The constructor takes as argument a WhiteBoardGUIImpl_2 (that embeds this panel). Furthermore, within the constructor, the two variables context and impl are initialized:
public WhiteBoardPanel_2(WhiteBoardGUIImpl_2 c) { this.context=c; this.impl = (WhiteBoard)c.getWObjectImpl(); initComponents(); }
The initComponents() method refers to the interface creation phase, i.e. the definition of the graphical user interface. The following code was automatically generated by the Forte IDE from Sun Microsystems:
private private private private private private private javax.swing.JPanel titlePanel; javax.swing.JLabel title; javax.swing.JPanel jPanel2; javax.swing.JPanel mainPanel; javax.swing.JScrollPane jScrollPane1; javax.swing.JTextArea text; javax.swing.JButton jButton1;
private void initComponents() { titlePanel = new javax.swing.JPanel(); title = new javax.swing.JLabel(); jPanel2 = new javax.swing.JPanel(); mainPanel = new javax.swing.JPanel(); jScrollPane1 = new javax.swing.JScrollPane(); text = new javax.swing.JTextArea(); jButton1 = new javax.swing.JButton(); setLayout(new java.awt.BorderLayout()); setLayout(new java.awt.BorderLayout()); setMaximumSize(new java.awt.Dimension(600, 480)); setMinimumSize(new java.awt.Dimension(400, 300)); setPreferredSize(new java.awt.Dimension(400, 300)); titlePanel.setLayout(new java.awt.GridBagLayout()); java.awt.GridBagConstraints gridBagConstraints1;
71

titlePanel.setMaximumSize(new java.awt.Dimension(600, 50)); titlePanel.setMinimumSize(new java.awt.Dimension(180, 22)); titlePanel.setPreferredSize(new java.awt.Dimension(170, 30)); title.setFont(new java.awt.Font("Verdana", 3, 14)); title.setForeground(java.awt.Color.blue); title.setText("A simple Whiteboard"); title.setMaximumSize(new java.awt.Dimension(200, 30)); title.setMinimumSize(new java.awt.Dimension(170, 18)); title.setPreferredSize(new java.awt.Dimension(180, 20)); gridBagConstraints1 = new java.awt.GridBagConstraints(); titlePanel.add(title, gridBagConstraints1); add(titlePanel, java.awt.BorderLayout.NORTH); jPanel2.setLayout(new java.awt.BorderLayout()); mainPanel.setLayout(new java.awt.BorderLayout()); jScrollPane1.setHorizontalScrollBarPolicy( javax.swing.JScrollPane.HORIZONTAL_SCROLLBAR_ALWAYS); jScrollPane1.setVerticalScrollBarPolicy( javax.swing.JScrollPane.VERTICAL_SCROLLBAR_ALWAYS); jScrollPane1.setMinimumSize(new java.awt.Dimension(200, 200)); jScrollPane1.setAutoscrolls(true); text.setFont(new java.awt.Font("Verdana", 0, 12)); text.setForeground(java.awt.Color.blue); text.setText(readboard()); text.setMinimumSize(new java.awt.Dimension(600, 600)); text.setPreferredSize(new java.awt.Dimension(1000, 1000)); jScrollPane1.setViewportView(text); mainPanel.add(jScrollPane1, java.awt.BorderLayout.CENTER); jPanel2.add(mainPanel, java.awt.BorderLayout.CENTER); jButton1.setText("Set Text"); jButton1.setMaximumSize(new java.awt.Dimension(50, 26)); jButton1.setMinimumSize(new java.awt.Dimension(50, 26)); jButton1.setPreferredSize(new java.awt.Dimension(50, 26)); jButton1.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(java.awt.event.ActionEvent evt) { setTextButtonActionPerformed(evt); } }); jPanel2.add(jButton1, java.awt.BorderLayout.SOUTH); add(jPanel2, java.awt.BorderLayout.CENTER); }
The two methods setTextButtonActionPerformed() and readboard() remain identical to those in the WhiteBoardPanel class:
private void setTextButtonActionPerformed (java.awt.event.ActionEvent evt){ try { impl.setText(text.getText()); } catch (RemoteException e) {} } private String readboard() { String resp = ""; try { resp = impl.getText(); } catch (RemoteException e) {} return resp; }
The public setText() method does not change either. In fact, it is only invoked inside WhiteBoardRemoteEventListener_2 when the contents of the WhiteBoard has to be updated:
public void setText(String s) { text.setText(s); } }//end of class
The additional GUI is now fully defined and the result is presented in Figure 3.6.
72
Figure 3.6: GUI of the WhiteBoard 2 example
Note: When the user starts to use the WhiteBoard, she should have the possibility to choose between all its available GUIs. This is done in the client part of the MaDViWorld framework and is out of the scope of this tutorial.
c) WhiteBoardRemoteEventListener_2
WhiteBoardRemoteEventListener_2 class manages the events for the second GUI. Note that the events generated by the implementation part (i.e. WhiteBoardImpl) do not have
changed, since the implementation part has not changed. Thus, the WhiteBoardRemoteEventListener_2 class can behave WhiteBoardRemoteEventListener class and its code is almost identical:
package ch.unifr.diuf.madviworld.wobject.whiteboard.gui_2; import import import import import import ch.unifr.diuf.madviworld.event.RemoteEventListener; ch.unifr.diuf.madviworld.event.UnknownEventException; ch.unifr.diuf.madviworld.event.RemoteEvent; ch.unifr.diuf.madviworld.wobject.whiteboard.WhiteBoard; java.rmi.server.UnicastRemoteObject; java.rmi.RemoteException;
like
the
public class WhiteBoardRemoteEventListener_2 extends UnicastRemoteObject implements RemoteEventListener { private long receivedSeqNum = 0; private WhiteBoardPanel_2 eventConsumer; public WhiteBoardRemoteEventListener_2(WhiteBoardPanel_2 c) throws RemoteException { this.eventConsumer = c; } public synchronized void notify(RemoteEvent clevt) throws UnknownEventException, RemoteException { long seqNum = clevt.getSequenceNumber(); long id = clevt.getID(); if (seqNum > receivedSeqNum) { if (clevt.getID() == WhiteBoard.CONTENT_CHANGED) {
73

String c = (String)(clevt.getAttribute("content")); eventConsumer.setText(c); } receivedSeqNum = seqNum; } else { //do nothing, the event is deprecated } } }//end of class
3.3.5 WhiteBoard 2 Code and Javadoc

By following the links on the website, the programmer can find the entire source code of all the files composing the WhiteBoard 2 example and visit its javadoc.
3.3.6 WhiteBoard 2 Benefits

In this example, the WhiteBoard object of the second example has been equipped with an additional graphical user interface, without having to rewrite the object code. The addition of a new GUI only requires a few steps. The interface and the implementation part of the object do not need to be rewritten or changed. Each GUI and its files are defined through a unique number at the end of their name. If an object owns several GUI, the user can choose which one to use.
3.4 Other Objects

Besides the three examples of the tutorial, the MaDViWorld framework already proposes a few interesting objects. The latter have not been integrated into the tutorial in order to keep it as basic as possible. You find below the list of these other MaDViWorld objects with a short summary of their characteristics and a snapshot of their GUI. They can be downloaded from the website: Fibonacci Clock TicTacToe Minesweeper Tamagotchi BattleShip
3.4.1 Fibonacci
The Fibonacci objects are a utility to calculate members of a Fibonacci series. The user must give the index n of the term of the series she is interested in and the program computes the result (the n-th term) and displays it to the user. These objects own one graphical user interface and do not use events. They are very similar to the HelloWorld objects. The GUI of the object is presented in Figure 3.7.
74
Figure 3.7: GUI of the Fibonacci object
3.4.2 Clock
The Clock objects are little programs, which display the current time to their users. Moreover, the latter can choose between three GUIs for their presentation on the screen. They present similarities with the WhiteBoard 2 objects. The first GUI (Figure 3.8) waits that the user clicks on a button before displaying the current time. This GUI does not use remote events. It works like the fibonacci objects. The second GUI (Figure 3.9) displays the current time every second in a textual way. In fact, an event is fired every second so that the GUI receives it and updates itself automatically. The third GUI (Figure 3.10) proposes an analog clock with the current date. This GUI uses the same event mechanism as the second one.
Figure 3.8: First GUI of the Clock object
Figure 3.9: Second GUI of the Clock object
Figure 3.10: Third GUI of the Clock object
75
3.4.3 TicTacToe
The TicTacToe objects are two players games based on the classical tic-tac-toe, where each player tries to align three symbols in any direction. Their GUIs (Figure 3.11) allow their users not only to play, but also to be informed about who is playing against them and about how many other avatars are watching the game. The objects use remote events in order to manage the games between two players. They are based on the concepts of the second tutorial example (WhiteBoard) and show how multi-user objects can be developed.
Figure 3.11: GUI of the TicTacToe object
3.4.4 Minesweeper
The Minesweeper objects are single player games. The user has to discover entirely a grid without falling on a mine in the shortest time as possible. She has the ability to mark the mines with flags. These objects manage their game with the help of remote events. Although these objects are for a single player, they have similarities with the TicTacToe objects. Their GUIs are illustrated in Figure 3.12.
76
Figure 3.12: GUI of the Minesweeper object
3.4.5 Tamagotchi
The Tamagotchi objects are tiny pets from cyberspace that need love to survive and grow. So, they can be fed, cleaned or distracted according to the avatars' desires. Of course, the virtual pets can change their mood, grow up, be happy or upset, and even die. Moreover, the pets are in relation with one another. Thus, they get upset if one of them dies. They offer a GUI (shown in Figure 3.13) to control themselves. Note that their GUIs use slightly more sophisticated resources (such as JPEG images). The innovation brought by Tamagotchi objects is that they listen to events from the other objects of the same kind. In this sense, one could speak about "social" objects. This kind of objects also present similarities with the Clock, as it has an own thread of life, its "biological" clock.
77
Figure 3.13: GUI of the Tamagotchi object in good and bad health
3.4.6 BattleShip
The BattleShip objects are two players games based on the classical battleship one. Each player owns a fleet and tries to destroy the opponent's one. Similarities can be found with the TicTacToe (two players). Note that their GUIs also use sophisticated resources such as JPEG images and WAV sounds.
Figure 3.14: GUI of the BattleShip object
3.5 Summary
This tutorial on how to create MaDViWorld objects is now completed. The programming of an object is a simple process and it does not require any special skills in Java programming. The programmer must simply implement the object package by making good use of the
78
classes already offered by the framework. Mobility, distributed computing and remote events mechanism come then for free. The creation of a new object is summarized one final time below: First, clarify the concept of the new object, its objectives, its functionalities, what it will be, what it will look like, how the user will interact with it and all what is needed to realize it. Then, create the object package inside the madviworld.wobject package. Create the object interface and declare the methods that represent the desired capabilities of the new object. The impl package represents the implementation part. It is supposed to perform the whole calculation process, to store the data and to manage the object. The only constraint is that the implementation class must effectively implement the object interface. Moreover, if the object is interested in listening events from other objects, it needs its own remote event listener. The GUI part can be composed of one or several GUIs packages. The object GUI is the visible part for the human user since she uses it to interact with the object. It is recommended that the concrete GUI inherits from the javax.swing.JPanel class, but for the rest of the GUI, it is up to the programmer. If the GUI part can receive remote events, it needs a remote event listener.
Finally, compile the object and then populate the virtual world using a room wizard that interacts with the available room servers. In order to help the programmer in the creation of new objects, she can find a quick reference in the website appendices.
79
Bibliography
MaDViWorld official papers
[1] P. Fuhrer, G. Kouadri Mostfaoui and J. Pasquier-Rocha, The MaDViWorld Software Framework for Massively Distributed Virtual Worlds: Concepts, Examples and Implementation Solutions, Department of Informatics Internal Working Paper no 01-23, University of Fribourg, Switzerland, July 2001. [2] P. Fuhrer, G. Kouadri Mostfaoui and J. Pasquier-Rocha, MaDViWorld: a Software Framework for Massively Distributed Virtual Worlds, Software - Practice and Experience, 2002, 32:645-668. [3] P. Fuhrer, Massively Distributed Virtual Worlds: a Framework Approach, FIDJI2002 International Workshop on scientiFic engIneering of Distributed Java applIcations, Luxembourg, November 28-29, 2002.
Java and RMI

[4] [5] [6] [7] Flanagan David, Java in a Nutshell (3rd Edition), O'Reilly, 1999. Flanagan David (et al.), Java Enterprise in a Nutshell (3rd Edition), O'Reilly, 1999. Grosso William, Java RMI, O'Reilly, 2001. P. Fuhrer, RMI Overview, Department of Informatics, University of Fribourg, January 2002 (http://diuf.unifr.ch/~fuhrer/publications/others/RMI.pdf).
Design Patterns
[8] Gamma Erich (et al.), Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1995.
80
Appendice D : Site internet du travail
APPENDICE D : SITE INTERNET DU

TRAVAIL
A ladresse
http://diuf.unifr.ch/softeng/student-projects/completed/marchon/
se trouvent un rsum du travail et le lien vers le guide du programmeur dobjets MaDViWorld, ainsi que le code source et la javadoc des deux objets programms. De plus, cette mme adresse propose la version PDF de ce document.
81
Appendice E : CD-Rom
APPENDICE E : CD-ROM
Le CD-Rom fourni en annexe du prsent document contient : La documentation (rpertoire documentation/) - rapport.doc: Travail de diplme au format Word - rapport.pdf: Travail de diplme au format PDF Les objets (rpertoire objets/) - miner/ Jeu du dmineur miner.zip: Code source de lobjet miner javadoc/: Javadoc de lobjet miner - battleship/ Jeu de la bataille navale battleship.zip: Code source de lobjet battleship javadoc/: Javadoc de lobjet battleship Le guide complet du programmeur dobjets MaDViWorld (rpertoire guide/) La dernire version du framework MaDViWorld (rpertoire framework/) - madviworldc.zip: Application avatar - madviworlds.zip: Application room server - madviworldw.zip: Application room wizard
82

Rapport Madviworld

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Madviworld

Transféré par

Droits d'auteur :

Formats disponibles

Dpartement dInformatique Universit de Fribourg - Suisse

MADVIWORLD : ETUDE DU FRAMEWORK ET CRATION DUN GUIDE DU PROGRAMMEUR DOBJETS

Travail de Diplme en Informatique Superviseur : Prof. Jacques Pasquier-Rocha

Dpartement dInformatique Universit de Fribourg Rue Faucigny 2 CH-1700 Fribourg

Tl. : +41 26 300 83 22 Fax : +41 26 300 97 26 http://www.unifr.ch/informatics/

Table des Matires

1.1 Prsentation du travail

1.2 Objectif du travail

1.3 Structure du document

2.1 Introduction MaDViWorld

2.1.1 Prsentation de MaDViWorld

2.1.2 Concept dobjet

room wobject util event

Default Implementation packages Specific Implementation packages

Figure 2.1: Architecture du projet MaDViWorld (cf. [7])

"Room server application"

"Room setup utility"

"System implementation layer"

"Specific implementation layer"

2.3.1 Package myobj

Figure 2.2:Aperu du package myobj (cf. [7])

MyObjRemoteEventListener +notify(in theEvent : RemoteEvent) : void

Figure 2.3:Aperu de linterface MyObj et du package myobj.impl

MyObjRemoteEventListener +notify(in theEvent : RemoteEvent) : void

Figure 2.4: Aperu du package myobj.gui

2.3.2 Package event

3 Objets dvelopps pour MaDViWorld

3 OBJETS DVELOPPS POUR MADVIWORLD

3 Objets dvelopps pour MaDViWorld

3 Objets dvelopps pour MaDViWorld

Bouton Reset Grille de jeu Chronomtre

Nombre de drapeaux disposition

Figure 3.1: Dcomposition du GUI de lobjet miner

3 Objets dvelopps pour MaDViWorld

Case avec une mine

Case avec un drapeau

Case vide, avec 2 mines dans son voisinage

Figure 3.2: Exemple de fin de partie pour lobjet miner

3.2 Bataille navale

3 Objets dvelopps pour MaDViWorld

chacun peut positionner sa flotte;

deux peut commencer tirer sur la flotte ennemie;

3 Objets dvelopps pour MaDViWorld

3 Objets dvelopps pour MaDViWorld

Panneau de placement des bateaux et dattaque

Bouton daide Bouton dinformation

Figure 3.3: Dcomposition du GUI de lobjet battleship

3 Objets dvelopps pour MaDViWorld

Tir ennemi dans leau

Dernier tir ennemi

Figure 3.4: Exemple dune partie pour lobjet battleship

4 Guide du programmeur dobjets MaDViWorld

4 GUIDE DU PROGRAMMEUR DOBJETS MADVIWORLD

4.2 Design du guide

4 Guide du programmeur dobjets MaDViWorld

4.2.1 Convivialit et accessibilit

4 Guide du programmeur dobjets MaDViWorld

4 Guide du programmeur dobjets MaDViWorld

4 Guide du programmeur dobjets MaDViWorld

Figure 4.1: Aperu de la page daccueil du site

4 Guide du programmeur dobjets MaDViWorld

Figure 4.2: Menus de navigation

4 Guide du programmeur dobjets MaDViWorld

4.3 Programmation du site