Travail de Diplôme au format PDF - DIUF

Transcription

Département d’Informatique – Université de Fribourg - Suisse
MADVIWORLD : ETUDE DU FRAMEWORK ET
CRÉATION D’UN GUIDE DU PROGRAMMEUR
D’OBJETS
Fabrice Marchon
[email protected]
Travail de Diplôme en Informatique
Superviseur : Prof. Jacques Pasquier-Rocha
Septembre 2002
Département d’Informatique
Université de Fribourg
Rue Faucigny 2
CH-1700 Fribourg
Tél. : +41 26 300 83 22
Fax : +41 26 300 97 26
http://www.unifr.ch/informatics/
Table des Matières
1 Introduction............................................................................................................................................. 4
1.1 Présentation 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 Présentation de MaDViWorld..................................................................................................... 6
2.1.2 Concept d’objet ........................................................................................................................... 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 développés pour MaDViWorld................................................................................................ 16
3.1 Démineur.......................................................................................................................................... 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 d’objets 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 Réalisation................................................................................................................................. 36
5.1.2 Améliorations............................................................................................................................ 36
5.2 Critique du framework ..................................................................................................................... 37
5.2.1 Points forts ................................................................................................................................ 37
5.2.2 Extensions souhaitables ............................................................................................................ 37
Références................................................................................................................................................. 39
1 Introduction
Appendice A : Software et Hardware .................................................................................................... 40
Software ................................................................................................................................................. 40
Programmation d’objets ..................................................................................................................... 40
Programmation du site ....................................................................................................................... 40
Hardware ............................................................................................................................................... 40
Appendice B : Guide d’installation et d’utilisation ............................................................................... 41
Guide d’installation ............................................................................................................................... 41
Guide d’utilisation ................................................................................................................................. 42
Appendice C : Version imprimable du "MaDViWorld Object Programmer’s 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
3
1 Introduction
1 INTRODUCTION
Le chapitre 1 sert d’introduction au présent document. Il présente tout d’abord le cadre du
travail, puis en expose les objectifs. Finalement, il décrit la structure du document et les
conventions utilisées.
1.1 Présentation du travail
Le projet MaDViWorld est développé au sein du groupe de recherche Software Engineering
du
Département
d’Informatique
de
l’Université
de
Fribourg
(cf.
http://diuf.unifr.ch/softeng/). Il s’agit d’une architecture logicielle destinée à
accueillir des systèmes de mondes virtuels massivement distribués.
Le software framework MaDViWorld est basé sur le modèle client-serveur avec la
particularité de n’inclure aucun serveur centralisé ; en effet, le côté serveur peut être réparti
sur un nombre arbitraire de machines. Chacune d’elles est connectée aux autres à l’aide
d’internet et héberge une partie du monde virtuel, de la même manière que des serveurs http.
Brièvement, dans le contexte des mondes virtuels, de multiples utilisateurs et objets actifs
interagissent dans le même espace. Ils s’influencent directement les uns et les autres. Si un
utilisateur apporte quelque modification au monde virtuel, les autres utilisateurs présents dans
le même sous-espace (c’est-à-dire dans la même pièce) en sont immédiatement avertis.
1.2 Objectif du travail
L’objectif de ce travail est dédoublé de la manière suivante :
•
Dans un premier temps, programmer deux objets pour MaDViWorld afin de s’imprégner
de l’utilisation du framework.
•
Dans un second temps, fort de l’expérience acquise, concevoir et réaliser le guide du
programmeur d’objets. Ainsi, le guide devra présenter le software framework
MaDViWorld, son architecture et le concept d’objet tel qu’il est conçu dans
MaDViWorld. Ensuite, le guide devra également inclure un tutorial de programmation à
l’aide d’exemples d’objets concrets. Enfin, la forme du guide sera celle d’un site internet
convivial, rédigé en anglais pour toucher un maximum de public.
1.3 Structure du document
Le présent document est décomposé 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.
4
1 Introduction
•
Le deuxième chapitre présente brièvement le projet MaDViWorld qui est le support de ce
travail. Les différentes sections de ce chapitre abordent les caractéristiques du projet, son
architecture, ses applications, ses couches et ses principales composantes.
•
Dans le troisième chapitre sont exposés les objets qui ont été développés pour
MaDViWorld dans le cadre de ce travail. Il s’agit des célèbres jeux Démineur et Bataille
Navale.
•
Le quatrième chapitre aborde la partie du travail consacrée au guide du programmeur
d’objets MaDViWorld. Il présente tout d’abord 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 cinquième chapitre.
•
L’appendice A renferme toutes les informations relatives aux logiciels, aux programmes
et aux outils qui ont été utilisés, ainsi que les configurations des machines de
développement et de tests.
•
L’appendice B explique comment installer et utiliser le framework MaDViWorld et ses
applications.
•
L’appendice C contient la version imprimable du guide du programmeur d’objets
MaDViWorld.
•
Le site internet de ce travail est présenté dans l’appendice D.
•
L’appendice E indique le contenu du CD-Rom fourni en annexe de ce document.
1.4 Conventions
Ce document est divisé en chapitres, qui eux-mêmes peuvent être divisés en sections, voire en
sous-sections.
Les différentes figures sont numérotées à l’intérieur de chaque chapitre. Par exemple, une
référence à la Figure j du chapitre i sera notée Figure i.j.
La bibliographie est classée par ordre alphabétique du nom de l’auteur ou de l’organisation.
A l’intérieur du texte, les mots importants sont en gras ou en italique.
La police Letter Gothic MT est utilisée pour les liens hypertextes, les noms de classes, de
packages et de répertoires.
5
2 MaDViWorld
2 MADVIWORLD
Le chapitre 2 est entièrement dédié au projet MaDViWorld. Tout d’abord, il présente le projet
dans sa globalité, puis expose son architecture, ses applications et ses couches, et termine en
dévoilant quelques-uns des packages qui composent le framework logiciel.
2.1 Introduction à MaDViWorld
Le projet MaDViWorld est développé au sein du groupe de recherche Software Engineering
du Département d’Informatique de l’Université de Fribourg (cf. [2]). Les domaines de
recherche de ce groupe sont la programmation distribuée orientée objet, les mondes virtuels,
la programmation de composants réactifs et la sécurité dans des environnements Java et Jini.
2.1.1 Présentation de MaDViWorld
MaDViWorld est l’acronyme pour Massive Distributed Virtual World. Il s’agit d’une
architecture logicielle destinée à accueillir des systèmes de mondes virtuels massivement
distribués.
Ce framework est basé sur le modèle client-serveur avec la particularité de n’inclure aucun
serveur centralisé ; en effet, le côté serveur peut être réparti sur un nombre arbitraire de
machines.
Un monde virtuel est composé de pièces et d’objets actifs distribués sur diverses machines,
qui vont héberger chacune une application serveur. Les pièces peuvent être interconnectées
entre elles par l’intermédiaire de simples portes et elles sont capables d’être peuplées avec
des objets. Puis, les utilisateurs sont représentés par des avatars au travers d’une application
cliente. Ces avatars possèdent la capacité de visiter les pièces et d’interagir avec les objets
contenus dans celles-ci, ainsi qu’avec les autres avatars se trouvant dans la même pièce au
même moment. Une terminologie plus détaillée est présenté dans [6].
Le software framework MaDViWorld est développé à l’aide du langage de programmation
Java (cf. [3] et [4]) de Sun MicroSystems, dans la version 1.4. De plus, il tire énormément
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 d’objet
Il est important de préciser le concept d’objet tel qu’il est présent et interprété au sein de
MaDViWorld.
Dans le contexte des mondes virtuels, la définition d’un objet ne se restreint pas à une chose
qui peut être seulement manipulée. Il existe plusieurs sortes d’objets : certains sont passifs,
c’est-à-dire qu’ils peuvent être modifiés par l’interaction humaine, plus précisément par
l’interaction d’un avatar ; certains sont réactifs, parce qu’ils changent lorsque d’autres objets
6
2 MaDViWorld
changent ; d’autres sont encore actifs, car ils ont la capacité de se transformer eux-mêmes. Le
software framework MaDViWorld accepte ces trois catégories d’objets.
De plus, comme un monde virtuel est réparti sur une multitude de machines, il est logique
qu’un objet donné puisse être transporté d’une pièce de la machine A vers une pièce de la
machine B. De la sorte, comme dans le monde réel, les objets sont également mobiles, sans
être statiques ou rattachés à une unique pièce.
Un avatar ne déplace pas seulement des objets, mais il peut également les copier (cloner)
avec toutes leurs propriétés. En effet, certains objets sont dotés d’un état interne qui peut être
sauvegardé et restauré, par exemple en cas de "crash" de la machine qui héberge la pièce qui
les contient.
Les objets ont encore la possibilité d’être exécutés soit sur la machine distante où ils se
trouvent, soit sur la machine locale de l’utilisateur.
La dernière caractéristique est qu’un utilisateur interagit avec l’objet au moyen d’un GUI
(Graphical User Interface) simple ou sophistiqué. Cette interface graphique est toujours
exécutée du côté client, sur sa machine locale qui héberge une application cliente. Le
mécanisme de téléchargement du code vers la machine de l’utilisateur est entièrement
automatisé et géré par le framework MaDViWorld lui-même.
2.2 Architecture
Le framework MaDViWorld est composé de 10 packages qui contient toutes les classes
nécessaires aux différentes composantes de MaDViWorld afin de créer, gérer et utiliser un
monde virtuel.
Au total, cela représente plus de 100 classes et plus de 14'000 lignes de code source Java. Si
l’on considère encore les objets déjà disponibles, le nombre de classes s’élève à plus de 200 et
le tout totalise plus de 37'000 lignes de code.
Afin d’avoir une meilleure idée et un meilleur aperçu du projet, la Figure 2.1 résume
l’architecture globale du framework MaDViWorld. Les divers blocs qui le composent sont
séparés par des lignes blanches et leurs rôles sont illustrés par différentes couleurs.
7
2 MaDViWorld
core
avatar
room
wobject
Default
avatar
event
Default
room
Room
Avatar
util
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 décomposés verticalement, c’est-à-dire, de gauche à droite,
les trois premières séparations correspondent respectivement aux trois applications
indépendantes 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 gèrent des aspects de plus bas niveau (transfert de classes, administration du
réseau, etc.).
Si le lecteur désire avoir plus de détails sur les applications de MaDViWorld, il les trouvera
dans [5] et [6].
"Client application"
Cette application représente l’utilisateur sous forme d’avatar afin de lui permettre de visiter le
monde virtuel et ses sous-espaces : les pièces. Elle lui confère également la possibilité
d’interagir avec les objets contenus dans celles-ci (les exécuter, les copier, les déplacer, …),
ainsi qu’avec les autres avatars (leur parler, les voir, …).
De plus, elle est exécutée localement, sur la machine de l’utilisateur. Pour se connecter à une
pièce, elle requiert simplement les coordonnées de celle-ci, à savoir l’adresse IP de la machine
qui héberge la pièce et son nom.
Dans la prochaine version du framework, les avatars pourront également faire des recherches
de pièces par critères. Par exemple, trouver toutes les pièces qui s’appellent « donjon » ou
toutes les pièces qui sont destinées à des jeux.
8
2 MaDViWorld
"Room server application"
Comme le monde virtuel est constitué de pièces, il faut bien les héberger : c’est le rôle de
cette application, qui recueille et gère les pièces d’une partie du monde virtuel sur une
machine donnée.
Cette application offre de surcroît un système de persistance qui, en cas de "crash" de la
machine, permet de reconstituer les pièces et leurs objets.
"Room setup utility"
Cette simple application permet à l’utilisateur de créer et d’administrer des pièces sur
n’importe quelle machine, locale ou distante, qui exécute l’application room server. Cet
utilitaire est aussi intitulé room wizard.
Elle contient les classes nécessaires à la création d’objets en vue de peupler les pièces. Ainsi,
elle offre la possibilité d’introduire de nouveaux objets dans une pièce pendant la phase de
création de cette dernière.
2.2.2 Layers
Si l’on considère la Figure 2.1 horizontalement, il en ressort trois niveaux hiérarchiques qui
sont respectivement de haut en bas : specification layer, system implementation layer et
specific implementation layer. Chaque niveau hiérarchique possède son propre rôle et sa
propre fonction au sein du software framework.
Si le lecteur désire avoir de plus amples informations sur les niveaux hiérarchiques du
framework MaDViWorld, il les trouvera dans [5] et [6].
"Specification layer"
Le specification layer est représenté par le package core1 de la partie supérieure de la
Figure 2.1. Il est commun aux trois applications, car il en définit le protocole de
communication entre ces composantes. En effet, les classes de ce package renferment toutes
les règles (et plus particulièrement toutes les interfaces) que doivent respecter les applications
cliente, room server et room wizard dans le but de communiquer correctement entre elles.
Idéalement, le package core représente le protocole abstrait minimal à implémenter 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
d’implémentation par défaut du framework. Le system implementation layer est divisé en trois
parties, une pour chaque application. En fait, les composantes de ce niveau hiérarchique
symbolisent l’ensemble basique des règles pour chaque implémentation spécifique d’une
application : le package avatar pour l’application cliente, le package room pour room server
et le package wobject pour room wizard.
Les applications cliente et room server sont dotées en plus d’une implémentation par défaut.
1
Pour des raisons de lisibilité et de simplification, dans la suite de ce document, le préfixe
sera omis dans les noms du packages du framework.
ch.unifr.madviworld
9
2 MaDViWorld
"Specific implementation layer"
Le troisième et dernier niveau de la Figure 2.1 correspond à l’implémentation concrète, où se
trouvent toutes les classes spécifiques d’une application ; le lecteur remarque à nouveau qu’il
y a un package pour chaque application.
Cette implémentation spécifique est une implémentation possible parmi beaucoup d’autres,
parce que cette partie du framework MaDViWorld est totalement libre. N’importe quel
développeur peut proposer une implémentation réelle à ce niveau si cette dernière respecte les
contraintes du framework.
Par exemple, une direction peut être d’enrichir le monde virtuel à l’aide de nouveaux objets
actifs. Pour ce faire, il suffit de fournir les implémentations appropriées du package wobject
(voir la sous-section 2.3.1) et d’utiliser les applications par défaut du framework.
Il est tout à fait intelligible d’offrir une version plus riche et meilleure des applications cliente
et room server soit en étendant les implémentations par défaut déjà existantes, soit en créant
une nouvelle implémentation qui hérite des classes du framework, voire les deux en même
temps.
2.3 Packages
Après que la section précédente a présenté l’architecture générale du MaDViWorld, ses
applications et ses niveaux hiérarchiques, cette section expose plus en détails deux package
essentiels du framework, à savoir les packages myobj, implémentation concrète de nouveaux
objets, et event, qui offre tout le mécanisme d’événements.
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 règles. Evidemment, le processus de création d’un objet doit rester très
simple et le moins contraignant que possible.
En voici grossièrement la solution :
•
Utiliser le langage de programmation Java et les classes du framework MaDViWorld;
•
Posséder un ensemble de règles afin de créer un objet compatible avec MaDViWorld,
ensemble qui est représenté par le package wobject;
•
Créer pour le nouvel objet un nouveau package qui hérite du package wobject.
L’appendice C contient le guide qui explique "pas par pas" les différentes étapes. Sa version
en ligne se trouve dans [2]. Néanmoins, reprenons brièvement les principaux concepts
impliqués.
La création du package d’un nouvel objet MaDViWorld doit se réaliser selon certaines
conditions et certaines contraintes. Examinons le cas de la création d’un hypothétique objet
intitulé myobj. La Figure 2.2 présente un aperçu 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 appelée MyObj,
•
Un package myobj.impl, qui correspond à la partie d’implémentation,
•
Un package myobj.gui, qui correspond à la partie GUI.
«interface»
java.rmi.Remote
ch.unifr.diuf.madviworld.core
«interface»
WObjectGUI
ch.unifr.diuf.madviworld.event
«interface»
WObject
framework classes
RemoteEvent
ch.unifr.diuf.madviworld.wobject
«interface»
RemoteEventListener
WObjectImpl
WObjectGUIImpl
+notify(in theEvent : RemoteEvent) : void
+initComponents() : void
ch.unifr.diuf.madviworld.wobjects.myobj
«interface»
MyObj
ch.unifr.diuf.madviworld.wobjects.myobj.gui
ch.unifr.diuf.madviworld.wobjects.myobj.impl
1
MyObjGUIImpl
implementation classes
1
MyObjRemoteEventListener
1 1
MyObjPanel
java.rmi.server.UnicastRemoteObject
javax.swing.JPanel
MyObjImpl
Figure 2.2:Aperçu du package myobj (cf. [7])
Cette décomposition n’est pas accidentelle, car elle représente la solution la plus appropriée
afin de remplir toutes les caractéristiques que le projet MaDViWorld propose pour un objet.
En fait, comme les objets peuvent être exécutés localement ou à distance, la partie
d’implémentation s’exécute respectivement soit sur la machine locale de l’utilisateur, soit sur
la machine où est exécuté le room server. D’autre part, l’application cliente transfère toujours
la partie GUI sur sa machine et l’exécute localement. Telle est la raison pour laquelle les
parties implémentation et GUI d’un objet ne peuvent être regroupées. Elles doivent être
séparées dans deux différents packages.
11
2 MaDViWorld
framework classes
«interface»
WObject
WObjectImpl
«interface»
MyObj
MyObjImpl
Figure 2.3:Aperçu de l’interface MyObj et du package myobj.impl
Interface MyObj
Comme le montrent les Figures 2.2 et 2.3, l’interface wobject.myobj.MyObj hérite des
interfaces java.rmi.Remote et core.WObject. L’interface MyObj a pour dessein de déclarer
des méthodes qui doivent être implémentées par le package wobject.myobj.impl, et plus
particulièrement par la classe wobject.myobj.impl.MyObjImpl.
La partie GUI peut invoquer dès lors ces méthodes de la partie implémentation au travers de
l’interface MyObj. Ces méthodes peuvent être assimilées à des fonctionnalités que propose la
partie d’implémentation.
Package myobj.impl
Ce package est essentiellement constitué de la classe MyObjImpl qui implémente l’interface
MyObj. Cette classe doit fournir une implémentation concrète pour toutes les méthodes
12
2 MaDViWorld
framework classes
déclarées par l’interface. De plus, cette même classe hérite de la classe WObjectImpl, qui
implémente l’interface WObject du package core.
La Figure 2.3 présente un zoom sur l’interface MyObj et le package myobj.impl par rapport à
la Figure 2.2.
Tout le traitement (c’est-à-dire tous les calculs, tous les tests, toutes les données…) est réalisé
au sein de la partie d’implémentation, au cœur du package myobj.impl. Ainsi, l’exécution de
la partie d’implémentation se déroule soit sur la machine qui héberge la pièce et son objet, soit
sur la machine locale de l’utilisateur s’il le souhaite.
Le lecteur peut remarquer sur la Figure 2.2 que le package myobj.impl contient encore une
classe appelée MyObjRemoteEventListener. Cette dernière est utilisée lorsque l’objet
souhaite être informé d’événements provenant de la pièce qui le contient. Cela est plus
amplement expliqué dans la sous-section suivante 2.3.2.
«interface»
RemoteEventListener
WObjectGUIImpl
1
MyObjGUIImpl
1
1 1
MyObjPanel
javax.swing.JPanel
Figure 2.4: Aperçu du package myobj.gui
Package myobj.gui
Ce package correspond à la partie GUI (Graphical User Interface) d’un objet. Il faut rappeler
que l’utilisateur contrôle chaque objet à l’aide de son GUI. Ainsi, la partie GUI est
responsable de procurer l’interactivité avec l’avatar. Le package myobj.gui est illustré par la
Figure 2.4.
13
2 MaDViWorld
La première classe qui compose ce package est la classe MyObjGUIImpl qui hérite de
WObjectGUIImpl du package wobject (qui implémente l’interface WObjectGUI de core).
Cette classe instancie les classes MyObjRemoteEventListener et MyObjPanel.
La classe MyObjRemoteEventListener gère les événements à destination de la partie GUI de
l’objet. Cette classe est présentée plus en détails dans la sous-section suivante 2.3.2.
L’interface graphique réelle et concrète se trouve dans la classe MyObjPanel qui hérite de
javax.swing.JPanel, ce qui est l’unique contrainte. En effet, le créateur de l’objet est tout à
fait libre de concevoir son GUI à sa propre convenance pour autant qu’elle hérite de la classe
JPanel.
Finalement, le package myobj.gui peut inclure un répertoire nommé resources. Ce dernier
renferme tous les fichiers nécessaires au GUI : images, sons, vidéos, etc. Lorsque
l’application cliente transporte dynamiquement la partie GUI d’un objet de la machine room
server vers la machine de l’avatar, ce dossier est automatiquement transféré avec tout son
contenu.
Le framework MaDViWorld offre la possibilité d’avoir plusieurs parties GUI pour le même
objet, mais seulement une et une seule partie d’implémentation. En conséquence, à l’intérieur
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 numérotées de la même
manière. Par exemple, le package myobj.gui_2 peut contenir les classes MyObjGUIImpl_2,
MyObjPanel_2 et MyObjRemoteEventListener_2. L’application cliente permet à l’utilisateur
de choisir le GUI qu’il souhaite utiliser lorsque plusieurs sont à disposition.
2.3.2 Package event
Dans la Figure 2.1, il reste encore un package qui n’appartient ni à l’application 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 événements jouent un rôle essentiel au cœur du framework
MaDViWorld (cf. [7]). Chaque fois que l’état d’une composante du monde virtuel change, le
sujet affecté génère l’événement correspondant, qui est capté par tous ceux qui sont à l’écoute
de ce type d’événement, ce qui leur permet de réagir en fonction.
Basé sur le mécanisme événementiel de Java (cf. [4]), il offre les événements aux objets, aux
pièces et aux avatars. En effet, comme le monde virtuel est réparti sur une multitude de
machines, les événements doivent être propagés et reçus parmi différentes applications et
machines. Ainsi, le software framework MaDViWorld offre son propre mécanisme
événementiel à distance, son propre modèle événementiel distribué. A noter qu’il présente des
analogies avec le système d’événements distribués de Jini (cf. [10]).
Comme il existe une multitude d’objets, de pièces et d’avatars dans le monde virtuel, il faut
recourir à une identification unique si l’on souhaite adresser un événement à un élément en
particulier ou seulement à un certain groupe d’éléments. Ainsi le framework génère un
identifiant unique pour chaque objet, chaque avatar et chaque pièce (cf. [7]).
Evénements et objets
Le package event est composé de plusieurs classes. Par exemple, si ce package est utilisé
pour la création d’un objet, il suffit au programmeur de créer une classe
MyObjRemoteEventListener pour son objet myobj. Cette classe doit étendre
et
implémenter
l’interface
14
2 MaDViWorld
RemoteEventListener du package event. En bref, le développeur d’objet crée le code qui
gère
les
événements
que
reçoit
son
objet
à
l’intérieur
de
la
classe
MyObjRemoteEventListener.
Si la partie GUI d’un objet souhaite recevoir des événements, elle doit inclure un remote event
listener (MyObjRemoteEventListener) dans son propre package. Si un objet souhaite
recevoir des événements en provenance d’autres objets (communication inter-objets), il a
besoin d’un remote event listener2 (MyObjRemoteEventListener) dans le package de sa
partie d’implémentation.
Les événements possèdent des attributs qui peuvent être n’importe quel objet Java
sérialisable. Ainsi, ils ont la possibilité de contenir des informations, des données ou tout
autre chose que l’objet peut réutiliser.
Communication intra-objet
La séparation entre la partie d’implémentation d’un objet et sa partie GUI ne fournit pas une
communication bidirectionnelle entre les deux. La relation de clientèle entre la classe
MyObjGUIImpl et l’interface MyObj produit un canal de communication unidirectionnel (de la
partie GUI vers la partie d’implémentation), tandis que la partie d’implémentation est
incapable d’envoyer des informations à la partie GUI correspondante.
Cette lacune est comblée par le modèle événementiel distribué du framework (cf. [7]). En
effet, si la partie GUI d’un objet peut recevoir des événements (c’est-à-dire qu’elle possède un
remote event listener), la partie d’implémentation peut produire des événements afin de lui
envoyer des informations. Ainsi, une communication bidirectionnelle est établie entre les
deux parties constituantes d’un objet.
Les objets pourraient être classés en quatre catégories en fonction de leur utilisation des
événements :
•
Sans aucun événement;
•
Avec des événements entre l’objet et son GUI (communication intra-objet);
•
Avec des événements entre des objets identiques (communication inter-objets);
•
Avec des événements entre l’objet et son GUI et entre des objets identiques.
2
Les listeners seront ensuite enregistrés auprès de producteurs d’événements (remote event producer) tels que
les pièces, les avatars ou les parties d’implémentation des objets.
15
3 Objets développés pour MaDViWorld
3 OBJETS DÉVELOPPÉS POUR
MADVIWORLD
Le précédent chapitre a présenté le projet MaDViWorld et entre autre le package d’un nouvel
objet myobj. Le chapitre 3 présente les deux objets MaDViWorld concrets qui ont été
développés dans le cadre de ce travail. C’est sur la base de cette expérience de programmation
que doit être réalisé par la suite le guide du programmeur d’objets MaDViWorld. Les deux
objets sont les jeux du démineur et de la bataille navale.
Le lecteur peut trouver dans l’appendice A les outils qui ont été utilisés pour la
programmation de ces deux objets.
3.1 Démineur
Cette section présente le premier objet qui a été programmé dans le cadre de la partie de
programmation de ce travail : l’objet miner, c’est-à-dire le jeu du démineur.
3.1.1 But
L’objet miner représente une adaptation du jeu du démineur au framework logiciel
MaDViWorld. Il permet à un seul avatar de jouer, mais aussi à d’autres avatars de regarder la
partie en cours. De plus, pour gérer le jeu et les avatars, il emploie le mécanisme événementiel
du framework.
Règles du jeu
Ce jeu est destiné à un seul joueur, dont le but est de découvrir entièrement une grille truffée
de mines, qui y sont placées aléatoirement. Chaque fois que le joueur découvre une case, cette
dernière peut contenir une mine ; si tel n’est pas le cas, la case contient le nombre total de
mines qui se trouvent dans son voisinage proche (c’est-à-dire dans les huit cases qui
l’entourent, dans toute direction). Le joueur a la possibilité de marquer les emplacements des
mines à l’aide de drapeaux pour se souvenir de leur position. Le joueur termine la partie
lorsqu’il réussit à découvrir toute la grille ou lorsqu’il tombe sur une mine.
3.1.2 Structure
L’objet miner respecte la structure d’un objet MaDViWorld telle quelle a été présentée dans
la sous-section 2.3.1. Le package de l’objet porte le même nom que l’objet, à savoir miner et
contient l’interface Miner. En outre, les parties implémentation et GUI sont séparées dans
deux packages distincts, respectivement miner.impl et miner.gui.
Interface Miner
Cette interface hérite des interfaces core.WObject et java.rmi.Remote, comme sur la
Figure 2.2. Elle définit les méthodes que la partie GUI peut invoquer à partir de la partie
16
d’implémentation ; toutefois, l’interface ne fait que de déclarer les méthodes sans en fournir
une implémentation concrète, car cela est le rôle de la partie implémentation.
De plus, l’interface définit les différents types d’événements qui intéressent l’objet ; ces
derniers sont générés par la partie d’implémentation et sont récupérés par la partie GUI :
RESET, GAME_STARTED, GAME_OVER et FIELD_CLICKED.
Package miner.impl
Ce package correspond à la partie d’implémentation qui a la tâche de gérer le jeu, les avatars
et l’objet. Il est uniquement composé de la classe MinerImpl qui hérite de la classe
wobject.WObjectImpl.
Afin de gérer le déroulement du jeu, la partie implémentation a recours au mécanisme
événementiel fourni par le framework (cf. 2.3.2). Les types d’événements qu’utilise la classe
MinerImpl sont définis dans l’interface Miner et sont :
•
RESET : lorsque le joueur choisit de recommencer la partie depuis le début;
•
GAME_STARTED : lorsque le joueur a débuté la partie;
•
GAME_OVER : lorsque le joueur a terminé la partie;
• FIELD_CLICKED : lorsque le joueur a découvert ou marqué une case.
Comme l’objet miner n’accepte qu’un seul avatar comme joueur, les autres avatars (qui
exécutent le même objet et dans la même pièce que le joueur actif) sont automatiquement
spectateurs de la partie en cours. Ils restent informés ainsi de l’évolution de la partie grâce aux
événements présentés ci-dessus et qu’ils reçoivent.
Si le joueur quitte la partie en cours sans l’avoir terminée ou sans l’avoir réinitialisée, celle-ci
reste bloquée jusqu’à ce que le joueur revienne. En effet, la partie d’implémentation permet
au joueur actif de revenir dans la partie qu’il a préalablement quittée, pour lui permettre de la
terminer ou de la réinitialiser.
La classe MinerImpl sauvegarde le moment à laquelle la partie débute et à laquelle elle se
termine. Ainsi, le score est affiché en fin de partie dans un panneau d’information (cf.
Figure 3.2).
La partie d’implémentation a la faculté de sauvegarder et restaurer l’état de l’objet en cas de
destruction de l’objet, de crash de la machine qui héberge la pièce, etc. Ainsi, le joueur a la
possibilité de commencer une partie dans la pièce A, puis de déplacer l’objet de la pièce A
vers une pièce B et enfin de terminer la partie dans la pièce B. Cette aptitude est fournie par le
framework MaDViWorld.
Package miner.gui
L’interface graphique de l’utilisateur est définie dans ce package, qui contient trois classes :
•
La classe MinerGUIImpl (qui hérite de la classe wobject.WObjectGUIImpl) sert à
instancier les classes MinerRemoteEventListener et MinerGamePanel.
•
La classe MinerRemoteEventListener implémente l’interface RemoteEventListener
du package event et hérite de la classe java.rmi.server.UnicastRemoteObject. Elle
gère les événements destinés à la partie GUI de l’objet, et permet au GUI de réagir en
fonction des types d’événements reçus.
•
Le vrai et concret GUI est renfermé dans la classe MinerGamePanel qui hérite de la classe
javax.swing.JPanel.
17
Le GUI de l’objet miner comprend deux boutons (Start et Reset), une grille de jeu, un
chronomètre, un indicateur de drapeaux et un panneau d’information. La Figure 3.1 présente
la décomposition du GUI de l’objet miner.
Le GUI n’est 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
Chronomètre
Nombre de
drapeaux à
disposition
Panneau
d’information
Figure 3.1: Décomposition du GUI de l’objet miner
3.1.3 Bilan
L’objet miner, adaptation du jeu du démineur, se révèle être un objet concret de
MaDViWorld, car il respecte sa structure et use de plusieurs fonctionnalités qu’offre le
framework. Voici une énumération de ses principales caractéristiques :
•
Utilisation du mécanisme événementiel afin de gérer l’objet et les avatars;
•
Séparation entre les parties implémentation et GUI;
•
Possibilité de sauvegarder et restaurer l’état de l’objet;
•
Jeu du démineur 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 préalablement quittée;
•
Chronomètre et affichage du score;
•
Cohérence du chronomètre, même en cas de déplacement de l’objet vers une autre pièce
(le joueur ne peut arrêter le chronomètre lors d’une partie);
•
Marquage des mines à l’aide de drapeaux;
•
Utilisation d’images au format GIF.
18
Concernant cet objet, les améliorations suivantes sont possibles:
•
Indiquer le nombre d’observateurs;
•
Conserver dans une table les meilleurs scores des joueurs;
•
Personnaliser du jeu (taille de la grille, nombre de mines);
•
Découvrir automatiquement le voisinage d’une case sans mine;
•
Afficher une fenêtre d’aide offrant des indications sur la manière de jouer.
Case avec
une mine
Case vide,
avec 2
mines dans
son
voisinage
Case avec
un drapeau
Figure 3.2: Exemple de fin de partie pour l’objet miner
3.2 Bataille navale
Cette section présente le second objet qui a été programmé dans le cadre de la partie de
programmation de ce travail : l’objet battleship, c’est-à-dire le jeu de la bataille navale.
3.2.1 But
L’objet battleship représente une adaptation du jeu de la bataille navale au framework
logiciel MaDViWorld. L’évolution majeure par rapport au premier objet est que cet objet est
destiné à deux joueurs cette fois-ci. Bien sûr, il permet à d’autres avatars de regarder la partie
qui est en cours. Le mécanisme événementiel du framework est une nouvelle fois employé
pour gérer le jeu et les avatars. En outre, le second objet doit proposer un GUI plus élaboré,
plus sophistiqué que celui du premier objet.
19
Règles du jeu
Deux joueurs s’affrontent en tentant de couler la flotte de leur adversaire. Chaque joueur peut
disposer à son gré sur sa grille de défense les cinq bateaux qui composent sa flotte ; il s’agit
d’un porte-avions (d’une longueur de cinq cases), d’un croiseur (d’une longueur de quatre
cases), d’un destroyer (d’une longueur de trois cases), d’un sous-marin (d’une longueur de
trois cases) et d’une vedette (d’une 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, c’est-à-dire les navires sur la grille défensive de l’adversaire. Le premier joueur qui
réussit à coulé tous les bateaux de son adversaire remporte la partie.
3.2.2 Structure
L’objet est composé du package intitulé battleship, qui renferme l’interface BattleShip et
les packages battleship.impl et battleship.gui.
Interface BattleShip
Elle déclare les méthodes (ou les fonctionnalités) qui sont à disposition de la partie GUI. Pour
ce faire, elle hérite des interfaces core.WObject et java.rmi.Remote.
L’interface BattleShip définit encore les types d’événements que peut recevoir l’objet, qui
sont : RESET, GAME_INIT, GAME_STARTED, GAME_OVER et ATTACK.
Package battleship.impl
La partie d’implémentation a pour tâche de gérer le jeu, les avatars et l’objet. Le package
battleship.impl est uniquement composé de la classe BattleShipImpl qui hérite de la
classe wobject.WObjectImpl.
La partie implémentation use du mécanisme événementiel du framework (cf. 2.3.2) dans le
but d’informer les joueurs et les autres avatars de l’état et du déroulement de la partie. Les
types d’événements qu’utilise la classe BattleShipImpl sont définis dans l’interface
BattleShip et sont générés dans les situations suivantes :
•
RESET: lorsque le joueur actif, à qui c’est le tour de jouer, choisit de réinitialiser la partie;
•
GAME_INIT: lorsque deux avatars se sont enregistrés comme joueurs, de telle sorte que
chacun peut positionner sa flotte;
•
GAME_STARTED: lorsque les deux joueurs ont terminé de placer leurs navires et qu’un 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: lorsqu’un des joueurs attaque son adversaire.
Chaque joueur possède ses propres grilles de défense et d’attaque. Sur la grille de défense est
disposée non seulement sa flotte, mais aussi les tentatives fructueuses ou infructueuses de son
adversaire. Quant à sa grille d’attaque, elle contient ses propres tirs.
Comme le jeu de la bataille navale n'autorise que deux avatars comme joueurs, les autres
avatars (qui exécutent le même objet dans la même pièce) sont automatiquement spectateurs
de la partie en cours ; en effet, ces derniers voient la grille d’attaque de chaque joueur, au lieu
d’une grille de défense et une grille d’attaque comme à l’accoutumé pour les joueurs.
20
Si un des joueurs (voire tous les deux) quitte la partie en cours sans l’avoir terminée ou sans
l’avoir réinitialisée, celle-ci demeure bloquée jusqu’à ce que ledit joueur revienne. Les
joueurs ont la possibilité de revenir dans la partie qu’ils ont préalablement quittée. 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 début.
La partie d’implémentation a la faculté de sauvegarder et restaurer l’état de l’objet en cas de
destruction de l’objet, de crash de la machine qui héberge la pièce, etc. Ainsi, le joueur a la
possibilité de commencer une partie dans la pièce A, puis de déplacer l’objet de la pièce A
vers une pièce B et enfin de terminer la partie dans la pièce B. Cette aptitude est fournie par le
framework MaDViWorld.
Package battleship.gui
Ce package contient l’interface graphique de l’utilisateur (GUI) et est composé des quatre
classes suivantes :
•
La classe BattleShipGUIImpl (qui hérite de la classe wobject.WObjectGUIImpl) sert à
instancier les classes BattleShipRemoteEventListener et BattleShipPanel.
•
La
classe
BattleShipRemoteEventListener
implémente
l’interface
RemoteEventListener
du
package
event
et
hérite
de
la
classe
java.rmi.server.UnicastRemoteObject. Elle gère les événements destinés à la partie
GUI de l’objet, et lui permet de réagir en fonction des types d’événements reçus.
•
La classe BattleShipPanel hérite de la classe javax.swing.JPanel. Elle construit le
GUI de l’objet, notamment à l’aide de la classe GridPanel.
•
La classe GridPanel est la composante principale du GUI, car elle contient le panneau de
jeu renfermant les grilles de défense et d’attaque, ainsi que le panneau servant à placer les
bateaux sur la grille de défense.
Le GUI n’est pas défini dans une classe unique, mais dans deux classes distinctes :
BattleShipPanel et GridPanel. En effet, comme la gestion et l’affichage du panneau de jeu
sont relativement longs et complexes (positionnement des bateaux, calcul des coordonnées,
affichages des tirs, etc), cette partie de l’interface a donc été séparée 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 créer le panneau de jeu.
Sur la Figure 3.3, il est possible de distinguer les deux parties du GUI appartenant chacune à
une classe différente ; les éléments en orange appartiennent à la classe GridPanel, tandis que
ceux en violet à la classe BattleShipPanel.
Revenons plus en détail sur la décomposition du GUI de l’objet battleship, illustrée par la
Figure 3.3. Les principales composantes sont les panneaux de jeu, de positionnement des
navires et d’attaque, qui tous sont partie intégrante 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
représentés dans la grille de défense sous forme d’images, comme le démontre la Figure 3.4.
Ensuite, le reste du GUI concerne la classe BattleShipPanel. Il s’agit des boutons Start,
Reset, ? (fenêtre d’aide) et About… (fenêtre d’information sur l’objet battleship), des labels
Player 1 (nom du 1er joueur), Player 2 (nom du 2ème joueur) et Observers (nombre total actuel
de spectateurs), ainsi que d’un panneau d’information où sont diffusés à l’avatar différents
messages. Finalement, le dernier élément du GUI est une case à option intitulée Sound enable.
21
Cette dernière composante est intéressante, car elle permet d’activer ou de désactiver les sons.
En effet, le GUI (et plus particulièrement la classe BattleShipPanel) intègre et utilise des
sons pour conférer au jeu un aspect plus ludique et plus convivial. Ces derniers, comme les
images, se trouvent dans le répertoire resources du package battleship.gui et sont joués
dans les situations suivantes :
•
Hit.wav: lorsqu’un tir touche un bateau;
•
Splash.wav: lorsqu’un tir atterrit dans l’océan, sans toucher un bateau;
•
Bomb.au: lorsqu’un navire est coulé après un tir;
•
Gameover.mid: lorsque le jeu est terminé, c’est-à-dire quand un joueur a coulé la flotte
ennemie.
Les joueurs ont la possibilité de revenir dans une partie qu’ils ont préalablement quittée, ce
qui inclut de réafficher les bateaux (ou plutôt les images des bateaux) tels qu’ils étaient
positionnés dans leur grille de défense, avant leur départ, ainsi que les différents tirs effectués.
Hélas, les coordonnées des images des navires ne sont pas sauvegardées lorsque le joueur
quitte le jeu. Donc, il est nécessaire d’avoir un mécanisme de repositionnement des images
par rapport aux navires dans la grille de défense ; un tel mécanisme est inclus dans la classe
GridPanel.
Panneau de placement des
bateaux et d’attaque
Panneau de jeu
Panneau
d’information
Bouton
Start
Bouton
d’aide
Bouton Reset
Nom du 1er
joueur
Nom du
2ème joueur
Case à option
pour le son
Nombre de
spectateurs
Bouton
d’information
Figure 3.3: Décomposition du GUI de l’objet battleship
3.2.3 Bilan
L’objet battleship adapte le jeu de la bataille navale en tant qu’objet concret du
frameworkd MaDViWorld. Voici une énumération de ses principales caractéristiques :
•
Utilisation du mécanisme événementiel afin de gérer l’objet et les avatars;
22
•
Séparation entre les parties implémentation et GUI;
•
GUI complet et évolué;
•
Possibilité de sauvegarder et restaurer de l’état de l’objet;
•
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 préalablement quittée avec le
réaffichage de leurs bateaux;
•
Affichage du nombre d’observateurs;
•
Mise à disposition d’une fenêtre d’aide pour le placement des bateaux;
•
Utilisation d’images aux formats JPEG et GIF.
•
Utilisation de sons aux formats WAV, MID et AU.
Concernant cet objet, les améliorations suivantes sont encore possibles:
•
Personnalisation du jeu (taille de la grille, nombre de bateaux);
•
Ajustement du GUI à la taille souhaitée par l’utilisateur (agrandissement ou réduction
automatique du panneau de jeu et des ses images);
•
Affichage des bateaux coulés.
Tir ennemi dans l’eau
Dernier tir ennemi
Porte-avions
Navire "touché"
Cible actuelle
Coordonnées de la cible
Figure 3.4: Exemple d’une partie pour l’objet battleship
23
Tir dans "l’eau"
Tir "touché"
4 Guide du programmeur d’objets MaDViWorld
4 GUIDE DU PROGRAMMEUR
D’OBJETS MADVIWORLD
Grâce à l’expérience acquise en programmant les deux objets présentés dans le précédent
chapitre, le but principal de ce travail est la conception et la réalisation d’un guide du
programmeur pour des objets MaDViWorld.
Le chapitre 4 présente tout d’abord 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 d’instruire des programmeurs sur la création d’objets compatibles
avec le projet MaDViWorld. Il doit donc être accessible pour toutes sortes de programmeurs,
expérimentés ou non, et il se doit de présenter clairement le projet MaDViWorld.
Le guide du programmeur doit également remplir plusieurs exigences quant à son contenu, sa
forme, sa lisibilité, etc.:
•
Présentation du projet MaDViWorld;
•
Description du concept d’objet dans MaDViWorld;
•
Illustration du concept d’objet avec des exemples concrets et détaillés sous forme de
tutorial;
•
Version imprimable du guide;
•
Clarté, lisibilité et efficacité du guide;
•
Sobriété esthétique du guide;
•
Guide électronique, en ligne sur internet;
•
Guide indépendant du type de navigateur;
•
Accessibilité du guide;
•
Rédaction du guide en anglais.
Toutes ces exigences déterminent l’audience, le contenu, la fonctionnalité, le design et la mise
en page du guide et de son site, de telle sorte qu’elles vont influencer les choix et décisions
qui interviennent dans la conception et la réalisation du guide.
4.2 Design du guide
Afin de réaliser l’objectif du guide et d’en remplir les exigences, il n’existe pas une
méthodologie bien définie et établie, mais une multitude qui peuvent être complémentaires ou
24
opposées. Comme il est impossible de toutes les satisfaire, il s’agit de faire les choix les plus
pertinents et les plus appropriés en vue de la réalisation du guide du programmeur d’objets.
Diverses méthodologies et considérations pour la création d’un site internet sont présentées
dans [1], [11], [12] et [18].
4.2.1 Convivialité et accessibilité
Le guide du programmeur d’objets MaDViWorld est destiné à une large audience et de ce fait
il doit être accessible par tous.
Une définition de l’accessibilité du contenu d’un site ainsi que des techniques associées se
trouvent dans [15], [17] et [18]. Voici en résumé les primordiaux critères :
•
D’abord, le guide doit supporter tout type de navigateur, récent ou moins récent, 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 indépendamment des polices et des tailles utilisées sur les
machines des internautes. Par exemple, les unités de mesures changent d’un système
d’exploitation à l’autre. Donc, il est important de recourir à des unités de mesure et des
polices standard aux différentes 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 décourager les visiteurs qui usent
d’un navigateur textuel.
•
Il est important de séparer au maximum la présentation des pages de leur contenu. Les
documents sont alors de plus petite taille, donc plus rapide d’accès. La présentation des
pages est contrôlée à l’aide de feuilles de style qui peuvent s’appliquer pour un site entier.
Il y a un gain énorme de temps lorsqu’il s’agit de faire une modification dans une feuille
de style qui va affecter la présentation de tous les documents, au lieu de modifier tous les
documents les uns après les autres.
•
Enfin, le site doit fournir un mécanisme de navigation clair et consistant, pour que le
visiteur ait de la facilité à rechercher les informations souhaitées (cf. 4.2.3 Navigation).
Tous les points présentés ci-dessus peuvent être considérés comme des exigences ou des
contraintes dont il est nécessaire de tenir compte non seulement dans la conception du guide
du programmeur d’objets MaDViWorld, mais surtout dans sa réalisation.
4.2.2 Conception
Tout d’abord, il est nécessaire de déterminer quelle va être l’apparence générale du guide.
Il ne faut pas oublier le fait qu’une page internet est à la merci des logiciels et de la
configuration matérielle de chaque utilisateur. Par exemple, une page peut sembler superbe
sur une machine et totalement différente, voire même affreuse, sur une autre. Cela est dû aux
fonctionnalités des navigateurs et aux préférences de l’utilisateur en ce qui concerne les
polices, les couleurs, la taille, etc.
Afin d’assurer une visibilité adéquate à chaque visiteur indépendamment de sa machine et de
sa configuration, il est nécessaire de définir des conditions dans lesquelles l’utilisateur va
visiter le guide.
25
Résolution d’écran
Les fenêtres des navigateurs peuvent être redimensionnées dans n’importe quelle dimension,
qui est seulement limitée par la résolution de l’écran. Donc, la taille d’écran influence
évidemment la visibilité d’une page au travers de la résolution qu’utilise l’internaute.
Il existe plusieurs tailles d’écrans comme 15, 17, 19, 20 et 21 pouces. A ces tailles
correspondent diverses résolutions d’écran, qui limitent le nombre de pixels disponibles pour
l’affichage ; voici les plus fréquentes : 640x480, 800x600, 1024x768, 1280x1024,
1600x1200.
De plus, la résolution d’écran est aussi caractérisée par la carte graphique de l’ordinateur, plus
particulièrement par les possibilités techniques de cette dernière. Ainsi, une carte graphique
peut proposer différentes résolutions d’écran.
Dès lors, il faut délimiter la partie minimale visible par l’utilisateur afin de réserver au guide
une surface d’affichage dépourvue d’erreur, de distorsion, d’inconsistance. Connaître la taille
de l’écran n’est pas encore suffisant, car le système d’exploitation et le navigateur occupent
une bonne part de l’écran. Ainsi, la partie visible dédiée à l’affichage du guide se restreint
fortement. Il est obsolète de considérer une résolution d’écran de 640x480 pixels pour le
guide, car cette dernière est largement trop étroite et trop réductrice. Par contre, il paraît
judicieux de choisir une résolution de 800x600 pixels comme zone minimale d’affichage du
guide.
Mise en page
Comme il est évident que les internautes ne se contentent actuellement pas seulement d’une
résolution d’écran 800x600 pixels, mais plutôt 1024x768 ou supérieure, il est nécessaire de
pouvoir adapter la page internet à la configuration de l’utilisateur.
Si la mise en page d’une page est fixe, il est certes plus facile d’en contrôler le contenu et
l’apparence. Cependant, plus l’utilisateur utilise une résolution élevée, plus il y a d’espaces
non-utilisés et perdus.
Donc, il est préférable d’ajuster automatiquement les pages du site de telle manière qu’elles
soient affichées correctement sur n’importe quel type d’écran et avec n’importe quelle
résolution (pour autant que cette dernière respecte la limite inférieure de 800x600 pixels). On
parle alors de pages fluides.
Ainsi, le design du guide doit être flexible pour permettre à tout utilisateur de le parcourir
indépendamment de son navigateur, de son écran et de sa configuration matérielle.
Frames
Obtenir une mise en page et un contenu flexible requiert l’utilisation de mesures relatives
pour les éléments des pages, afin qu’ils 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 créer des colonnes de texte et de diviser une page en plusieurs
sections. En utilisant des mesures relatives (en l’occurrence des pourcentages), les
tableaux s’adaptent à la fenêtre du navigateur en garantissant que les colonnes et les
éléments du tableau restent proportionnels.
•
Les cadres (en anglais frames) sont utilisés pour conférer une structure à un design
flexible. En effet, ils divisent la fenêtre du navigateur en plusieurs sous-fenêtres, qui
peuvent afficher différents contenus. Ces sous-fenêtres peuvent être créées à l’aide de
mesures proportionnelles pour conserver la flexibilité du site.
26
Les deux techniques sont utiles, d’une part, les cadres structurent la fenêtre du navigateur afin
de pouvoir afficher simultanément plusieurs pages ou éléments, et d’autre part, les tableaux
structurent logiquement le contenu de chacune des pages.
L’utilisation des cadres comporte les avantages suivants :
•
Division de la fenêtre du navigateur pour afficher plusieurs pages;
•
Diminution de la taille des pages;
•
Possibilité de changer une partie de la fenêtre sans en changer les autres;
•
Possibilité de faire défiler une partie sans déplacer en même temps les autres parties.
Bien sûr, les cadres apportent les inconvénients suivants :
•
Gestion plus difficile de la structure et des documents du site;
•
Difficulté de navigation pour certains utilisateurs;
•
Difficulté de créer un raccourci vers un document contenu à l’intérieur d’un ensemble de
cadres;
•
Augmentation de la charge du serveur en cas de nombreuses requêtes pour des documents
constitués de cadres;
•
Incompatibilité avec certains navigateurs.
Dans le but de fournir un guide agréable à visiter, les cadres sont une bonne solution, mais il
est nécessaire d’en limiter les inconvénients avec les trois propositions suivantes :
1. Le nombre de cadres contenu dans une fenêtre est limité à trois : d’abord un cadre
supérieur, puis un cadre du côté gauche et enfin un cadre principal. Ainsi, la charge du
serveur hébergeant le site est réduite, ce qui lui permet d’assurer une vitesse optimale pour
l’exécution des requêtes des documents.
2. Tout document affiché dans la partie centrale du navigateur est référencé par une page
unique pour permettre à l’utilisateur de créer un raccourci sur ce document.
3. Si le navigateur de l’utilisateur ne supporte pas les cadres, l’internaute est redirigé vers
une version sans cadre du document qu’il recherche.
En ce qui concerne les trois cadres, voici une brève description de chacun :
•
Le cadre supérieur accueille le titre du site (en l’occurrence MaDViWorld Object
Programmer’s Guide), un lien vers la page d’accueil, un lien vers le plan du site (cf. 4.2.3
Plan du site), un lien permettant d’envoyer un message au responsable du projet
MaDViWorld et un lien permettant d’accéder à la version imprimable du site. Ce cadre
reste identique pour tous les documents du site.
•
Le cadre de gauche est dédié à la navigation et aux menus (cf. 4.2.3 Navigation).
•
Le dernier cadre est le lieu où sont affichés les documents du site.
La Figure 4.1 présente un aperçu de la page d’accueil du guide, ainsi que sa décomposition en
trois cadres.
27
Figure 4.1: Aperçu de la page d’accueil du site
4.2.3 Navigation
Pour visiter un site, l’utilisateur a besoin d’une aide visuelle, de repères pour parcourir les
pages qui composent le site ; cela est réalisé par les moyens de navigation qui lui sont
proposés tels que des menus, des icônes, 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
compréhensible par les visiteurs. Ainsi, ce regroupement sous la forme de menus rend la
navigation plus intuitive et facilite la recherche d’informations.
De plus, il est nécessaire d’instruire l’utilisateur sur les aides à la navigation qui sont à sa
disposition pour parcourir le site ; cela est assumé par la page d’accueil du site comme le
montre la Figure 4.1.
Les aides à la navigation du site sont présentés dans les trois paragraphes qui suivent.
Menus
Comme le contenu du guide est décomposé en rubriques, il est possible d’y associer pour
chacune un menu. De plus, comme le guide est construit hiérarchiquement, c’est-à-dire, à
28
l’aide de chapitres, de sections et de sous-sections, il faut respecter cette hiérarchisation
également dans la construction des menus du guide, afin que la navigation demeure cohérente
pour l’utilisateur.
Les menus (et ses sous-menus) de navigation sont situés dans le côté gauche de la fenêtre du
navigateur de telle manière à être rapidement accessible. Pour un meilleur aperçu global du
contenu des rubriques, toutes les sections sont également visibles.
Chaque fois que l’utilisateur clique sur une section, celle-là se développe et affiche les soussections qui la composent le cas échéant.
La Figure 4.2 présente le cadre gauche contenant les menus de navigation ; cette figure
permet également de présenter le contenu du guide du programmeur d’objets MaDViWorld.
Figure 4.2: Menus de navigation
Navigation interne
Pour faire gagner du temps au visiteur, chaque document du cadre central contient un système
de navigation interne. Cette dernière est constituée de différents liens vers les autres
documents :
•
Un lien vers le précédent document
•
Un lien vers le prochain document
•
Un lien vers le haut du courant document
•
Un lien vers la page d’accueil du guide
29
De plus, les liens vers les documents suivants et précédents sont dédoublés, une fois dans
l’en-tête du document principal et une fois à la fin du document.
Plan du site
En complément à la navigation du site se trouve un plan du site qui présente l’arborescence
globale du site, autrement dit de son contenu.
Ce plan est accessible à droite du cadre supérieur sous la forme du lien hypertexte intitulé
Sitemap (voir Figure 4.1).
4.3 Programmation du site
Il s’agit de passer à la création du guide et de son site, tout en respectant les diverses
exigences de la section 4.1 et les considérations présentées dans la section 4.2.
Pour y parvenir, cette section expose tout d’abord la structure du site, puis les techniques qui
ont été utilisées pour la programmation du site, et enfin les tests de compatibilité de divers
navigateurs.
4.3.1 Structure du site
Le site est décomposé en plusieurs répertoires contenant diverses catégories d’éléments. Ces
répertoires sont par ordre alphabétique :
•
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 deuxième chapitre.
•
Le dossier chapter3 contient celles du troisième chapitre.
•
Le dossier code renferme le code source de chaque exemple qui est présenté dans le
tutorial du guide.
•
Les feuilles de styles utilisées dans le site se situent dans le dossier css.
•
Le dossier download possède les éléments qui sont téléchargeables, tels que des objets du
projet MaDViWorld (sous forme d’archives 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 s’agit de toutes les
informations qui sont affichées 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 élaborés pour le site.
Ainsi, la décomposition du site en plusieurs parties permet de regrouper les éléments selon
leurs fonctionnalités afin d’en améliorer la gestion, l’utilisation et la maintenance.
30
4.3.2 Avantages
Cette structure permet de résoudre deux problèmes présentés précédemment : les raccourcis
vers une page donnée malgré l’utilisation de frames et la gestion de navigateurs ne supportant
pas les frames.
Raccourcis
Dans la section 4.2.1 et son paragraphe dédié aux frames, il a été remarqué que l’utilisation de
cadres dans un site internet empêche le visiteur de créer un raccourci sur un document
contenu dans un cadre. Cependant, les principaux navigateurs dans leurs versions les plus
récentes permettent d’outrepasser cette restriction et offrent la possibilité de créer un
raccourci pour tout document affiché dans une page web. Malgré cela, ce n’est pas le cas des
navigateurs moins récents ou de plus faible notoriété. Donc, il est nécessaire de remédier à ce
manque afin d’assurer une accessibilité totale au site, sans que l’utilisateur doive passer par
une mise à jour de son navigateur.
•
Ainsi, à chaque document qui est affiché dans le cadre central est associée sa propre page
web afin de pouvoir créer un raccourci sur ledit document. C’est pourquoi dans la
structure du site les pages des différents chapitres (les dossiers chapter1, chapter2,
chapter3 et appendices) sont séparées de leurs contenus (le dossier frames). En effet,
cette page web renferme non seulement une référence vers son contenu, mais aussi des
références vers les menus correspondants et vers le cadre supérieur.
La principale conséquence de cette solution est que la gestion du site s’alourdit et que le
nombre de requêtes de pages est plus élevé du côté du serveur. Cependant, cette dernière
remarque est atténuée par les constatations suivantes :
•
D’une part, un tiers des requêtes concerne une demande d’une page internet contenant le
cadre supérieur. Comme ce dernier demeure toujours identique, la page web
correspondante se trouve alors dans le tampon du navigateur après son premier
téléchargement, ce qui la rend immédiatement accessible.
•
D’autre part, le deuxième tiers des requêtes est destiné à obtenir la page web qui contient
les menus de navigation, c’est-à-dire le cadre situé à gauche. Hors, les menus de
navigations sont presque tous semblables, seuls certains menus associés à une section sont
susceptibles de changer. Donc, le nombre de trafic lié à la requête du cadre des menus
n’augmente que très peu.
Cadres
La solution possède un avantage majeur dans le fait que pour chaque document il est possible
d’en définir une nouvelle version n’usant pas de cadres. En l’occurrence, l’utilisateur qui
utilise un navigateur sans cadre est redirigé vers le document principal, dépourvu du cadre
supérieur et du cadre des menus.
4.3.3 Technologies
Cette sous-section présente les outils, les techniques et les langages utilisés dans la phase de
programmation du site.
La liste des logiciels et outils qui ont été employés est disponible dans la section Software de
l’appendice A.
31
HTML
Le langage HTML (Hypertext Markup Language) est utilisé pour créer et structurer des
documents web à l’aide de balises, ce qui permet aux navigateurs d’afficher le contenu des
pages internet.
Comme tout langage, il existe plusieurs versions de HTML et le dernier standard développé
par le World Wide Web Consortium (W3C) est HTML 4.01 (cf. [16]). La principale
caractéristique de cette spécification par rapport aux précédentes versions est l’effort fourni
afin de séparer la structure des documents de leurs présentations. Ainsi, la mise en page des
documents est conférée aux feuilles de style, qui s’occupent uniquement de l’aspect et de la
présentation des documents.
La spécification HTML 4.01 est déclinée en trois différentes versions, qui définissent chacune
les balises, les attributs et leurs règles d’utilisation :
1. HTML 4.01 Strict Document Type Definition (DTD) exclue toutes balises et attributs
obsolètes ; cette version est la plus restrictive et ne contient plus aucun élément de mise en
page.
2. HTML 4.01 Transitional DTD est moins restrictive que la première, car elle accepte les
balises et attributs obsolètes, afin d’assurer la compatibilité avec les navigateurs moins
récents qui ne supportent pas encore l’utilisation de feuilles de style.
3. HTML 4.01 Frameset DTD est identique à Transitional DTD, sauf qu’elle permet
l’utilisation de cadres (frames) dans les pages web.
HTML 4.01 est le langage choisi pour programmer le guide du programmeur d’objets
MaDViWorld. Dès lors, les pages requérant 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é contrôlées et validées comme
réalisatrices de la norme HTML 4.01. La conformité à HTML 4.01 est affiché sur la page
d’accueil du site sous la forme d’une image fournie par W3C, illustrée 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 présentation du site : les feuilles de style. Ces dernières offrent la possibilité
d’appliquer des styles et des instructions de mise en page pour tout élément d’une page web.
L’utilisation des feuilles de style procure les avantages suivants :
•
Un plus grand contrôle de la typographie et de la mise en page, tels que les polices de
caractères, leur taille, leur alignement, les marges, le positionnement, etc.
•
Séparation 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 facilitée, car il est possible de lier plusieurs pages HTML à une seule
feuille de style.
32
La technique des feuilles de style est définie par le langage CSS (Cascading Style Sheets)
développé par W3C. La version de CSS employée dans le site est le standard CSS Level 2 (cf.
[14]).
Toujours dans l’optique de supporter le maximum de navigateurs (aussi bien les plus récents
que les moins récents), deux feuilles de style ont été créées et sont localisées dans le répertoire
css du site :
1. Le fichier simplestyles.css contient tous les styles destinés aux plus anciens
navigateurs, afin d’offrir une présentation basique, claire et lisible du site.
2. Le fichier mystyles.css contient des styles plus élaborés dans le but d’améliorer la
présentation du site sur des navigateurs récents.
En outre, ces deux feuilles de styles ont été soumises avec succès au test de validité de la
norme CSS Level 2 fourni par le W3C. Cette information est également affichée sur la page
d’accueil du site, au côté de la validation HTML 4.01 ; la Figure 4.4 présente l’image attestant
de la conformité à la norme CSS.
Figure 4.4: Standard CSS
JavaScript
Le langage JavaScript est un langage de script côté client qui permet de contrôler différents
aspects des navigateurs. Par exemple, il est possible d’afficher des informations
supplémentaires aux liens hypertextes, de créer de nouvelles fenêtres ou de changer le
contenu des pages.
Ce langage permet entre autre de détecter les navigateurs et leurs versions. Cette particularité
est fort intéressante dans le cas du guide du programmeur d’objets ; elle permet de choisir les
feuilles de style à appliquer pour la présentation du site en fonction du type de navigateur
qu’utilise l’internaute.
Le script détectant le type et la version du navigateur s’intitule 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 dernière, référencent une des deux feuilles de style. Ainsi, le navigateur
utilise simplestyles.css ou mystyles.css afin de déterminer la présentation des
pages.
•
Les scripts windowstate.js et windowfull.js s’occupent d’ouvrir une nouvelle fenêtre
respectivement soit en précisant les dimensions, soit en plein écran selon la taille et la
résolution d’écran disponibles.
•
Le dernier script intitulé effect.js est étroitement corrélé à une fonctionnalité propre à
Internet Explorer 5.5 et version supérieure ; cette fonctionnalité offre plusieurs effets de
transition entre chaque page. Dans le cas de ce script, il s’agit d’un effet de fondu
enchaîné où la vieille page s’efface pour laisser la place à la nouvelle.
4.3.4 Tests de compatibilité
Une fois le site réalisé à l’aide des technologies présentées dans la sous-section précédente, il
faut le mettre à l’épreuve de nombreux navigateurs. C’est la seule manière de tester la
compatibilité du site avec les navigateurs existants.
33
Pour ce faire, il est nécessaire de choisir non seulement plusieurs types et versions de
navigateurs, mais aussi diverses plate-formes. Puis, les critères de compatibilité sont basés 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é employées pour la construction du site. En effet, ces
dernières assurent une compatibilité avec les navigateurs qui ne supportent pas le standard
HTML 4.01 ou seulement une version antérieure.
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 l’utilisation des feuilles
de style CSS. La seule incohérence qui est survenue lors des tests est que certains navigateurs
alignent quelque peu différemment 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 cohérent et
compréhensible.
Le tableau de la Figure 4.5 résume les résultats des tests de compatibilité.
Plateforme
Caractéristiques du site
Navigateur
HTML
Frames Javascript CSS
4.01
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
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
Remarque
listes à puces déplacées
listes et tableaux déplacés
-
Figure 4.5: Résultats des tests
Les configurations des machines sur lesquelles les tests ont été effectués se trouvent dans la
section Hardware de l’appendice A.
1
Navigateur ne supportant pas les cadres.
2
Navigateur purement textuel.
34
4.4 Bilan
Le site du guide du programmeur d’objets MaDViWorld répond aux principaux critères
d’accessibilité (cf. 4.2.1). En bref, il supporte tout type de navigateurs, les plus récents comme
les moins récents :
•
La présentation s’adapte automatiquement selon les navigateurs.
•
La mise en page flexible que procurent les tableaux et les cadres permet d’afficher le site
dans n’importe quelle fenêtre de navigateur, pour autant qu’il y ait un espace de 800x600
pixels à disposition.
•
La présentation du site est séparée de son contenu grâce aux feuilles de style. Ces
dernières assurent une présentation du contenu cohérente et lisible en recourant à des
unités de mesure et des polices standard aux différentes plate-formes.
•
Les trois mécanismes de navigation à savoir les menus, la navigation interne et le plan du
site dotent le site d’une 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 l’appendice C.
35
5 Conclusion
5 CONCLUSION
Le chapitre 5 sert de conclusion à ce document en dressant le bilan du travail et en présentant
les améliorations envisageables. Il contient également une critique du software framework
MaDViWorld.
5.1 Bilan du travail
5.1.1 Réalisation
L’objectif de ce travail était dédoublé de la manière suivante :
•
Dans un premier temps, programmer deux objets pour MaDViWorld afin de s’imprégner
de l’utilisation du framework.
•
Dans un second temps, fort de l’expérience acquise, concevoir et réaliser le guide du
programmeur d’objets.
Il a été montré, tout au long de cette documentation, que les buts évoqués ci-dessus ont été
atteints.
Tout d’abord, les deux objets programmés ont été des adaptations au framework
MaDViWorld des jeux du démineur et de la bataille navale. Le premier est conçu pour un seul
avatar, tandis que le second pour deux avatars ; cependant, tous les deux acceptent d’autres
avatars en qualité de spectateurs. De plus, ces deux objets respectent les caractéristiques d’un
objet MaDViWorld: séparation des parties implémentation et GUI, sauvegarde et restauration
de l’état interne de l’objet, communication intra-objet à l’aide du mécanisme événementiel
distribué offert et utilisation de ressources diverses (images, voire même sons). En résumé,
tous deux illustrent les principales qualités que confère le framework à ses objets.
Le site du guide du programmeur d’objets MaDViWorld remplit entièrement sa fonction en
présentant tout d’abord MaDViWorld, puis son architecture, ensuite le concept d’objet 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é rédigé intégralement en anglais
afin de toucher un large public. Pour ce faire, il est doté d’un design flexible (utilisation de
cadres et de tableaux) et d’un mécanisme varié d’aide à la navigation pour le rendre convivial.
En outre, sa structure est séparée de sa présentation grâce à l'usage du standard HTML 4.01 et
des feuilles de style CSS. Ainsi, le site adapte sa présentation et sa mise en page selon les
navigateurs récents ou moins récents par l’intermédiaire des scripts Javascript. En d’autres
termes, le site du guide du programmeur d’objets se révèle accessible à un large public et
compatible pour tout type de navigateurs.
5.1.2 Améliorations
Concernant les deux objets programmés dans le cadre de ce travail, il reste encore maintes
améliorations possibles, qui ont été présentées dans le chapitre 3.
36
5 Conclusion
Le site du guide du programmeur d’objets propose accessibilité, convivialité et cohérence tel
qu’il a été montré dans le chapitre 4. Cependant, le guide peut être amélioré sur les plans
interaction et méthodologique. Une bonne idée serait d’inclure quelques animations que le
lecteur pourrait lancer afin de présenter certaines caractéristiques du framework ou certaines
étapes du tutorial ; le site pourrait inclure des animations sous forme d’applets ou d’images
animées. De la sorte, le lecteur deviendrait plus qu’un simple lecteur et serait plus actif.
5.2 Critique du framework
5.2.1 Points forts
Quant au framework logiciel MaDViWorld, il possède les points forts suivants:
•
La création d’objets est simple et peu contraignante ; il suffit de respecter un nombre
restreint de règles, comme la séparation entre le GUI et l’implémentation, l’obligation du
GUI d’hériter de la classe javax.swing.JPanel… (cf. 2.3.1). Le programmeur est
totalement libre de façonner les objets selon ses désirs et ses souhaits.
•
Le framework logiciel est extensible par le fait qu’un programmeur puisse non seulement
créer ses propres objets, mais également repenser l’application cliente, voire même définir
de nouvelles sortes de pièces.
•
De plus, l’avatar a la capacité d’interagir avec les objets et les autres avatars présents dans
la pièce de manière simple et intuitive. Tout ce qui se passe derrière reste pour lui
transparent. Par exemple, lorsqu’il veut déplacer un objet vers une autre pièce, il le met
dans son "sac" et change de pièce.
•
Le monde virtuel se base sur une architecture entièrement distribuée composée d’un
nombre arbitraire de machines, faisant partie aussi bien d’un réseau local que d’Internet et
sans recourir à un système de serveur centralisé. Dans ce domaine, MaDViWorld use des
avantages des dernières technologies RMI et Jini.
•
Les applications sont de leur côté peu gourmandes en ressources et ne nécessitent pas de
machines dédiées ou spécifiques à leur utilisation. Par exemple, l’application room server
utilise le mécanisme d’activation d’objets distants fourni par RMI (cf. [3] et [9]).
•
Un des principaux points forts de MaDViWorld réside dans son modèle d’événement
distribué. En effet, son mécanisme événementiel distribué est utilisable à tous les niveaux
qui composent le framework logiciel, car il est non seulement simple d’utilisation mais
également efficace et très avantageux.
•
Le framework offre encore un mécanisme de sauvegarde et de restauration automatique
permettant de remédier aux éventuels "crashs" des machines hébergeant les pièces. Il
présente ainsi persistance et robustesse.
5.2.2 Extensions souhaitables
Dans le but de diminuer l’utilisation de la bande passante entre les machines, il serait non
négligeable de compresser les transferts de fichiers et de classes entre les différentes
applications. Il est possible d’introduire la compression de données au niveau le plus bas,
c’est-à-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 réseau est saturé et moins
37
5 Conclusion
rapide. Il faut avoir à l’esprit que chaque utilisateur ne dispose pas forcément d’une connexion
à Internet à haut débit.
Un autre point à améliorer est le domaine de la sécurité soit pour le modèle de sécurité au sein
du monde virtuel, soit à un plus bas niveau tel que les autorisations d’accès. Le recours au
Secure Sockets Layer (SSL) est une possibilité pour authentifier les utilisateurs et crypter leurs
données (cf. [9]). L’implémentation de SSL se situerait au niveau de l’emploi des sockets à
l’aide du package javax.net.ssl.
En restant dans l’optique d’une utilisation de SSL, le serveur HTTP qui transporte les classes
et les fichiers entre les applications devrait être converti en une version sécurisée, c’est-à-dire
un serveur HTTPS. En effet, pour l’instant, les "firewalls" protégeant le réseau Internet
empêchent le framework d’utiliser certains ports de communication des machines ; pour
résoudre ce problème, la solution la plus répandue est la méthode "HTTP tunneling" (cf. [9]),
qui consiste à contourner les "firewalls" en utilisant le port traditionnel HTTP 80. Hélas, le
désavantage de cette technique réside dans le fait qu’il serait nécessaire de reprogrammer le
serveur HTTP du framework. Cependant, comme les "firewalls" permettent l’accès aux
applications passant au travers de ports sécurisés, la conversion du serveur en HTTPS est une
solution envisageable, car elle évite de recourir à la méthode "HTTP tunneling".
Le software framework MaDViWorld est entièrement écrit en Java, langage qui offre
portabilité et indépendance vis-à-vis des plate-formes des machines. Cependant, il serait
acceptable d'autoriser au sein du monde virtuel des objets écrits dans d’autres langages de
programmation (par exemple C++, Ada, Smalltalk…) à l’aide de l’architecture CORBA. En
outre, cette technique pourrait être appliquée à l’application cliente (à l’avatar) en vue de
fournir une représentation du monde virtuel en 3D.
38
Références
RÉFÉRENCES
[1]
G. Collaud, J. Monnard, H. Platteaux, La convivialité d’un site web : clé d’une plus
grande efficacité, Centre NTE, Université de Fribourg, janvier 2002.
[2]
Département d’Informatique, 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].
[3]
D. Flanagan, J. Farley, W. Crawford, K. Magnusson, Java Enterprise in a Nutshell,
O'Reilly & Associates, 1999.
[4]
D. Flanagan, J. Farley, W. Crawford, K. Magnusson, Java in a Nutshell, O'Reilly &
Associates, 1999.
[5]
P. Fuhrer, G. Kouadri Mostéfaoui 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.
[6]
P. Fuhrer, G. Kouadri Mostéfaoui and J. Pasquier-Rocha, MaDViWorld: a Software
Framework for Massively Distributed Virtual Worlds, Software - Practice and
Experience, 2002, 32:645-668.
[7]
P. Fuhrer, Massively Distributed Virtual Worlds: a Framework Approach, FIDJI’2002
International Workshop on scientiFic engIneering of Distributed Java applIcations,
Luxembourg, November 28-29, 2002.
[8]
P. Fuhrer, RMI Overview, Department of Informatics, University of Fribourg,
http://diuf.unifr.ch/~fuhrer/publications/others/RMI.pdf, January 2002.
[9]
W. Grosso, RMI in a Nutshell, O'Reilly & Associates, 2002.
[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, O’Reilly & 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/
[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/
39
Appendice A : Software et Hardware
APPENDICE A : SOFTWARE ET
HARDWARE
Software
Programmation d’objets
•
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/
•
JBuilder 5, Borland, http://www.borland.com/jbuilder/ [25 septembre 2002].
Programmation du site
•
UltraEdit 32, IDM Computer Solutions, http://www.ultraedit.com
•
Dreamweaver 4/MX, Macromedia,
http://www.macromedia.com/software/dreamweaver/ [25 septembre 2002].
•
WebEditor 5, Namo, http://www.namo.com/products/webeditor/
•
Photoshop 5.5, Adobe, http://www.adobe.com/products/photoshop/
•
Acrobat 5, Adobe, http://www.adobe.com/products/acrobat/ [25 septembre 2002].
Hardware
Configurations de développement 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 d’installation et d’utilisation
APPENDICE B : GUIDE
D’INSTALLATION ET D’UTILISATION
Guide d’installation
Prérequis
Un compilateur Java pour la version 1.4.0 (ou supérieure) est requis pour la compilation des
classes du framework.
Téléchargements des fichiers
Les applications peuvent être téléchargées en [2] sous la forme d’archives ZIP ; chaque fichier
archive contient toutes les classes et les fichiers de lancement pour chaque application.
Extractions des fichiers
Il faut choisir un répertoire où vont être extraites les trois applications. Par exemple,
supposons que le répertoire d’installation soit d:\. Après extraction des fichiers dans ce
répertoire, celui-ci possède la structure suivant :
•
Le répertoire racine de l’application "room server" est d:\MaDViWorlds et contient un
dossier MaDViWorld qui contient le package MaDViWorld et tous les sous-packages relatifs
à cette application;
•
Le répertoire racine de l’application "avatar" est d:\MaDViWorldc et contient un dossier
MaDViWorld qui contient le package MaDViWorld et tous les sous-packages relatifs à
l’application cliente;
•
Le répertoire racine de l’application "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 l’application "room server"
Dans le répertoire racine de cette application, exécuter le fichier cpws.bat.
Compilation de l’application "avatar"
Dans le répertoire racine de cette application, exécuter le fichier cpwc.bat.
Compilation de l’application "room wizard"
Dans le répertoire racine de cette application, exécuter le fichier cpww.bat.
41
Guide d’utilisation
Prérequis
JRE 1.4 doit être installé sur la machine locale pour exécuter les applications ; il peut être
téléchargé à l’adresse http://java.sun.com/j2se/1.4/. De plus, l’application "room
server" nécessite l’installation préalable de Jini qui est disponible à l’adresse
http://wwws.sun.com/software/communitysource/jini/.
Exécution de l’application "room server"
1. Dans le répertoire racine de l’application, éditer le fichier setmvwenvvar.bat. Dans ce
fichier sont à définir trois variables (cf. Figure B.1):
•
MVHOME détermine le répertoire où a été installée l’application;
•
JINI_HOME détermine le répertoire où est installé Jini;
•
HOST contient l’adresse IP de la machine locale. Si cette dernière ne fait pas partie
d’un réseau, l’adresse IP est par défaut 127.0.0.1 ; sinon pour trouver l’adresse IP de la
machine, exécuter la commande ipconfig.
Figure B.1: Edition du fichier setmvenvvar.bat
2. Dans une console, exécuter dans le répertoire racine de l’application le fichier
sserver.bat (cf. Figure B.2).
42
Figure B.2: Lancement de l’application "room server" dans une console
Exécution de l’application "avatar"
1. Dans le répertoire racine de l’application, éditer le fichier setmvwenvvar.bat.et définir
les trois variables locales MVHOME, JINI_HOME et HOST (cf. Figure B.1). Puis sauvegarder et
fermer le fichier.
2. Exécuter dans le répertoire racine de l’application le fichier sclient.bat.
Exécution de l’application "room wizard"
1. Dans le répertoire racine de l’application, éditer le fichier setmvwenvvar.bat.et définir
les trois variables locales MVHOME, JINI_HOME et HOST (cf. Figure B.1). Puis sauvegarder et
fermer le fichier.
2. Dans une console, exécuter dans le répertoire racine de l’application le fichier
swizard.bat.
43
Appendice C : Version imprimable du "MaDViWorld Object Programmer’s Guide"
APPENDICE C : VERSION
IMPRIMABLE DU "MADVIWORLD
OBJECT PROGRAMMER’S 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 Mostéfaoui, 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
Default
avatar
Avatar
util
event
Default
room
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
«interface»
WObjectGUI
«interface»
WObject
framework classes
RemoteEvent
«interface»
RemoteEventListener
WObjectImpl
WObjectGUIImpl
«interface»
MyObj
1
MyObjGUIImpl
1
1 1
MyObjPanel
javax.swing.JPanel
MyObjImpl
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
framework classes
«interface»
WObject
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
framework classes
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.
«interface»
RemoteEventListener
WObjectGUIImpl
1
MyObjGUIImpl
1
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;
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.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.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;
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:
import ch.unifr.diuf.madviworld.wobject.whiteboard.WhiteBoard;
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();
}
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
titlePanel = new javax.swing.JPanel();
title = new javax.swing.JLabel();
buttonPanel = new java.awt.Panel();
setTextButton = new javax.swing.JButton();
setLayout(new java.awt.GridBagLayout());
titlePanel.setLayout(new java.awt.GridBagLayout());
titlePanel.setMinimumSize(new java.awt.Dimension(80, 22));
title.setFont(new java.awt.Font("Verdana", 1, 14));
title.setText("A simple Whiteboard");
titlePanel.add(title, gridBagConstraints2);
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());
text.setText(readboard());
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.fill = java.awt.GridBagConstraints.VERTICAL;
mainPanel.add(buttonPanel, gridBagConstraints3);
add(mainPanel, gridBagConstraints1);
}
private void setTextButtonActionPerformed (java.awt.event.ActionEvent
evt) {
try {
impl.setText(text.getText());
}
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();
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:
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:
import
import
import
import
ch.unifr.diuf.madviworld.event.RemoteEventListener;
ch.unifr.diuf.madviworld.event.UnknownEventException;
67
import java.rmi.server.UnicastRemoteObject;
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:
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
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;
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:
import ch.unifr.diuf.madviworld.wobject.whiteboard.WhiteBoard;
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();
}
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;
titlePanel = new javax.swing.JPanel();
title = new javax.swing.JLabel();
jPanel2 = new javax.swing.JPanel();
jScrollPane1 = new javax.swing.JScrollPane();
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());
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));
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.setForeground(java.awt.Color.blue);
text.setText(readboard());
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());
}
private String readboard() {
String resp = "";
try {
resp = impl.getText();
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:
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:
like
the
import
import
import
import
import
import
ch.unifr.diuf.madviworld.event.RemoteEventListener;
ch.unifr.diuf.madviworld.event.UnknownEventException;
java.rmi.server.UnicastRemoteObject;
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"));
}
receivedSeqNum = seqNum;
} else {
//do nothing, the event is deprecated
}
}
}//end of class
3.3.5 WhiteBoard 2 Code and Javadoc
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 Mostéfaoui 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 Mostéfaoui 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, FIDJI’2002
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 l’adresse
http://diuf.unifr.ch/softeng/student-projects/completed/marchon/
se trouvent un résumé du travail et le lien vers le guide du programmeur d’objets
MaDViWorld, ainsi que le code source et la javadoc des deux objets programmés. De plus,
cette même adresse propose la version PDF de ce document.
81
Appendice E : CD-Rom
APPENDICE E : CD-ROM
Le CD-Rom fourni en annexe du présent document contient :
•
La documentation (répertoire documentation/)
- rapport.doc:
Travail de diplôme au format Word
- rapport.pdf:
Travail de diplôme au format PDF
•
Les objets (répertoire objets/)
- miner/
Jeu du démineur
miner.zip:
Code source de l’objet miner
javadoc/:
Javadoc de l’objet miner
- battleship/
Jeu de la bataille navale
battleship.zip: Code source de l’objet battleship
javadoc/:
Javadoc de l’objet battleship
•
Le guide complet du programmeur d’objets MaDViWorld (répertoire guide/)
•
La dernière version du framework MaDViWorld (répertoire framework/)
- madviworldc.zip: Application avatar
- madviworlds.zip: Application room server
- madviworldw.zip: Application room wizard
82

Travail de Diplôme au format PDF - DIUF

Transcription

Documents pareils

Window Sticker - FordDirect.com

Mardi 17 Janvier 19h00 Exia / Cesi de Mont Saint Aignan Des

Lexique Java EE

CV - Julien Vaudour

Le Youth Package, un programme innovateur de la Banque Libano

brochure-defis-du-chott-2010

CV - Jean David Olekhnovitch

agendas - Cerner

CampingduLacdeBournazel****