Projet ISIMA 3ème année F2

Transcription

INSTITUT SUPÉRIEUR D'INFORMATIQUE DE MODÉLISATION DE LEURS APPLICATIONS
Complexe des Cézeaux
BP 125
63173 Aubière Cedex
Rapport de projet de 3ème année
Filière 2 – Génie Logiciel et Systèmes Informatiques
SYSTÈME D'INFORMATION GÉOGRAPHIQUE
TOME 1 RAPPORT
Présenté par : Vianney Bajart et Christophe Charles
Durée :
Responsables ISIMA : Christophe Duhamel et Philippe Lacomme
BAJART / CHARLES
REMERCIEMENTS
REMERCIEMENTS
Nos remerciements s'adressent principalement à nos tuteurs de projets, Monsieur Christophe Duhamel et Monsieur Philippe Lacomme pour nous avoir guidés et conseillés dans la conduite de ce projet.
Nos remerciements vont également à Murielle Mouzat, notre professeur de communication, pour nous avoir appris la bonne démarche à suivre lors de la réalisation d'un rapport et d'une présentation orale.
Enfin, nous remercions les professeurs de l'ISIMA qui nous ont apporté un enseignement précieux sur les méthodes et outils de développement logiciel qui nous ont permis de mener à bien ce projet
Projet ISIMA 3ème année F2 – Système d'Information Géographique
2/50
BAJART / CHARLES
RÉSUMÉ / ABSTRACT
RÉSUMÉ
La recherche opérationnelle appliquée au problème du voyageur de commerce nécessite de travailler sur des données géographiques réelles. C'est pourquoi ce projet a été proposé par les chercheurs pour réaliser un système d’information géographique (SIG) regroupant plusieurs fonctionnalités dont le géocodage, la recherche d’itinéraire, la construction de distancier ou encore l'affichage de plusieurs villes sur une carte. Le logiciel devait être écrit en Java pour permettre de l'exécuter sur un maximum de plateformes et devait utiliser les services géographiques en ligne. Nous avons retenu le fournisseur de services Google Maps pour sa gratuité et la qualité de ses outils.
L'utilisation de Google Maps nous a posé un problème technique important : celui d'utiliser API JavaScript dans un programme Java. Pour cela, nous nous sommes dirigés vers une solution utilisant une applet Java plutôt qu’une application dans le but de communiquer avec l'environnement JavaScript du navigateur Web grâce à la technologie LiveConnect.
Les fonctionnalités demandées ont été implémentées et nous avons conçu une interface graphique ergonomique permettant de présenter clairement des résultats à des personnes noninitiées au problème du voyageur de commerce.
Motsclés : problème du voyageur de commerce, système d'information géographique (SIG), services géographiques en ligne, géocodage, recherche d'itinéraire, distancier, carte, Google Maps, Java, JavaScript, applet, LiveConnect, ergonomie
ABSTRACT
The operational research applied to the travelling salesman problem needs to work on real geographical data. Here's why this project was suggested by researchers to achieve a geographical information system (GIS) including several uses as geocoding, route planning, distancer construction, or still the display of several cities on the same map.
The software application must be written in Java, to allow to execute it on the most of platforms, and had to use online geographical services. We arrested on the service provider Google Maps for his free access and the quality of his tools.
The use of google Maps raised us a major technical issue : apply an API JavasScript in a Java program. For it, we went to a solution using a Java applet rather an application in the purpose of communicate with the JavaScript environnement of the Web browser thanks to LiveConnect technology.
The wanted features were implemented and we designed an ergonomic interface allowing to present clearly the results to persons nonintroduced to the problem of the commercial traveller.
Keywords : problem of the commercial traveller, geographical information system (GIS), online geographical services, geocoding, route planning, distancer construction, map, Google Maps, Java, JavaScript, applet, LiveConnect, ergonomy.
3/50
BAJART / CHARLES
TABLE DES MATIÈRES
TABLE DES MATIÈRES
REMERCIEMENTS
2
RÉSUMÉ
3
ABSTRACT
3
INTRODUCTION
10
1 Présentation du projet.........................................................................11
1.1 Contexte.........................................................................................................11
1.1.1 Problème du voyageur de commerce..............................................................11
1.1.2 Description du problème................................................................................11
1.2 Système d'information géographique.............................................................11
1.2.1 Définition........................................................................................................11
1.2.2 Fonctionnalités demandées.............................................................................12
2 Services géographiques.......................................................................13
2.1 Données géographiques.................................................................................13
2.1.1 L'adresse.........................................................................................................13
2.1.2 La position......................................................................................................13
2.1.3 La route..........................................................................................................13
2.2 Les différents services....................................................................................13
2.2.1 Géocodage......................................................................................................13
2.2.2 Recherche d'itinéraire.....................................................................................14
2.2.3 Affichage de cartes..........................................................................................14
2.3 Recherche de fournisseurs.............................................................................14
2.3.1 ViaMichelin.....................................................................................................14
2.3.2 Google Maps...................................................................................................15
2.3.3 Mappy.............................................................................................................15
2.4 Choix du fournisseur......................................................................................15
4/50
BAJART / CHARLES
TABLE DES MATIÈRES
2.5 Utilisation des services...................................................................................15
2.5.1 Choix d'une solution.......................................................................................15
2.5.2 Comprendre le fonctionnement d'un navigateur............................................16
2.5.3 Intégration d'une applet Java dans une page Web..........................................16
2.5.4 Communication Java – Javascript...................................................................17
2.5.4.1 L'interface NPAPI et la technologie LiveConnect.....................................17
2.5.4.2 De JavaScript vers Java...........................................................................17
2.5.4.3 De Java vers JavaScript...........................................................................18
2.5.5 Architecture de la solution..............................................................................20
2.5.6 Problèmes rencontrés.....................................................................................20
2.5.7 Lien Java – JavaScript....................................................................................21
2.5.7.1 Synchronisation Java – JavaScript..........................................................21
2.5.7.2 Importations de fichiers JavaScript.........................................................22
2.5.7.3 Injection de code JavaScript depuis Java................................................24
2.5.8 Services JavaScript........................................................................................24
2.5.9 Implémentation du géocodeur........................................................................25
2.5.9.1 Géocodeur de l'API Google Maps............................................................25
2.5.9.2 Wrapper JavaScript.................................................................................25
2.5.9.3 Côté Java.................................................................................................26
2.5.10 Implémentation du calculateur d'itinéraire..................................................27
2.5.10.1 Calculateur d'itinéraire de l'API Google Maps.......................................27
2.5.10.2 Wrapper JavaScript...............................................................................27
2.5.10.3 Côté Java...............................................................................................28
2.5.11 Implémentation de l'afficheur de carte.........................................................29
2.5.11.1 Afficheur de carte de l'API Google Maps...............................................29
2.5.11.2 Wrapper JavaScript...............................................................................30
2.5.11.3 Côté Java...............................................................................................30
2.5.12 Résultat.........................................................................................................30
3 Développement de l'application..........................................................32
3.1 Organisation de l'application.........................................................................32
3.1.1 Répertoire de l'application..............................................................................32
3.1.2 Répertoire utilisateur......................................................................................32
3.2 Fonctionnalités...............................................................................................32
3.3 Architecture ModèleVueContrôleur..............................................................33
3.3.1 Présentation....................................................................................................33
3.3.2 Le Modèle.......................................................................................................33
3.3.3 La Vue.............................................................................................................33
3.3.4 Le Contrôleur..................................................................................................33
3.3.5 Utilisation du patron de conception MVC dans le SIG....................................33
3.4 Outils de développement pour l'interface graphique.....................................34
3.5 Géocodeur......................................................................................................34
3.5.1 Vue..................................................................................................................34
3.5.2 Modèle............................................................................................................35
5/50
BAJART / CHARLES
TABLE DES MATIÈRES
3.6 Recherche d'itinéraire....................................................................................35
3.6.1 Vue..................................................................................................................35
3.6.2 Modèle............................................................................................................35
3.7 Organisation des projets................................................................................37
3.8 Liste des projets.............................................................................................37
3.8.1 Vue..................................................................................................................37
3.9 Sélection des villes........................................................................................39
3.9.1 Objectif...........................................................................................................39
3.9.2 Données..........................................................................................................39
3.9.3 Vue..................................................................................................................39
3.9.4 Modèle............................................................................................................40
3.10 Coordonnées des villes.................................................................................40
3.10.1 Objectif.........................................................................................................40
3.10.2 Vue................................................................................................................40
3.10.3 Modèle..........................................................................................................42
3.10.4 Cache............................................................................................................42
3.11 Création du distancier..................................................................................43
3.11.1 Objectif.........................................................................................................43
3.11.2 Vue................................................................................................................43
3.11.3 Modèle..........................................................................................................44
3.11.4 Cache............................................................................................................44
3.12 Déploiement du SIG.....................................................................................44
3.12.1 Conditions préalables...................................................................................44
3.12.1.1 Java.......................................................................................................44
3.12.1.2 Serveur Web..........................................................................................44
3.12.2 Clé Google....................................................................................................45
3.12.3 Installation du SIG........................................................................................45
3.12.4 Lancement de l'application...........................................................................45
3.12.5 Bugs connus..................................................................................................46
3.13 Améliorations pouvant être apportées au logiciel........................................46
CONCLUSION
47
GLOSSAIRE
48
RÉFÉRENCES EN LIGNE
50
6/50
BAJART / CHARLES
INDEX DES TABLES ET ILLUSTRATIONS
INDEX DES TABLES
Tab. 1 Contenu des champs de la classe Address...............................................................13
Tab. 2 Méthodes de l'interface « Map »...............................................................................14
Tab. 3 Conversion des types de JavaScript vers Java..........................................................18
Tab. 4 Méthodes de la classe JSObject...............................................................................18
Tab. 5 Conversion des types de Java vers JavaScript..........................................................19
Tab. 6 Méthodes de la classe GoogleMap...........................................................................30
Tab. 7 Traitements effectués par le modèle de l'extracteur de villes..................................40
Tab. 8 Liste des villes et distanciers....................................................................................44
INDEX DES ILLUSTRATIONS
Fig. 1 Problème du voyageur de commerce........................................................................11
Fig. 2 Classe Address..........................................................................................................13
Fig. 3 Classe Position..........................................................................................................13
Fig. 4 Classe Route.............................................................................................................13
Fig. 5 Interface Geocoder...................................................................................................13
Fig. 6 Interface RouteFinder...............................................................................................14
Fig. 7 Interface Map...........................................................................................................14
Fig. 8 Architecture de la solution pour l'utilisation des services en ligne...........................20
Fig. 9 Diagramme de séquence d'un appel synchrone à une fonction JavaScript...............21
Fig. 10 Diagramme de séquence d'un appel asynchrone à une fonction JavaScript...........21
Fig. 11 Diagramme de séquence de principe pour la synchronisation Java JavaScript....22
Fig. 12 Diagramme de séquence pour la synchronisation Java JavaScript.......................22
Fig. 13 Diagramme de séquence d'une injection de code JavaScript depuis Java..............24
Fig. 14 Classe JSService.....................................................................................................24
Fig. 15 Diagramme de dépendances des services JavaScript..............................................25
Fig. 16 Structure de l'implémentation du géocodeur.........................................................27
Fig. 17 Exemple de carte générée par Google Maps...........................................................30
Fig. 18 Architecture du patron de conception MVC...........................................................33
7/50
BAJART / CHARLES
INDEX DES TABLES ET ILLUSTRATIONS
Fig. 19 Onglet « Géocodage ».............................................................................................34
Fig. 20 Diagramme de séquence du modèle de l'outil de géocodage.................................35
Fig. 21 Onglet « Recherche d'itinéraire » avec carte et directions......................................36
Fig. 22 Onglet « Liste des projets ».....................................................................................38
Fig. 23 Onglet « Liste des villes »........................................................................................38
Fig. 24 Onglet « Coordonnées des villes » et position des villes sur la carte......................41
Fig. 25 Algorigramme de principe de l'utilisation cache du géocodeur..............................42
Fig. 26 Onglet « Construction du distancier ».....................................................................43
Fig. 27 Certificat autorisant l'applet à accéder au disque dur............................................46
8/50
BAJART / CHARLES
INDEX DES LISTINGS DE CODE SOURCE
INDEX DES LISTINGS DE CODE SOURCE
List. 1 Applet Java..............................................................................................................16
List. 2 Intégration d'une applet Java dans une page Web...................................................17
List. 3 Autoriser la communication applet Java JavaScript..............................................17
List. 4 Méthode Java appelée dans JavaScript....................................................................18
List. 5 Appel d'une méthode Java depuis JavaScript..........................................................18
List. 6 Importation statique d'un fichier JavaScript externe...............................................22
List. 7 Fonction pour l'importation dynamique d'un fichier JavaScript externe.................23
List. 8 Fonction synchrone pour l'importation dynamique d'un fichier JavaScript externe 23
List. 9 Déclaration de la classe GoogleGeocoder................................................................25
List. 10 Utilisation du géocodeur de l'API Google Maps.....................................................25
List. 11 Wrapper JavaScript du géocodeur Google.............................................................26
List. 12 Implémentation du Géocodeur..............................................................................26
List. 13 Utilisation du calculateur d'itinéraire de l'API Google Maps..................................27
List. 14 Wrapper JavaScript du calculateur d'itinéraire Google..........................................28
List. 15 Implémentation du calculateur d'itinéraire............................................................28
List. 16 Utilisation de l'afficheur de carte de l'API GoogleMaps.........................................29
List. 17 Exemple de fichier contenant la liste des villes d'un projet...................................40
9/50
BAJART / CHARLES
INTRODUCTION
INTRODUCTION
Le problème du voyageur de commerce monopolise la pensée de nombreux chercheurs à l’heure actuelle et depuis de nombreuses années. En effet, ce problème très complexe trouve des applications concrètes dans de nombreux domaines. Malheureusement, peu de gens connaissent réellement ce problème et il est souvent bien compliqué d’expliquer ses résultats à une personne lambda. Il faut donc s’appuyer sur des outils graphiques pour plus de clarté.
Il existe déjà de nombreux systèmes d’informations géographiques dont plusieurs sont gratuits. Le but de ce projet est donc de regrouper les fonctionnalités demandées dans un logiciel facile à utiliser pour aider et complémenter le travail des chercheurs sur le problème du voyageur de commerce.
Dans une première partie nous allons donc expliquer les objectifs du projet en détaillant le contexte et les fonctionnalités demandées. Ensuite, nous expliquerons comment utiliser des services géographiques tels que Google Maps ou ViaMichelin. Et enfin, nous détaillerons la réalisation de l’application en expliquant les choix techniques et graphiques.
10/50
BAJART / CHARLES
PRÉSENTATION
1 Présentation du projet
1.1 Contexte
1.1.1 Problème du voyageur de commerce
Le problème du voyageur de commerce mobilise énormément de chercheurs encore à l’heure actuelle. Avec ce projet, nous ne travaillons pas sur les algorithmes de résolution de ce problème mais sur un outil permettant d’afficher les résultats de manière compréhensible pour tous.
En effet, pour présenter leur résultat à un autre audimat que les scientifiques, les chercheurs ont besoin d’un outil simple et graphique. Notre logiciel doit donc pouvoir afficher à l’aide de carte des résultats stockés dans des fichiers textes. Il doit aussi être facile à utiliser pour éviter de perdre du temps à générer des cartes alors que l’essentiel du travail n’est pas là.
L'autre objectif de cet outil est de générer des données réelles. En effet, les chercheurs travaillent souvent avec des banques de données réalistes mais pas forcément réelles. Une des fonctionnalités demandées pour ce logiciel était donc de pouvoir générer des données géographiques réelles (coordonnées géographiques des villes, itinéraires...), à partir de services géographiques en ligne tels que ViaMichelin ou Google Maps.
1.1.2 Description du problème
Le problème du voyageur de commerce consiste, étant donné un ensemble de villes séparées par des distances données, à trouver le plus court chemin qui relie toutes les villes. C’est un problème NPComplet. A titre d’exemple, le nombre de chemin possible passant par 69 villes est un nombre d’une longueur de 100 chiffres. Par comparaison, un nombre de 80 chiffres permettrait déjà de représenter le nombre d’atomes dans tout l’univers connu.
Fig. 1 Problème du voyageur de commerce
C’est un problème plus compliqué qu’il n’y paraît car on ne connaît pas de méthode de résolution permettant d’obtenir des solutions exactes en un temps raisonnable pour un grand nombre de villes. C'est pourquoi on résout ce problème avec des heuristiques.
Ce type de problème ce retrouve dans de nombreux domaines. Il peut bien sûr servir pour optimiser les tournées d’un facteur ou autre livreur, mais il sert aussi dans énormément de problèmes de recherche opérationnelle
1.2 Système d'information géographique
1.2.1 Définition
Le travail demandé est donc de créer un système d’information géographique (SIG) proposant les fonctionnalités souhaitées. Nous allons donc tout d’abord définir ce qu’est un système d’information géographique.
Un système d’information géographique est un outil informatique permettant de produire des cartes et des plans à partir de données alphanumériques spatialement référencées. Son rôle est donc de proposer une représentation plus ou moins réaliste de l’environnement spatial en se basant Projet ISIMA 3ème année F2 – Système d'Information Géographique
11/50
BAJART / CHARLES
PRÉSENTATION
sur des primitives graphiques telles que des points, des vecteurs, des polygones ou des maillages.
1.2.2 Fonctionnalités demandées
Nous avons donc en début de projet établit une liste de fonctionnalités nécessaires à ce SIG. Voici les fonctionnalités de base demandée :
•
A partir d’une adresse :
◦ connaître sa localisation GPS ;
•
A partir de deux adresses :
◦ connaître la distance kilométrique et horaire les séparant ;
◦ connaître le chemin.
•
A partir d’un ensemble d’adresses :
◦ connaître la carte englobant ces villes au plus près et afficher les villes souhaitées dessus.
Par la suite, nous avons établit plusieurs autre fonctionnalités qui apportent un plus à ce SIG. En voici une liste :
•
Pouvoir sélectionner une liste de villes suivant certains critères (population et département) ;
•
Pouvoir créer un distancier à partir d’un liste de villes ;
•
Avoir une base de données regroupant toutes les distances déjà connues pour minimiser le nombre de requêtes auprès du fournisseur de services géographiques. Projet ISIMA 3ème année F2 – Système d'Information Géographique
12/50
BAJART / CHARLES
SERVICES GÉOGRAPHIQUES
2 Services géographiques
2.1 Données géographiques
Nous avons défini plusieurs classes d'objets permettant de manipuler des données géographiques :
Fig. 3 Classe Position Fig. 4 Classe Route
Fig. 2 Classe Address
2.1.1 L'adresse
Pour définir une adresse, nous avons créé une classe Address (Fig. 2) comportant quatre champs dont le contenu est décrit sur le tableau 1. À noter qu'on accepte l'utilisation d'adresses incomplètes (par exemple : une adresse dont on aurait seulement précisé le nom de la ville et le nom du pays).
street
Numéro + nom de la voie
code
Code postal de la ville
city
Nom de la ville
country
Nom du pays
Tab. 1 Contenu des champs de la classe Address
2.1.2 La position
On définit une position (classe Position Fig. 3) par ses coordonnées géographiques formées par le couple latitude et longitude.
2.1.3 La route
L'itinéraire entre deux adresses est défini dans une classe appelée « Route » (Fig. 4). Cette classe contient uniquement le temps de trajet et la distance parcourue car ce sont les deux seules données dont nous avons eu besoin pour ce projet. Bien sûr, si l'on souhaite étendre les fonctionnalités du programme, on pourra y rajouter des champs comme : les points de passages, les instructions pour la conduite, le coût du trajet, etc.
2.2 Les différents services
2.2.1 Géocodage
Le géocodage est un procédé qui consiste à retrouver les coordonnées géographiques associées à une adresse. L'objet qui fournit ce service est appelé « géocodeur ». On Fig. 5 Interface Geocoder
définit alors une interface « Geocoder » contenant une méthode « geocode() » qui prend en paramètre une adresse et retourne une position (Fig. 5).
13/50
BAJART / CHARLES
2.2.2 Recherche d'itinéraire
La recherche d'itinéraire grâce à un objet qui implémente l'interface Fig. 6 Interface RouteFinder
« RouteFinder ». Cette interface comprend une méthode « routeFind() » qui prend en paramètres une adresse de départ et une adresse d'arrivée et qui retourne la route correspondant à cet itinéraire.
2.2.3 Affichage de cartes
On souhaite pouvoir afficher des cartes géographiques en y insérant des marqueurs indiquant la position d'éléments comme des adresses ou des villes. Ce travail doit être réalisé par une classe qui implémente l'interface « Map » (Fig. 7). Le rôle des méthodes est décrit dans le tableau 2.
Fig. 7 Interface Map
setCenter(center:Position, zoom)
Recentre la carte sur la position « center » avec le niveau de zoom « zoom »
addMarker(pos:Position, title:String)
Ajoute un marqueur sur la position « pos » avec comme nom « title »
reframe()
Recadre la carte sur le plus petit rectangle contenant tous les marqueurs avec un niveau de zoom optimal
clear()
Enlève tous les marqueurs de la carte
Tab. 2 Méthodes de l'interface « Map »
Si l'on souhaite ajouter des fonctionnalités au programme, on pourra étendre cette interface de manière à pouvoir effectuer le tracé d'itinéraires sur la carte.
2.3 Recherche de fournisseurs
Les outils qui peuvent nous permettre d'implémenter ces interfaces sont proposées par des fournisseurs de services en ligne. Nos recherches se sont orientées vers des services Web fournissant des outils de géocodage et de recherche d'itinéraire tels que Google Maps, ViaMichelin et Mappy. 2.3.1 ViaMichelin
Le service ViaMichelin propose une API appelée Maps & Drive qui fournit notamment un géocodeur et un outil de recherche d'itinéraire. Ce dernier est très complet puisque de nombreux paramètres peuvent être choisis pour l'itinéraire : type d'itinéraire (le plus court, le plus rapide, le plus économique...), type de véhicule, la consommation du véhicule... Le résultat d'une requête d'itinéraire comporte bien sûr la distance et le temps de trajet mais aussi le coût (carburant et péages) et la consommation d'essence.
L'utilisation de cette API requiert la création d'un compte sur le site de ViaMichelin, ce qui donne la possibilité de profiter de ce service pendant 45 jours – délai audelà duquel le service devient payant. ViaMichelin limite l'utilisation du géocodage et de la recherche d'itinéraire à 1000 requêtes par jour.
14/50
BAJART / CHARLES
2.3.2 Google Maps
Google Maps fournit une API conséquente pour la manipulation de données géographiques telles que des cartes ou des routes. Le site fournit entre autres, un géocodeur et un service de recherche d'itinéraire, bien que ce dernier ne permet pas de choisir des options pour l'itinéraire telles que : le type de trajet (plus court, plus rapide), le type de véhicule, la consommation, la vitesse... et ne donne aucune information sur le coût d'un trajet.
Il est nécessaire de s'inscrire pour utiliser le service Google Maps. L'utilisation est illimitée dans le temps mais il y a une limite de 15 000 requêtes de géocodage ou de recherche d'itinéraire par jour. 2.3.3 Mappy
Le site Mappy (iTi) propose une API appelée Maia similaire à celle de ViaMichelin cependant elle impose l'intégration d'une application Flash de Mappy pour l'affichage de la carte. Nous n'avons pas trouvé d'informations concernant les limites de l'utilisation de ce service. Cependant, à chaque géocodage ou recherche d'itinéraire, l'application Flash doit être rafraîchie, ce qui ralenti l'exécution et limite considérablement la quantité de requête pouvant être effectuées dans un temps donné.
2.4 Choix du fournisseur
Étant données les limites imposées par ViaMichelin sur le nombre de requêtes et les contraintes posées par l'utilisation de l'application Flash de Mappy, nous avons choisi d'utiliser dans un premier temps le service Google Maps. 2.5 Utilisation des services
2.5.1 Choix d'une solution
Les services proposés par ces sites sont conçu pour être intégrés dans des pages Web, c'est pourquoi leur API est écrite en JavaScript. Le défi technique majeur a été de trouver une solution pour utiliser ces services dans un programme Java.
Nous avons envisagé trois possibilités :
• Réécrire l'API JavaScript en Java et dialoguer directement avec les serveurs des fournisseur
Le problème de cette solution est que le code source de ces API est constitué d'une quantité importante de fichiers (parfois plus d'une cinquantaine !) et que leur contenu est volontairement brouillé (commentaires, espaces et retours à la ligne supprimés, nom des variables, classes et fonctions brouillés...) ce qui rend leur compréhension et leur réécriture quasi impossible.
• Utiliser un environnement JavaScript dans un programme Java
La deuxième idée que nous avons eu est de créer un environnement d'exécution JavaScript dans un programme Java en utilisant des interpréteurs JavaScript tels que SpiderMonkey, l'interpréteur utilisé dans le moteur de rendu Web Gecko (Firefox) ou directement utiliser ce dernier. Cependant, cette tâche s'avéra être longue et Projet ISIMA 3ème année F2 – Système d'Information Géographique
15/50
BAJART / CHARLES
fastidieuse pour pouvoir être réaliser dans les temps impartis.
• Utiliser une applet Java
Lors de nos recherches, notre attention s'est portée sur le package Java netscape.javascript qui fournit une API permettant la manipulation d'objets JavaScript dans une applet Java. Ainsi, l'applet communique avec l'interpréteur JavaScript du navigateur qui se charge d'utiliser l'API des fournisseurs. Bien que cette solution impose d'embarquer notre application dans un navigateur Web, elle nous a paru la plus simple à mettre en œuvre pour ce projet.
2.5.2 Comprendre le fonctionnement d'un navigateur
Contenu d'une page Web
Une page Web est composée de code HTML qui permet de structurer sémantiquement son contenu et d'y inclure des ressources externes telles que des images, des fichiers audio ou vidéo, des fichiers JavaScript ou CSS, des applets Java, des applications Flash... (Remarque : certaines ressources comme le code JavaScript ou CSS peuvent être intégrées dans la page entre des balises) en précisant leur URL.
Chargement d'une page par le navigateur
Lorsqu'on entre une URL dans la barre d'adresse du navigateur celuici télécharge le fichier HTML puis l'interprète en créant ce qu'on appelle le DOM (Document Object Model). Le DOM est une arborescence qui représente la structure du document. Il possède une API, permettant de modifier la structure et le contenu de cette arborescence, qui est utilisée par les composants susceptibles de modifier le contenu et la mise en forme de la page, principalement : les interpréteurs HTML, CSS et JavaScript. Au chargement de la page, ces composants construisent le DOM qui est ensuite traité par le moteur de rendu pour afficher la page sur le navigateur. 2.5.3 Intégration d'une applet Java dans une page Web
Dans un premier temps, il faut implémenter l'applet et la placer dans une archive Java (JAR). Nommons la « MyApplet.jar » (List. 1).
package mypackage;
import java.applet.*;
public class MyApplet extends Applet
{
public void init()
{
...
}
...
}
List. 1 Applet Java
On intègre ensuite l'applet dans une page HTML grâce à la balise « <applet> » (List. 2).
16/50
BAJART / CHARLES
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<title>Integration d'une applet Java</title>
</head>
<body>
<div>
<applet name="myApplet" codebase="." archive="MyApplet.jar"
code="mypackage.MyApplet" width="600" height="400">
</applet>
</div>
</body>
</html>
List. 2 Intégration d'une applet Java dans une page Web
On nomme l'applet dans la page avec le champ « name » et on spécifie le répertoire contenant l'archive avec le champ « codebase ». Dans l'exemple, l'archive se trouve dans le même répertoire que le fichier HTML.
2.5.4 Communication Java – Javascript
2.5.4.1 L'interface NPAPI et la technologie LiveConnect
De nos jours, un navigateur ne sert plus uniquement à afficher des pages Web HTML mais il est le support de nombreuses applications externes telles que les lecteurs audio/vidéo, le lecteur Flash, le lecteur de document PDF et la machine virtuelle Java (JVM). Toutes ces applications sont embarquées dans le navigateur sous forme de plugins qui utilisent l'interface NPAPI (Netscape Plugin Application Programming Interface). À l'origine développée pour Netscape, cette interface a été implémentée dans tous les navigateurs actuels : Firefox, Internet Explorer, Safari, Opera, Konqueror, Google Chrome...
Depuis Netscape 4, NPAPI a été étendue pour permettre aux plugins de communiquer avec JavaScript, cette extension est appelée LiveConnect. Elle fournit notamment un support pour la communication entre le plugin Java et JavaScript.
Pour autoriser la communication entre une applet Java et JavaScript il faut ajouter l'attribut « mayscript » (remarque : cet attribut n'est pas conforme aux standards du W3C) dans la balise « <applet> » (List. 3).
<applet ... mayscript></applet>
List. 3 Autoriser la communication applet Java JavaScript
2.5.4.2 De JavaScript vers Java
Au chargement de la page, LiveConnect crée un objet JavaScript – un « wrapper » ou adaptateur – portant le nom spécifié dans le champ « name » de la balise « <applet> ». Ainsi la communication avec l'applet Java depuis du code JavaScript est très simple puisqu'on fait appel directement aux méthodes de la classe MyApplet dans le code JavaScript (List. 4 et List. 5).
17/50
BAJART / CHARLES
public class MyApplet extends Applet
{
...
public void myMethod() { ... }
...
}
List. 4 Méthode Java appelée dans JavaScript
<script type="text/javascript">
myApplet.myMethod();
</applet>
List. 5 Appel d'une méthode Java depuis JavaScript
JavaScript et Java n'ont pas la même représentation des données, c'est pourquoi il faut respecter les règles certaines règles de conversion (Tab. 3).
JavaScript → Java
number
→
byte
short
int
long
float
double
char
java.lang.Double
boolean
→
boolean
java.lang.Boolean
string
→
java.lang.String
function
ou tout autre objet JavaScript
→
netscape.javascript.JSObject
Tab. 3 Conversion des types de JavaScript vers Java
2.5.4.3 De Java vers JavaScript
Pour communiquer avec JavaScript depuis l'applet Java, on utilise l'API JSObject contenue dans le package « netscape.javascript ». Cette API fournit une classe JSObject permettant de manipuler des objets JavaScript (Tab. 4) mais son utilisation nécessite également des règles de conversion de type entre les deux langages (Tab. 5).
Object getMember(String name)
Permet d'obtenir l'objet JavaScript nommé « name »
void setMember(String name, Object value)
Affecte une valeur à l'objet « name »
void removeMember(String name)
Supprime l'objet « name »
Object call(String name, Object args[])
Appelle une méthode avec une liste d'arguments
Object eval(String expr)
Évalue une expression JavaScript
Tab. 4 Méthodes de la classe JSObject
18/50
BAJART / CHARLES
JavaScript ← Java
number
Number
←
byte
short
int
long
float
double
char
boolean
Boolean
←
boolean
JavaObject
←
java.lang.String
java.lang.Character
java.lang.Boolean
java.lang.Integer
java.lang.Long
java.lang.Float
java.lang.Double
java.lang.Class
ou tout autre objet Java
Tab. 5 Conversion des types de Java vers JavaScript
19/50
BAJART / CHARLES
2.5.5 Architecture de la solution
Navigateur Web
Page Web
Code HTML
Interpréteur
HTML
DOM
API DOM
Interpréteur
JavaScript
Code JavaScript
LiveConnect
Applet
Java
API JSObject
Plug-in Java
API JavaScript
Fournisseur
de Services
Machine Virtuelle
Java
Fig. 8 Architecture de la solution pour l'utilisation des services en ligne
2.5.6 Problèmes rencontrés
Lors des premiers essais d'utilisation de l'API JSObject, nous avons remarqué plusieurs problèmes :
•
Certains appels à des fonctions JavaScript depuis Java ne sont pas bloquants. C'està
dire qu'au moment de l'appel à la méthode call("js_function", params),
l'exécution de la suite du code Java se poursuit alors que l'exécution de la fonction js_function() n'est pas terminée. Il a donc fallu imaginer un mécanisme de synchronisation des fils d'exécution Java et JavaScript.
•
Il n'est pas possible d'importer directement des fichiers JavaScript depuis le code Java. Or, ceci est possible depuis JavaScript. Pour résoudre ce problème, nous avons cherché un moyen d'importer des fichiers .js depuis Java en passant JavaScript. Projet ISIMA 3ème année F2 – Système d'Information Géographique
20/50
BAJART / CHARLES
2.5.7 Lien Java – JavaScript
Pour réaliser cette solution, nous avons créé un objet de classe JSBind qui sert de lien entre l'applet et la page Web. Ce lien facilite l'écriture du code pour la communication Java – JavaScript, permet la synchronisation des appels de fonction entre les deux langages et fournit un support pour l'importation de fichiers JavaScript externes.
2.5.7.1 Synchronisation Java – JavaScript
En temps normal, les appels à des fonctions JavaScript depuis Java sont bloquants. Lorsqu'on fait appel à une fonction JavaScript, l'exécution du thread Java est suspendue jusqu'à ce que l'exécution de la fonction se termine ; sa valeur de retour est alors récupérée dans l'environnement Java et l'exécution du thread se poursuit (Fig. 9).
Fig. 9 Diagramme de séquence d'un appel synchrone à une fonction JavaScript
Cependant, pour une raison inconnue, certains de ces appels ne sont pas synchrones. C'està
dire que la fonction call() obtient tout de suite la valeur de retour « null » alors que l'exécution du code JavaScript se poursuit en parallèle (Fig. 10).
Fig. 10 Diagramme de séquence d'un appel asynchrone à une fonction JavaScript
Ce comportement erratique pose problème car, la valeur de retour obtenue étant « null », on ne peut pas connaître le vrai résultat de la fonction JavaScript. De plus, on ne peut pas prédire le comportement de JavaScript lorsqu'on appelle en boucle une fonction de façon asynchrone.
21/50
BAJART / CHARLES
Afin d'éviter tout problème, on décide de rendre synchrones tous les appels à JavaScript. Pour cela, on suspend explicitement le thread Java après chaque appel à JavaScript et on le réveil à la fin de la fonction JavaScript (Fig. 11).
Concrètement, on suspend le thread Java en appelant la méthode « wait() » sur l'objet JSBind. Cette méthode, disponible pour tout objet Java, suspend le thread courant jusqu'à ce qu'un autre thread appelle la méthode « notify() » sur le même objet (Fig. 12 partie gauche).
Fig. 11 Diagramme de séquence de principe pour la synchronisation Java JavaScript
Pour réveiller le thread à la fin de l'exécution de la fonction JavaScript, on appelle la méthode « notifyBind() » de l'applet Java. Cette méthode est appelée depuis l'environnement JavaScript par l'intermédiaire d'une fonction « _notifyBind() » (Fig. 12 partie droite) ayant une portée globale1 de manière à pouvoir être appelée n'importe où (script embarqué dans la page Web, fichier JavaScript externe...).
Fig. 12 Diagramme de séquence pour la synchronisation Java JavaScript
2.5.7.2 Importations de fichiers JavaScript
Pour utiliser les services en ligne, il est nécessaire d'importer des fichiers JavaScript externes. Il existe deux manières d'importer ces fichiers : • statiquement, au chargement de la page, avec la balise « <script> » (List. 6);
<script type="text/javascript" src="js_file.js"></script>
List. 6 Importation statique d'un fichier JavaScript externe
1 En JavaScript, une fonction ayant une portée globale est en fait une méthode de l'objet « window »
22/50
BAJART / CHARLES
• dynamiquement, en appelant une fonction JavaScript (List. 7) durant l'exécution en passant en paramètre l'URL du fichier ;
function importJSFile(url)
{
var script = document.createElement('script');
script.setAttribute('src', url);
script.setAttribute('type', 'text/javascript');
var loaded = false;
var loadFunction = function() {
if (loaded) return;
loaded = true;
};
script.onload = loadFunction;
script.onreadystatechange = loadFunction;
document.getElementsByTagName('head')[0].appendChild(script);
}
List. 7 Fonction pour l'importation dynamique d'un fichier JavaScript externe
Il n'est pas préférable d'importer au chargement de la page tous les scripts nécessaires au fonctionnement du programme. D'une part parce que cela alourdirait le chargement de la page. D'autre part, on souhaite épurer la page HTML de tout contenu « intelligent » en y mettant uniquement ce qui concerne l'affichage.
Un autre problème concerne la compatibilité entre les fichiers JavaScript. En effet, si un jour on souhaite utiliser l'API JavaScript de plusieurs fournisseurs différents, on risque d'importer des fichiers contenant des éléments (variables, fonctions, classes...) portant des noms identiques, ce qui pourrait engendrer des confusions à l'exécution.
C'est pourquoi nous avons décidé d'importer dynamiquement les fichiers JavaScript seulement au moment où on en a besoin. Ainsi, c'est le code Java qui appellera la fonction JavaScript pour importer les fichiers. Celleci nécessite alors une petite modification afin de rendre cet appel synchrone : lorsque le fichier a été complètement chargé, on réveille le thread Java en appelant la fonction « _notifyBind() » (List. 8).
function _importJSFile(url)
{
var script = document.createElement('script');
script.setAttribute('src', url);
script.setAttribute('type', 'text/javascript');
var loaded = false;
var loadFunction = function() {
if (loaded) return;
loaded = true;
_notifyBind(); // Réveil l'applet quand le fichier a été chargé
};
script.onload = loadFunction;
script.onreadystatechange = loadFunction;
document.getElementsByTagName('head')[0].appendChild(script);
}
List. 8 Fonction synchrone pour l'importation dynamique d'un fichier JavaScript externe
23/50
BAJART / CHARLES
2.5.7.3 Injection de code JavaScript depuis Java
Afin de pouvoir être utilisées, les fonctions _notifyBind() et _importJSFile(» doivent être déclarées dans l'environnement JavaScript.
Pour cela, on utilise la méthode eval() (Fig. 13) sur l'objet JSObject « window » (afin que les fonctions aient une portée globale) avec comme paramètre une chaîne de caractère contenant la déclaration de la fonction (Exemple : "function _notifyBind() { … }").
Fig. 13 Diagramme de séquence d'une injection de code JavaScript depuis Java
2.5.8 Services JavaScript
Fig. 14 Classe JSService
Lorsqu'on utilise un service en ligne tel que le géocodeur, on souhaite masquer l'utilisation de JavaScript au programmeur. C'est pourquoi nous avons créé une classe JSService (Fig. 14) qui permet de « se connecter » à l'objet JavaScript qui fournit le service et de faire ainsi abstraction des problèmes de conversion de type, de synchronisation, etc.
La méthode init() permet de lier l'objet à l'environnement JavaScript par l'intermédiaire de la classe JSBind. On attache l'objet de classe JSService à un objet JavaScript (le contexte) par la méthode setContext() en passant en paramètre le nom de l'objet. Par exemple, setContext("googleGeocoder") permet de s'attacher à l'objet JavaScript nommé googleGeocoder). Les méthodes call() et request() permettent d'appeler des fonctions JavaScript, la seconde méthode étant rendue bloquante avec le mécanisme décrit précédemment. En plus des méthodes listées cidessus, la classe JSService possède des méthodes getInt(), getFloat(), getString()... qui permettent de récupérer la valeur des attributs – en passant leur nom en paramètre – de l'objet servant de contexte JavaScript.
Lorsqu'on implémente un service, on crée une classe dérivée de la classe JSService. Par Projet ISIMA 3ème année F2 – Système d'Information Géographique
24/50
BAJART / CHARLES
exemple, la classe GoogleGeocoder hérite de JSService et implémente l'interface Geocoder
(List. 9).
public class GoogleGeocoder extends JSService implements Geocoder { ... }
List. 9 Déclaration de la classe GoogleGeocoder
On répète ce schéma pour les services de recherche d'itinéraire et d'affichage de carte pour obtenir la structure d'héritage décrite sur le diagramme de dépendances (Fig. 15).
Fig. 15 Diagramme de dépendances des services JavaScript
2.5.9 Implémentation du géocodeur
2.5.9.1 Géocodeur de l'API Google Maps
Le service de géocodage est fournit dans l'API Google Maps par l'objet GClientGeocoder. Pour géocoder une adresse, on la passe en paramètre (sous forme de chaîne de caractère) de la méthode getLatLng(), le deuxième paramètre étant une fonction de rappel qui sera appelée quand la requête de géocodage a été effectuée. Sur l'exemple (List. 10), la fonction de rappel affiche une boîte de dialogue contenant le résultat du géocodage.
var geocoder = new GClientGeocoder();
function onResult(pos) {
if (pos) alert("Latitude: " + pos.lat() + " Longitude: " + pos.lng());
else
alert(address + " not found");
);
geocoder.getLatLng("Rue Roche Genès, Aubière", onResult);
List. 10 Utilisation du géocodeur de l'API Google Maps
2.5.9.2 Wrapper JavaScript
L'utilisation de cet objet nécessite un « wrapper » qui prend en compte la synchronisation avec Java. Ce wrapper est écrit dans le fichier GoogleGeocoder.js (List. 11) du package fr.isima.sig.google. Il contient : une instance de la classe GClientGeocoder, la méthode geocode() et la fonction de rappel onResult() qui réveillera le thread Java une fois la requête effectuée. De plus, il possède deux attributs lat (latitude) et lng (longitude) dans lesquels on stock le résultat de la dernière requête de géocodage.
Ce wrapper est instancié à la fin du chargement du fichier GoogleGeocoder.js puis référencée par la variable googleGeocoder dont la portée est définie comme globale.
25/50
BAJART / CHARLES
var GoogleGeocoder = function() { // GoogleGeocoder
this.client = new GclientGeocoder(); // Attributs
this.result = null;
this.lat = 0;
this.lng = 0;
}
GoogleGeocoder.prototype.geocode = function(address) { // Methode 'geocode'
this.client.getLatLng(address, function(point);
googleGeocoder.onSearchResult(point);
});
}
GoogleGeocoder.prototype.onResult = function(point) { // Attributs 'onResult'
if (!point) {
this.result = _JSCode.NOT_FOUND;
} else {
this.lat = point.lat();
this.lng = point.lng();
this.result = _JSCode.SUCCESS;
}
_notifyBind();
}
_global("googleGeocoder", new GoogleGeocoder());
List. 11 Wrapper JavaScript du géocodeur Google
2.5.9.3 Côté Java
A son initialisation, l'objet Java GoogleGeocoder charge le fichier JavaScript GoogleGeocoder.js et s'attache sur le wrapper googleGeocoder (List. 12). Lors d'une requête de géocodage, on appelle la méthode geocode() du wrapper, puis on récupère le résultat stocké dans les attributs lat et lng.
public class GoogleGeocoder extends JSService implements Geocoder
{
...
public boolean init(JSBind bind) {
super.init(bind);
try {
System.out.println("Chargement du géocodeur Google");
bind.importJSFile("js/google/GoogleGeocoder.js");
setContext("googleGeocoder");
return true;
} catch (JSServiceException e) { ... }
}
public Position geocode(Address addr) throws GeographyException {
Object[] params = { addr.toString() };
try {
request("geocode", params); // Lance le géocodage
return new Position(getFloat("lat"), getFloat("lng"));
}
}
List. 12 Implémentation du Géocodeur
26/50
BAJART / CHARLES
On obtient alors la structure décrite sur la figure 16.
Fig. 16 Structure de l'implémentation du géocodeur
2.5.10 Implémentation du calculateur d'itinéraire
2.5.10.1 Calculateur d'itinéraire de l'API Google Maps
L'objet de l'API Google Maps qui fournit le service de recherche d'itinéraire s'appelle GDirections. Après son instanciation, on lui ajoute deux listeners (List. 13) : le premier appelle une fonction de rappel lorsque la requête a été traitée et le deuxième appelle une fonction de rappel en cas d'erreur de traitement (adresse invalide, itinéraire non trouvé, erreur du serveur...).
On lance la recherche d'itinéraire avec la méthode load() en lui passant en paramètre le contenu de la requête sous la forme : "from: <adresse de départ> to: <adresse de
destination>". var dir = new GDirections();
GEvent.addListener(dir, "load", function() {
alert("Distance: " + gdir.getDistance().meters + "m\n" +
"Durée: " + gdir.getDuration().seconds + "s");
});
GEvent.addListener(dir, "error", function() {
alert("Itinéraire non trouvé");
});
dir.load("from: rue Roche Genès Aubière to: rue Mouffetard Paris", {"locale":"fr_FR"});
List. 13 Utilisation du calculateur d'itinéraire de l'API Google Maps
Le wrapper est écrit dans le fichier GoogleRouteFinder.js (List. 14) du package fr.isima.sig.google. Son constructeur crée une instance de la classe GDirections et lui ajoute les deux listeners appelant les fonctions de rappel onLoad() et onError(). Le wrapper possède deux attributs distance et duration (durée) dans lesquels on stock le résultat de la dernière recherche d'itinéraire.
Ce wrapper est instancié à la fin du chargement du fichier GoogleRouteFinder.js puis référencée par la variable globale googleRouteFinder.
27/50
BAJART / CHARLES
var GoogleRouteFinder = function() { // Classe GoogleRouteFinder
this.gdir
= new GDirections(); // Attributs
this.distance = 0;
this.duration = 0;
this.result
= null;
GEvent.addListener(this.gdir, "load", function() {
googleRouteFinder.onLoad();
});
GEvent.addListener(this.gdir, "error", function() {
googleRouteFinder.onError();
});
}
GoogleRouteFinder.prototype.find = function(start, end) { // Méthode 'find'
this.gdir.load("from: " + start + " to: " + end, { "locale" : "fr_FR" });
}
GoogleRouteFinder.prototype.onLoad = function() { // Méthode 'onLoad'
this.distance = this.gdir.getDistance().meters;
this.duration = this.gdir.getDuration().seconds;
this.result = _JSCode.SUCCESS;
_notifyBind();
}
GoogleRouteFinder.prototype.onError = function() { ... } // Méthode 'onError'
List. 14 Wrapper JavaScript du calculateur d'itinéraire Google
2.5.10.3 Côté Java
A son initialisation, l'objet Java GoogleRouteFinder charge le fichier JavaScript GoogleRouteFinder.js et s'attache sur le wrapper googleRouteFinder (List. 12). Lors d'une recherche d'itinéraire, on appelle la méthode find() du wrapper, puis on récupère le résultat stocké dans les attributs distance et duration.
public class GoogleRouteFinder extends JSService implements RouteFinder {
...
public final boolean init(JSBind bind, String mapDiv, String routeDiv) {
super.init(bind);
try {
bind.importJSFile("js/google/GoogleRouteFinder.js");
setContext("googleRouteFinder");
return true;
}
public Route findRoute(Address start, Address end) throws GeographyException
Object[] params = { start.toString(), end.toString() };
{
try {
request("find", params);
Route route = new Route();
route.setDistance(getInt("distance"));
route.setDuration(getInt("duration"));
return route;
}
}
List. 15 Implémentation du calculateur d'itinéraire
28/50
BAJART / CHARLES
2.5.11 Implémentation de l'afficheur de carte
2.5.11.1 Afficheur de carte de l'API Google Maps
Google Maps propose toute une panoplie d'outils permettant de manipuler des cartes géographiques. En faire une liste exhaustive serait fastidieux, c'est pourquoi nous ne décrirons ici que les outils dont nous avons besoin, à savoir : affichage d'une carte sur une page Web, positionnement de marqueurs, recadrage de la carte.
L'objet GMap2 permet d'afficher une carte, on l'attache à un élément HTML (Exemple : en utilisant une balise <div id="map_canvas"></div>, en le passant en paramètre du constructeur (List. 16).
On peut recentrer la carte avec la méthode setCenter() qui prend en paramètre une position et un niveau de zoom.
On crée un marqueur avec la classe GMarker en précisant la position et le titre du marqueur. Celuici peutêtre ajouté à la carte en utilisant la méthode addOverlay() de la classe GMap2.
// Crée la carte dans l'élément de la page dont l'ID est "map_canvas"
var map
= new GMap2(document.getElementById("map_canvas"));
// Crée deux positions
var pos1 = new GLatLng(45.0, 3.0);
var pos2 = new GLatLng(47.2, -1.5);
// Centre la carte sur la premiére position avec le niveau de zoom 13
map.setCenter(pos1, 13);
// Ajoute des marqueurs
map.addOverlay(new GMarker(pos1, { title: "Position 1: ISIMA" }));
map.addOverlay(new GMarker(pos2, { title: "Position 2: rue Mouffetard" }));
// Définit un rectangle contenant la position 1
var bounds = new GLatLngBounds(pos1, pos1);
bounds.extend(pos2); // Etend le rectangle pour englober la position 2
// Recadre la carte sur le rectangle
map.setCenter(bounds.getCenter(), map.getBoundsZoomLevel(bounds));
// Efface les marqueurs
map.clearOverlays();
List. 16 Utilisation de l'afficheur de carte de l'API GoogleMaps
Pour recarder la carte, on crée un rectangle avec la classe GLatLngBounds en passant en paramètre du constructeur la position du coin NordOuest et celle du coin SudEst. On peut ensuite étendre ce rectangle pour qu'il contienne une nouvelle position avec la méthode extend(). Une fois qu'on a définit les limites du rectangle, on récupère les coordonnées de son centre avec getCenter(). Pour connaître le niveau de zoom optimal pour que ce rectangle puisse être contenu entièrement dans la carte, on le passe en paramètre de la méthode getBoundsZoomLevel() de l'objet de classe GMap2 (List. 16).
La figure montre un exemple carte générée par Google Maps.
29/50
BAJART / CHARLES
Fig. 17 Exemple de carte générée par Google Maps
Le wrapper est écrit dans le fichier GoogleMap.js du package fr.isima.sig.google. Son implémentation reprend les mêmes principes que ceux décrits avec le géocodeur et le calculateur d'itinéraire. Il est instancié à la fin du chargement du fichier et référencé par la variable globale googleMap.
2.5.11.3 Côté Java
La classe Java GoogleMap est implémentée de la même manière que les classes GoogleGeocoder et GoogleRouteFinder. Les méthodes de cette classe sont décrites dans le tableau 6.
init(JSBind bind, String div)
Initialise la carte avec le lien JSBind en précisant le nom de l'objet HTML qui servira de conteneur pour la carte
setCenter(Position center, int zoom)
Recentre la carte sur la position « center » en précisant le niveau de zoom
addMarker(Position pos, String title)
Ajoute un marqueur sur la position « pos » avec comme nom « title »
reframe()
Recadre la carte sur le plus petit rectangle contenant tous les marqueurs avec un niveau de zoom optimal
clear()
Enlève tous les marqueurs de la carte
Tab. 6 Méthodes de la classe GoogleMap
2.5.12 Résultat
Il s'agissait là de la partie technique qui nous a posé le plus de problèmes mais ce travail nous a permis de mettre en place une API Java de services géographiques dont les fonctionnalités Projet ISIMA 3ème année F2 – Système d'Information Géographique
30/50
BAJART / CHARLES
peuvent être facilement étendues. Une fois cette tâche achevée, nous avons pu utiliser les services de Google Maps par l'intermédiaire des classes GoogleGeocoder, GoogleRouteFinder et GoogleMap en ayant totalement masqué la partie JavaScript. Projet ISIMA 3ème année F2 – Système d'Information Géographique
31/50
BAJART / CHARLES
DÉVELOPPEMENT DE L'APPLICATION
3 Développement de l'application
3.1 Organisation de l'application
3.1.1 Répertoire de l'application
Le répertoire d'installation de l'application contient tous les fichiers nécessaires à l'exécution du programme. Il est composé :
• d'une archive SIG.jar qui contient le code Java compilé et les différente ressources ;
• d'une répertoire lib/ qui contient les librairies externes utilisées par le programme ;
• d'un répertoire js/ qui contient les fichiers JavaScript qui seront chargés par l'applet ;
• et d'une page Web HTML index.html qui intègre l'applet Java en chargeant le fichier SIG.jar.
3.1.2 Répertoire utilisateur
Lors de la première exécution, l'application crée un répertoire destiné à stocker les données de l'utilisateur.
Le chemin d'accès de ce répertoire est créé à la racine du dossier de l'utilisateur :
• Sous Linux : ~/.sig/
ou $HOME/.sig/
• Sous Windows : C:\Documents and Settings\nom d'utilisateur\SIG\
Par la suite, on utilisera la notation Linux pour parler de ce répertoire mais son contenu est strictement le même quel que soit la plateforme utilisée.
3.2 Fonctionnalités
Le SIG, n'est pas une application ayant une unique fonctionnalité mais il est composé d'un ensemble d'outils géographiques.
Pour valider l'implémentation du package google et la tester simplement nous avons commencé par développer :
• l'outil de géocodage ;
• le calculateur d'itinéraire.
Nous avons ensuite conçu les outils principaux du SIG :
• le gestionnaire de projets ;
• l'extracteur de villes (pour construire une liste de villes à partir d'une banque de données) ;
• le multigéocodeur (qui détermine les coordonnées d'une liste de villes) ;
• le constructeur de distancier.
32/50
BAJART / CHARLES
3.3 Architecture ModèleVueContrôleur
3.3.1 Présentation
Pour développer l'application de manière structurée, nous avons décidé d'utiliser le patron de conception ModèleVueContrôleur (MVC). Cette architecture organise l'interface homme
machine (IHM) d'une application en trois parties (Fig. 18) : le modèle (modèle de données), la vue (présentation à l'utilisateur : console, interface graphique) et le contrôleur (gestion des évènements, synchronisation).
3.3.2 Le Modèle
Le modèle représente le comportement « intelligent » de l'application. C'est lui qui assure la lecture, le traitement et le stockage des données. C'est ce composant qui communique avec des extérieurs. Dans le cadre de notre projet, c'est lui qui fera appel à l'API Google.
Lorsque les données changent, le modèle met à jour la vue.
3.3.3 La Vue
La vue correspond à l'interface dont le rôle est de présenter les données par le modèle et de recevoir les actions de l'utilisateur (clics, entrées au clavier, etc.). Elle doit être épurée de tout traitement, elle doit se contenter d'afficher les résultats et de transmettre les évènements au contrôleur.
3.3.4 Le Contrôleur
Le contrôleur reçoit les évènements de la vue et met à jour le modèle si nécessaire. Son rôle est de transmettre (si nécessaire) les actions au modèle pour le synchroniser avec la vue. Certains traitements effectués par le modèle peuvent prendre du temps (lecture/écriture de fichier, communication avec un autre composant, calcul...). C'est pourquoi à chaque fois que la vue demande une action susceptible du durer longtemps, le contrôleur appelle la méthode du modèle dans un nouveau thread qui se terminera à la fin du traitement. Une telle démarche est nécessaire pour éviter de figer la vue lors du traitement (comportement très désagréable qui donne une mauvaise expérience utilisateur).
Fig. 18 Architecture du patron de conception MVC
3.3.5 Utilisation du patron de conception MVC dans le SIG
Le SIG proposant un ensemble d'outils différents, nous avons structuré l'application en plusieurs sousapplications (le géocodeur, le calculateur d'itinéraire, le gestionnaire de projet, Projet ISIMA 3ème année F2 – Système d'Information Géographique
33/50
BAJART / CHARLES
l'extracteur de villes, le multigéocodeur et le constructeur de distancier) qui implémente chacune le patron MVC, chaque vue étant intégrée dans la fenêtre principale sous forme d'onglet.
Les contrôleurs étant des composants assez simples et assez semblables dans toutes les sous
applications citées cidessus, nous ne détaillerons dans ce rapport que les modèles et les vues de chacun des outils.
3.4 Outils de développement pour l'interface graphique
Pour concevoir les vues, nous avons utilisé la bibliothèque Swing qui propose une grande quantité de composants permettant la création d'interface graphique. De plus, cette bibliothèque est totalement adaptée à l'architecture de l'application car elle utilise intrinsèquement le patron de conception MVC.
3.5 Géocodeur
3.5.1 Vue
L'onglet « Géocodage » (Fig. 19) comporte : • un formulaire de saisie d'adresse ;
• un bouton « Géocode » permettant de lancer le géocodage de l'adresse ;
• des champs de texte « Latitude » et « Longitude » où sont inscrits les résultats des requêtes de géocodage ; • une console de sortie.
L'utilisation d'une console de sortie est une méthode très simple pour afficher l'état du programme, les traitements en cours ou finis et les éventuelles erreurs. Fig. 19 Onglet « Géocodage »
34/50
BAJART / CHARLES
En plus de ces éléments, une carte affichant la position de l'adresse géocodée est affichée sur la page Web après chaque requête.
3.5.2 Modèle
Le modèle de l'outil de géocodage utilise la classe GoogleGeocoder pour retrouver les coordonnées de l'adresse envoyée par la vue.
Une fois la requête effectuée, il met à jour la vue en lui envoyant la position de l'adresse géocodée (Fig. 20).
Il se sert ensuite de la classe GoogleMap pour afficher la carte et y placer le marqueur.
Fig. 20 Diagramme de séquence du modèle de l'outil de géocodage
3.6 Recherche d'itinéraire
3.6.1 Vue
L'outil de recherche d'itinéraire dans l'onglet « Recherche d'itinéraire » est composé de deux formulaires de saisie d'adresse : un pour le départ, un autre pour l'arrivée. Comme pour le géocodage, on lance par l'intermédiaire d'un bouton et on surveille le statut du programme avec la console de sortie.
Lorsqu'une requête est effectuée, la carte indiquant le tracé de la route et les instructions de conduite sont affichées sur la page Web (Fig. 21).
3.6.2 Modèle
Le modèle de l'outil de recherche d'itinéraire est très proche de celui de l'outil de géocodage. Cependant, la carte et les instructions ne sont pas affichées à l'aide de classe Java GoogleMap mais directement générées par l'objet JavaScript GDirections de l'API Google Maps. Projet ISIMA 3ème année F2 – Système d'Information Géographique
35/50
BAJART / CHARLES
Fig. 21 Onglet « Recherche d'itinéraire » avec carte et directions
36/50
BAJART / CHARLES
3.7 Organisation des projets
Pour faciliter l’utilisation de notre logiciel, nous avons choisi une organisation sous forme de projet. L’utilisateur peut donc créer à tout moment un nouveau projet et ensuite travailler dedans. Cela permet de retrouver facilement des données générées précédemment et de pouvoir les modifier très rapidement.
On stocke les projets dans le répertoire ~/.sig/projects. Les fichiers de chaque projet sont stockés dans un répertoire qui porte le nom du projet.
Exemple : le répertoire du projet « Auvergne » est ~/.sig/projects/Auvergne
Un projet est constitué de fichiers texte :
• cities : liste des villes ;
• positions : coordonnées des villes ;
• distances : distancier contenant les longueurs de trajets ;
• durations : distancier contenant les temps de trajets.
L'onglet « Projet » est organisé en sousonglets permettant différentes actions :
• Liste des projets ;
• Sélection des villes ;
• Coordonnées des villes ;
• Construction du distancier.
En outre, un indicateur en bas à droite de la fenêtre permet de vérifier quel projet est actuellement sélectionné. Cet indicateur est visible quel que soit le l'onglet actif.
3.8 Liste des projets
3.8.1 Vue
Cet onglet est là pour sélectionner le projet dans lequel nous voulons travailler, créer un nouveau projet, le modifier ou encore le supprimer. Cet onglet est constitué de la liste (JList) contenant le noms des projets existants. Lorsqu'aucun projet n'est sélectionné, la seule action possible est de créer un projet, les autres onglets et boutons sont inaccessibles. Lorsqu'on crée un nouveau projet, une boîte de dialogue s'ouvre pour y entrer le nom. Quand on sélectionne un projet dans la liste, les autres onglets et boutons sont activés. Le bouton « Paramètres » affiche la boîte de dialogue permettant de modifier le nom du projet. Il y a enfin un bouton permettant de supprimer un projet. Ce projet sera donc effacé de la liste, son répertoire et tous ses fichiers seront supprimés.
37/50
BAJART / CHARLES
Le thème graphique de l'application s'adapte au Look & Feel de l'environnement de l'utilisateur. Fig. 22 Onglet « Liste des projets »
Look & Feel GTK sous Linux
Fig. 23 Onglet « Liste des villes »
Look & Feel Windows sur la plateforme de Microsoft
38/50
BAJART / CHARLES
3.9 Sélection des villes
3.9.1 Objectif
Cette partie de l'application permet de générer une liste réelle de point de passages. Ces points sont en fait des villes pouvant être choisies parmi l'ensemble des villes présentes dans la base de données INSEE que nous avons récupérée. Ainsi, nous travaillons sur des données réelles et non pas sur des données réalistes mais synthétiques.
3.9.2 Données
La base de données INSEE, initialement au format XLS (Microsoft Excel), contenait la liste de toutes les villes françaises identifiée par leur nom et leur code INSEE. Nous disposions, en plus, d'informations supplémentaires comme le numéro de département, le code postal et le nombre d'habitants (remarque : ces données dates de 1990).
Cette feuille Excel de plus de 36 000 lignes contenait d'autres informations dont nous n'avons pas besoin, de plus, le format XLS est assez contraignant à gérer. C'est pourquoi nous avons extrait seulement les informations utiles – à savoir, le nom de la ville, le code postal, le numéro de département et le nombre d'habitants – en les stockant dans des fichiers CSV.
Chaque fichier porte un nom contenant le numéro du département et contient sur chaque la liste des villes du département en question triée par code postal, puis par nom (deux villes peuvent avoir un même code postal). Chaque ligne contient : le code postal, le nom de la ville et le nombre d'habitants.
3.9.3 Vue
Une fois le projet sélectionné, l’utilisateur peut passer à l’onglet suivant : « Sélection des villes » (Fig. 23). Cet onglet permet de sélectionner facilement toutes les villes que nous voulons rattacher à ce projet et qui seront, par la suite, utilisées pour la création du distancier. Les villes peuvent être sélectionnées selon deux critères : le département et nombre minimal d'habitants. On sélectionne d'abord le ou les départements d'où on souhaite extraire les villes, puis on filtre le résultat en choisissant un nombre minimal d'habitant grâce à la glissière. La liste des villes pouvant être ajoutées au projet apparaît dans la liste en bas à gauche (Fig. 23). Cette liste de ville sest mise à jour au moindre déplacement de la glissière et à chaque modification de la sélection des départements.
Les valeurs extrêmes de la glissière sont 0 et 500 000 habitants. Cependant, ces bornes évoluent en fonction du nombre de départements sélectionnés. Par exemple, pour 20 départements, l'intervalle vaut [10 000, 1 000 000]. Lorsqu'on les sélectionne tous, l'intervalle vaut [50 000, 1 000 000]. Nous avons choisi ce comportement pour éviter de faire apparaître trop de villes dans la liste en bas à gauche. D'une part, un trop grand nombre d'éléments dans une liste rend difficile sa lecture. D'autre part, sans cette limitation, la mise à jour de la liste prendrait beaucoup de temps lorsqu'on sélectionne un grand nombre de départements avec un nombre minimal d'habitants peu élevé.
La liste en bas à droite représente la liste des villes que contient le projet. On agrandit cette liste en ajoutant : toutes les villes de la liste de gauche ou seulement une sélection. On réduit cette liste en supprimant une sélection de ville ou en la vidant complètement. Projet ISIMA 3ème année F2 – Système d'Information Géographique
39/50
BAJART / CHARLES
3.9.4 Modèle
Le modèle de l'extracteur de ville reçoit trois types d'évènements qui sont chacun associé à un traitement (Tab. 7). Événement
Traitement
Modification de la sélection des départements
Ouvre les fichiers des nouveaux départements sélectionnés (sauf si leur contenu est déjà chargé en cache) et met à jour la liste des villes pouvant être selectionnée
Modification de la valeur du nombre minimal d'habitants
Crée une liste de villes à partir des département sélectionnés en filtrant sur le nombre d'habitants
Modification de la liste des villes du projet
Réécrit le fichier ~/.sig/project/<projet_courant>/cities en y inscrivant la nouvelle liste de villes
Tab. 7 Traitements effectués par le modèle de l'extracteur de villes
63170
63110
63400
63140
63000
63800
63200
63530
Aubière
Beaumont
Chamalières
Châtelguyon
Clermont-Ferrand
Cournon-d'Auvergne
Riom
Volvic
List. 17 Exemple de fichier contenant la liste des villes d'un projet
Les villes inscrites dans le fichier « cities » du projet sont identifiées par leur code postal et leur nom (Exemple : List. 17).
3.10 Coordonnées des villes
3.10.1 Objectif
Afin de pouvoir placer les villes sur une carte, on souhaite connaître la position géographique des villes sélectionnées dans le projet. C'est pourquoi nous avons besoin d'un « multi
géocodeur » permettant de géocoder une liste d'adresse et d'enregistrer les coordonnées.
3.10.2 Vue
La vue est composée :
• d'un bouton pour lancer le géocodage ;
• d'une barre de progression pour surveiller l'avancement du traitement ;
• d'une console de sortie.
Au fur et à mesure que le traitement avance, le résultat des requêtes de géocodage est affiché dans la console de sortie. À la fin du traitement, les différentes villes sont mis en évidence sur la carte à l'aide de marqueurs (Fig. 24).
40/50
BAJART / CHARLES
Fig. 24 Onglet « Coordonnées des villes » et position des villes sur la carte
41/50
BAJART / CHARLES
3.10.3 Modèle
Le modèle ouvre le fichier contenant la liste des villes et effectue un géocodage pour déterminer une à une la position des villes.
Google autorise un nombre de géocodage limité, c'est pourquoi il faut économiser le nombre de requêtes en évitant de géocoder deux fois la même ville. Pour cela, on stocke le résultat des requêtes dans un cache. On accède au cache en appelant la méthode geocode() de la classe CacheGeocoder qui implémente l'interface Geocoder. Cette classe possède en plus une méthode register() qui permet d'enregistrer la position d'une nouvelle ville. Le géocodage se déroule ainsi : on regarde d'abord si la ville est déjà présente dans le cache ; si c'est le cas, on dispose immédiatement des coordonnées ; sinon on effectue une requête de géocodage avec la classe GoogleGeocoder et on enregistre le résultat dans le cache.
Fig. 25 Algorigramme de principe de l'utilisation cache du géocodeur
Dans le cas où une requête échoue à cause d'un problème du serveur distant ou d'une erreur inconnue, le modèle effectue jusqu'à quatre nouvelles tentatives.
Une fois le traitement achevé, on place les marqueurs de chaque position sur la carte à l'aide de la classe GoogleMap et on la recadre avec le centrage et le niveau de zoom optimal. 3.10.4 Cache
Les données du cache sont situées dans le répertoire ~/.sig/cache/positions/. On structure le cache regroupant les données, par pays puis par département. Le format d'une entrée dans un fichier est :
<numéro de département> <nom de ville>\t<latitude>,<longitude>
42/50
BAJART / CHARLES
Ainsi la position de la ville de Nice (06100) sera stockée dans le fichier ~/.sig/cache/positions/France/06. La ligne qui correspond à cette entrée est :
06100 Nice
43.72758,7.2598915
Ce stockage arborescent permet de retrouver très rapidement une entrée dans le cache. Son utilisation à alors deux conséquences : on limite le nombre de requêtes auprès du fournisseur de services et on accélère le traitement d'un géocodage multiple. Ce traitement est d'autant plus rapide que la taille du cache croît au fur et à mesure qu'on utilise l'application.
3.11 Création du distancier
3.11.1 Objectif
Le but de ce dernier outil est de construire le distancier à partir de la liste des villes. Pour une liste de taille n , ce distancier correspond une matrice M n ,n dont chaque composante c ij est égale à la longueur (métrique ou temporelle) du trajet qui sépare les villes i et j.
Cette matrice est particulière puisque sa diagonale est composée de zéros (la distance entre une ville et ellemême est nulle). De plus, en supposant que le trajet de i vers j est strictement le j vers i , on peut affirmer que c ij=c ji et que nous avons à faire à une matrice nn−1  .
symétrique. Le nombre de que trajets à évaluer est donc égal à trajet inverse de 2
3.11.2 Vue
La vue est pratiquement identique à celle de l'onglet précédent (Fig. 26). La console de sortie affiche le résultat de chaque requête d'itinéraire.
Fig. 26 Onglet « Construction du distancier »
43/50
BAJART / CHARLES
3.11.3 Modèle
Comme précédemment, le modèle utilise un cache faisant appel à la classe CacheRouteFinder qui implémente l'interface RouteFinder.
Au fur et à mesure du traitement, on remplit deux matrices n×n distances (métrique) et durations (temporelle) avec le résultat des requêtes de géocodage. Lorsque toutes les requêtes ont été exécutées, on enregistre les matrices dans les fichiers du même nom.
Les matrices sont stockées sous forme de fichier texte en séparant les colonnes par tes tabulations et les lignes par des retours à la ligne. Les distances sont exprimées en mètres et les durées en secondes.
cities
63170 Aubière
75001 Paris
59800 Lille
distances
0
427726
639391
427726
0
26095
durations
639391 0
26095 14465
0
20913
14465
0
7915
20913
7915
0
Tab. 8 Liste des villes et distanciers
3.11.4 Cache
Lorsqu'on détermine le trajet entre deux villes, par exemple Paris – Lille, on stocke sa longueur (métrique et temporelle) à deux endroits :
Sens aller : • Fichier : ~/.sig/cache/routes/France/75/75001\ Paris
• Ligne : 59000 Lille
226095
7915
Sens retour : • Fichier : ~/.sig/cache/routes/France/59/59000\ Lille
• Ligne : 75001 Paris
226095
7915
Ainsi, le fichier ~/.sig/cache/routes/France/75/75001\ Paris contiendra tous les trajets au départ de Paris.
3.12 Déploiement du SIG
3.12.1 Conditions préalables
3.12.1.1 Java
Pour exécuter l'applet dans le navigateur, il est indispensable de disposer du plugin Java 1.6. À l'heure actuelle, cette version n'est pas encore disponible pour Mac OS X.
3.12.1.2 Serveur Web
Pour pouvoir utiliser l'application, on doit disposer d'un serveur Web tel que le logiciel Apache. Il est fournit de base ou sous forme de package à installer dans la plupart des distributions Linux. Sous Windows, la méthode la plus simple pour l'obtenir est sans doute d'installer la suite Projet ISIMA 3ème année F2 – Système d'Information Géographique
44/50
BAJART / CHARLES
EasyPHP.
Mais on peut tout à fait se passer de serveur Web local en utilisant hébergeur, l'important étant de pouvoir accéder à l'application grâce à une URL HTTP.
Par exemple :
• http://localhost/
• http://fc.isima.fr/~username/
• http://foo.free.fr/
• etc.
3.12.2 Clé Google
Pour pouvoir utiliser les services de Google Maps, il faut obtenir une clé en se rendant à l'adresse :
http://code.google.com/intl/fr/apis/maps/signup.html
Cette page d'inscription contient un formulaire où l'on doit entrer l'URL à partir de laquelle sera utilisée l'API. Si on a installé le serveur Apache en local, il s'agit de : http://localhost/.
La clé ainsi obtenue sous forme de chaîne de caractères doit être copiée dans le fichier :
Sous Linux : ~/.sig/googlekey
Sous Windows :
C:\Document and Settings\<utilisateur>\SIG\googlekey (sans extension)
3.12.3 Installation du SIG
Il faut ensuite ensuite extraire l'archive sig.tar.gz dans le répertoire racine du serveur web :
Sous Linux :
/var/www (ou ~/public_html si l'option UserDir d'Apache est activée)
Sous Windows :
C:\Program Files\EasyPHP 3.0\www\
3.12.4 Lancement de l'application
Firefox :
L'accès à l'application se fait en ouvrant la page suivante avec le navigateur Mozilla http://localhost/sig/ ou http://localhost/~username/sig/ si on utilise l'option UserDir d'Apache
45/50
BAJART / CHARLES
Si le domaine est différent, il suffit d'adapter l'URL. Exemples :
http://fc.isima.fr/~username/sig/
http://foo.free.fr/sig/
Au premier lancement, une fenêtre apparaît (Fig. 27) pour demander la validation d'un certificat. Cette validation est nécessaire pour que le navigateur autorise l'applet à lire et écrire des fichiers sur le disque dur.
Fig. 27 Certificat autorisant l'applet à accéder au disque dur
3.12.5 Bugs connus
Nous avons rencontré plusieurs bugs, survenant de manière totalement erratique, que nous n'avons pas su résoudre :
Applet qui ne charge pas : Si aucune exception Java n'est levée, cela provient sans doute d'un bug du navigateur ou du plugin Java.
Brusque fermeture du navigateur lors de l'utilisation de l'applet : Il s'agit vraisemblablement d'un bug (erreur de segmentation) de Mozilla Firefox.
Impossible de saisir des données au clavier dans les champs de texte
Dans la plupart des cas, recharger la page Web ou redémarrer le navigateur corrige le problème.
3.13 Améliorations pouvant être apportées au logiciel
Ce SIG peutêtre amélioré sur plusieurs points :
• Il serait intéressant de pouvoir se passer du navigateur en utilisant, non plus une applet, mais une application autonome. Pour cela, il faudrait tenter de trouver une API Java qui fournit les mêmes services que Google Maps.
• On souhaiterai pouvoir afficher le tracé des itinéraires sur les cartes. Cependant, cela exige de pouvoir stocker les points de passages dans un fichier. L'idée est donc de trouver le moyen de sérialiser (ou extraire le contenu) de l'objet GRoute de l'API Google Maps.
46/50
BAJART / CHARLES
CONCLUSION
CONCLUSION
Le développement du SIG géographique à globalement suivit le planning prévu, même si quelques difficultés techniques ont parfois ralenti notre progression et la plupart des fonctionnalités demandées au départ ont été implémentées. Nous avons travaillé l'ergonomie de l'interface graphique pour faciliter la navigation au sein de ce logiciel et permettre à n’importe qui de pouvoir l’utiliser. Les objectifs ont donc bien été atteints.
La principale difficulté rencontrée au cours du développement fut l'intégration des services de JavaScript de Google Maps dans le programme Java. En effet, nous avons du comprendre comment une tel communication était possible et nous rediriger vers une applet Java plutôt qu’une application Java.
Ce projet nous a permis de mieux comprendre le fonctionnement d’un SIG et ce qu’il est possible de faire avec différentes technologies Web mises à disposition gratuitement. Nous avons appris à utiliser ces technologies écrites en JavaScript au sein d’un programme Java. Il nous a aussi permis de maîtriser le langage JavaScript et d'acquérir une expérience supplémentaire (en particulier pour l'organisation du projet, le patron de conception MVC et la création d'une interface ergonomique avec Swing) quant au développement d'un programme Java conséquent.
Notre logiciel va pouvoir aider plusieurs enseignantschercheurs dans leurs recherches et dans leurs communications. Dans les mois à venir, d'autres étudiants de l'ISIMA seront sûrement amenés à reprendre ce projet afin de faire évoluer l'application pour mieux prendre en compte les attentes des clients.
47/50
BAJART / CHARLES
GLOSSAIRE
GLOSSAIRE
Applet
Une applet est un logiciel qui s’exécute dans un navigateur web.
Cache
Un cache est un élément de stockage permet d'enregistrer des résultats de traitement afin de pouvoir les retrouver de manière efficace sans avoir à recommencer le traitement.
CSS
Cascading Style Sheets (feuilles de style en cascade) est un langage informatique qui notamment sert à décrire la présentation, la mise en forme des documents HTML. CSV
CommaSeparated Values est un format de fichiers texte permettant de stocker des données ligne par ligne en séparant les champs par des virgules ou pointvirgules.
Distancier Matrice qui stocke les longueurs (métrique ou temporelle) des trajets entre tous les couples possibles d'une liste de villes.
Fonction de rappel Une fonction de rappel, souvent appelée « calback », est une fonction passée en argument qui peutêtre appelée dans le corps d'une autre fonction.
Heuristique Méthode de résolution de problème qui fournit une solution acceptable sans pour autant garantir l’optimalité
Listener Le listener, en français « écouteur », est le terme anglais utilisé de façon générale en informatique pour qualifier un élément logiciel qui est à l'écoute d'évènements afin d'effectuer des traitements.
Look & Feel
Le look & feel d'une interface graphique correspond à l'ensemble des caractéristiques visuelles qui donne une identité au logiciel. Il s'agit des polices de caractères, de leur taille, des formes des composants de l'interface, de leur couleurs, de leur disposition, etc.
48/50
BAJART / CHARLES
GLOSSAIRE
NPcomplet
En théorie de la complexité, un problème NPcomplet désigne un problème dont les solutions ne peuvent pas être déterminées dans un temps polynomiales. Le temps de résolution croît de façon exponentiel avec la taille du problème.
Porté d’une variable
La portée lexicale d'une variable définit sa visibilité dans le code source du programme. Elle peutêtre locale (visible seulement à l'intérieur d'une fonction où d'une classe) ou globale (visible partout dans le code source).
URL
Une URL, de l'anglais Uniform Resource Locator, littéralement « localisateur uniforme de ressource », est une chaîne de caractères utilisée pour adresser les ressources du World Wide Web.
Wrapper Un « wrapper » ou « adaptateur » en français permet de convertir l'interface d'un composant logiciel en une autre interface dans le but de pouvoir le faire communiquer avec d'autres composants qui n'auraient pas pu le faire autrement à cause d'une incompatibilité d'interfaces.
49/50
BAJART / CHARLES
Communication Java JavaScript
https://developer.mozilla.org/en/Gecko_Plugin_API_Reference/Scripting_plugins
https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/LiveConnect_Overview/
https://developer.mozilla.org/en/LiveConnect
http://www.docjar.com/docs/api/netscape/javascript/JSObject.html
http://www.apl.jhu.edu/~hall/java/JavaScriptfromJava.html
Documentation des fournisseurs de services géographiques
http://code.google.com/apis/maps/documentation/
http://dev.viamichelin.fr/wswebsite/fra/jsp/vmdn/VMDNApiMapsDriveReference.jsp
http://apipro.mappy.com/
Implémentation du patron de conception ModèleVueContrôleur
http://baptistewicht.developpez.com/tutoriel/conception/mvc/
Documentation des packages Java standards
http://java.sun.com/j2se/1.4.2/docs/api/
50/50

Projet ISIMA 3ème année F2

Transcription

Documents pareils

Lotus Notes Domino v7/v8, JavaScript

CV - Jean David Olekhnovitch

Diplomatic-Cover - Top Interactive Agencies

Julien Kronegg - Log(psycho)Analyst

A B E D C SITUER UN POINT C A D E F B SUR UNE FEUILLE

OFC Flow Manager

Utilisation du navigateur Internet Explorer 6

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

Descriptif mission en alternance : Caterpillar Grenoble Equipe

responsable informatique - Loi fonctionnelle/cv de Rodolphe LOUE