Recensement de La Faune Avec PDA (.AXF D'arcpad

Recensement de la faune à
l'aide d'un PDA
Mémoire de diplôme en informatique Aurélien Poscia

Laboratoire de didactique informatique

c Laboratoire de didactique informatique 27 novembre 2008
Table des matières
1 Introduction 1
1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Organisation du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Capture des besoins 3

2.1 Préambule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Identication des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1 Responsable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.2 Observateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.3 Interrogateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.4 Combinaisons des rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Entités de l'application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1 FauneTracker - PDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.2 FauneTracker - Conguration . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.3 FauneTracker - Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Données à saisir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 SVG et Java pour une plate-forme mobile 7

3.1 Préambule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Normes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Dénitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2 Java 2 Micro Edition (J2ME) . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.3 Conguration J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.4 Prol J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.5 Connected Device Conguration(CDC) . . . . . . . . . . . . . . . . . . . 10
3.3.6 Connected Limited Device Conguration (CLDC) . . . . . . . . . . . . . 10
3.3.7 Mobile Information Device Prole (MIDP) . . . . . . . . . . . . . . . . . 10
3.4 SVG sur PDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1 Langage hôte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.3 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5 SVG sur téléphone mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
i
TABLE DES MATIÈRES ii
4 Produits ESRI 14
4.1 Préambule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Bureautique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Nomade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5 ArcPad et ArcPad Application Builder 17

5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Fichier de conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3 Fichier de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.1 Contenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.2 Formulaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3.3 Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6 Préparation de l'implémentation 23
6.1 Préambule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2 Environnement de développement et de tests . . . . . . . . . . . . . . . . . . . 23
6.2.1 Conguration réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2.2 Conguration logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3 Structures de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3.1 Schéma de base de données . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3.2 Schéma pour implémentation sur le PDA . . . . . . . . . . . . . . . . . 26
6.3.3 Pictogrammes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.3.4 Carte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7 FauneTracker - Conguration 28
7.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2 Fichier de mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2.1 Rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2.2 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2.3 Génération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.4 Accès base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.5 Organisation des composants graphiques . . . . . . . . . . . . . . . . . . . . . . 32
7.5.1 Organisation hiérarchique . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.5.2 Motif de conception template method . . . . . . . . . . . . . . . . . . . 33
8 FauneTracker - PDA 36
8.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.2 Achage et navigation sur une carte . . . . . . . . . . . . . . . . . . . . . . . . 37
8.3 Lecture du chier de mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.4 Navigation GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.6 Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.7 Saisie d'une observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.7.1 Ajout de données sur la carte . . . . . . . . . . . . . . . . . . . . . . . . 44
TABLE DES MATIÈRES iii
8.7.2 Collecte des informations . . . . . . . . . . . . . . . . . . . . . . . . . . 46

8.8 Filtrage des informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.9 Hiérarchie des composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
9 FauneTracker - Desktop 52
9.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.2 Gestion des droits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.3 Informations sur une observation . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.4 Édition d'une observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.4.1 Géographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.4.2 Attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
10 Déploiement 59
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
10.2 Déploiement de FauneTracker pour PC . . . . . . . . . . . . . . . . . . . . . . . 59
10.3 Déploiement de FauneTracker - PDA . . . . . . . . . . . . . . . . . . . . . . . . 59
10.3.1 Génération d'un cache de cartes . . . . . . . . . . . . . . . . . . . . . . . 59
10.3.2 Génération d'un chier cab . . . . . . . . . . . . . . . . . . . . . . . . . 60
10.3.3 Installateur Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
11 Conclusion 63
Bibliographie 65
A Liens utiles 66
B Codes sources 67
B.1 Organisation des paquetages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
B.2 Code source de FauneTracker - Conguration . . . . . . . . . . . . . . . . . . . 68
B.2.1 FauneTracker - Conguration - Activites . . . . . . . . . . . . . . . . . . 84
B.2.2 FauneTracker - Conguration - Classes . . . . . . . . . . . . . . . . . . . 96
B.2.3 FauneTracker - Conguration - Especes . . . . . . . . . . . . . . . . . . 108
B.2.4 FauneTracker - Conguration - XML . . . . . . . . . . . . . . . . . . . . 123
B.3 Code source de FauneTracker - PDA . . . . . . . . . . . . . . . . . . . . . . . . 130
B.3.1 FauneTracker - PDA - Authentication . . . . . . . . . . . . . . . . . . . 152
B.3.2 FauneTracker - PDA - MachinesEtats . . . . . . . . . . . . . . . . . . . 155
B.3.3 FauneTracker - PDA - MachinesEtats - Etats . . . . . . . . . . . . . . . 171
B.4 Code source de FauneTracker - Desktop . . . . . . . . . . . . . . . . . . . . . . 191
B.5 Code source de FauneTracker - Commun . . . . . . . . . . . . . . . . . . . . . . 212
B.6 Code source de FauneTracker - Communs - Windows . . . . . . . . . . . . . . . 213
Table des gures
2.1 Diagramme des cas d'utilisations de l'application. . . . . . . . . . . . . . . . . . 4

3.1 Diérences entre un format matriciel et vectoriel. . . . . . . . . . . . . . . . . . 7
3.2 Dessin SVG, correspondant au code du listing 3.1. . . . . . . . . . . . . . . . . 8
3.3 Empilement J2ME/J2SE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Exemple de ux pour un Midlet. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Gamme ArcGIS (source : ESRI). . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1 Synchronisation des données depuis ArcPad jusqu'au serveur. . . . . . . . . . . 17
5.2 Conguration par défaut d'ArcPad (gauche) et personnalisée (droite). . . . . . 18
5.3 Exemple de formulaire d'ajout, avec aide à la saisie et guidage étape par étape. 20
6.1 Réseau mis en place. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2 Schéma UML théorique de la base de données. . . . . . . . . . . . . . . . . . . 25
6.3 Schéma UML de la base de données créée. . . . . . . . . . . . . . . . . . . . . . 26
6.4 Carte créée pour l'application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1 Interface graphique de FauneTracker - Conguration. . . . . . . . . . . . . . . . 28
7.2 Décomposition graphique des composants du GUI. . . . . . . . . . . . . . . . . 32
7.3 Composants du GUI, structure de classes. . . . . . . . . . . . . . . . . . . . . . 33
7.4 Implémentation du design pattern Template Method. . . . . . . . . . . . . . . . 34
7.5 Diagramme de classes simplié de FauneTracker - Conguration. . . . . . . . . 35
8.1 FauneTracker PDA, achage de la carte (gauche) et saisie de l'espèce (droite). 36
8.2 Principe de fonctionnement de l'authentication. . . . . . . . . . . . . . . . . . 41
8.3 Machine à états de la saisie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.4 Machine à états de la création d'un ltre. . . . . . . . . . . . . . . . . . . . . . 48
8.5 Diagramme de classes du motif de conception état. . . . . . . . . . . . . . . . . 49
8.6 Diagramme de classes simplié de FauneTracker - PDA. . . . . . . . . . . . . . 51
9.1 Interface graphique de FauneTracker Desktop. . . . . . . . . . . . . . . . . . . . 53
9.2 Formulaire d'édition des attributs d'une observation. . . . . . . . . . . . . . . . 56
9.3 Diagramme de classes simplié de FauneTracker - Desktop. . . . . . . . . . . . 58
10.1 Génération du cache de carte et synchronisation. . . . . . . . . . . . . . . . . . 60
10.2 Création du chier d'installation CAB. . . . . . . . . . . . . . . . . . . . . . . . 60
10.3 Fonctionnement de l'installateur Windows. . . . . . . . . . . . . . . . . . . . . . 62
iv
Listings
3.1 Exemple de code source SVG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Exemple de chier de conguration. . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Création et exécution du ltre sur les animaux. . . . . . . . . . . . . . . . . . . 21
7.1 Exemple de chier de mission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2 Exemple d'accès à la base de données. . . . . . . . . . . . . . . . . . . . . . . . 30
7.3 Création d'un objet connexion. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1 Méthode d'ouverture du service mobile. . . . . . . . . . . . . . . . . . . . . . . 37
8.2 Création de l'outil de zoom en avant. . . . . . . . . . . . . . . . . . . . . . . . . 38
8.3 Exemple d'aectation d'un outils à la carte. . . . . . . . . . . . . . . . . . . . . 38
8.4 Lecture du chier de mission (implémentation du motif de conception singleton ). 39
8.5 Conguration et connexion du GPS. . . . . . . . . . . . . . . . . . . . . . . . . 40
8.6 Génération d'un condensé md5. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.7 Synchronisation des données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.8 Vérication du bon déroulement de la synchronisation. . . . . . . . . . . . . . . 43
8.9 Préparation de l'édition de la couche. . . . . . . . . . . . . . . . . . . . . . . . . 44
8.10 Validation du dessin et lancement du processus de saisie. . . . . . . . . . . . . . 45
8.11 Interface IEtats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.12 Méthode suivant(), dénie par l'interface IEtats. . . . . . . . . . . . . . . . . . 47
8.13 Illustration du design pattern template method. . . . . . . . . . . . . . . . . . . 50
9.1 Méthode selectionAction_StatusChanged de FrmMain. . . . . . . . . . . . . . . . 54
9.2 Méthode choisirOutil() de FrmMain. . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.3 Méthode pour enregistrer les modications (enregistrerModication_click ). . . . 56
10.1 Code du chier de conguration ini. . . . . . . . . . . . . . . . . . . . . . . . . 61
10.2 Lancement du gestionnaire d'applications Windows Mobile. . . . . . . . . . . . 61
v
Avant-propos
Conventions typographiques
Dans un souci de clarté ainsi que pour simplier la tâche du lecteur, plusieurs conventions
typographiques et de style ont été adoptées pour la rédaction de ce mémoire :
l'essentiel des textes sont typographiés à l'aide de la police Computer Modern dans une
taille de caractère de 11 points ;
les identicateurs de classes, des tables de données, des balises XML ainsi que les ins-
tructions et les noms de dossiers sont tracés en caractères de types machine à écrire ;
les noms de méthodes et d'identicateurs ainsi que les mots anglais sont écrits en italique ;
enn, les notions importantes ou les mots clés d'un paragraphe sont mis en évidences à
l'aide d'une graisse de caractère supérieure.
Les extraits de codes sont colorés selon des conventions proches de celles utilisées par Visual
Studio. Les légendes des images gurent au-dessus de celles-ci alors que les captions des pièces
de codes sont situées en-dessous des extraits de codes. Les référence internes, sont indiquées
en rouge et les adresses internet sont mises en évidence à l'aide de la couleur bleu-clair.
Remerciements
Avant tout, je tiens à remercier les professeurs qui m'ont instruits durant ces trois années
de scolarité à l'École d'ingénieurs de Genève et qui m'ont permis d'arriver jusqu'ici. Parmi
ceux-ci, je remercie particulièrement M. Lazeyras, mon professeur de diplôme, pour ses conseils
avisés, pour la relecture de mon mémoire et pour son humour au quotidien.
Je remercie Mrs. Meyer, Travaglini et Dubois pour m'avoir fourni les diérents logiciels,
périphériques et données géographiques nécessaires à la réalisation de ce projet de diplôme.
J'adresse aussi mes remerciements à Mrs. Yannic et Francey de l'École d'ingénieurs de
Lullier, pour avoir pris le temps de m'aider à dénir et cibler les besoins des services de gardes-
faune, ainsi que d'avoir suivi l'évolution du projet, tout en émettant des critiques constructives
et de nouvelles idées pour celui-ci.
Merci à ma famille d'avoir relu avec attention ce mémoire, de m'avoir encouragé tout au
long de mes études et sans qui, bien entendu, rien de tout cela n'aurait été possible.
Je remercie mes collègues de promotion Mrs Bell, Domenicucci , Gomez et Thévenoz, pour
la bonne humeur qu'ils ont gardée tout au long de ce travail de diplôme, même durant les
moments les plus stressants. Je les remercie également pour les conseils qu'ils m'ont donnés
pour la rédaction de ce mémoire. Finalement, merci Red BullTM de m'avoir tenu éveillé durant
ces longues mais néanmoins passionnantes journées et nuits de travail.
vi
Chapitre 1
Introduction
1.1 Contexte
Les gardes-faune des diérents cantons suisses n'utilisent actuellement aucun moyen unié
de recensement de la faune. De plus, à l'intérieur d'un même service de gestion de la faune,
plusieurs gardes peuvent utiliser leur propre méthode de saisie, parfois très rudimentaire. Cela
conduit inévitablement à une grande diculté de compilation de ces informations et les études
sur celles-ci deviennent très compliquées. L'archivage des données n'étant pas forcément assuré,
avec le temps et les rotations de personnel, beaucoup de précieuses informations peuvent être
perdues. C'est pourquoi l'École d'ingénieurs de Lullier (EIL) recherche aujourd'hui un moyen
technique permettant d'unier et simplier au maximum les saisies d'observations faunistiques.
Dans ce but, elle souhaite que les gardes-faune puissent disposer d'un terminal mobile
leur permettant de recenser très précisément la position géographique de chacun des animaux
observés et ceci directement sur le terrain. Les gardes doivent avoir la possibilité de saisir une
position xe, ou le trajet eectué par le groupe d'animaux. Ils doivent de plus pouvoir indiquer
pour chacun des sexes ainsi que pour diérentes tranches d'âges, le nombre d'animaux observés
lors de la saisie. D'autres informations, telles que l'espèce, l'activité ou un commentaire sur
l'observation doivent aussi pouvoir être entrés dans le système. L'école de Lullier désire, de
plus, que les gardes-faune aient la possibilité d'eectuer un ltrage des données et consulter
celles-ci sur le terrain. Ils pourraient, par exemple, vouloir acher sur la carte uniquement les
renards observés du premier janvier 2007 au 15 septembre 2008.
Dans un premier temps, ce travail de diplôme est consacré à l'étude de diérentes tech-
nologies permettant de représenter des données géographiques sur un terminal mobile. Une
fois la technologie la plus appropriée sélectionnée, le développement d'un prototype non-nal,
mais permettant de répondre à toutes les interrogations techniques du cahier des charges doit
être développé. Une base de données uniée, sera créée pour permettre aux gardes-faune de
l'ensemble de la Suisse de publier leurs observations an d'en faire proter l'ensemble de leurs
collègues, les chercheurs et éventuellement le grand publique. Ces derniers doivent avoir la
possibilité de visualiser les observations sur une application pour ordinateur de bureau. Des
développements futurs pourront être réalisés, an de traiter les données et d'eectuer des
études sur celles-ci.
1
CHAPITRE 1. INTRODUCTION 2
1.2 Organisation du mémoire

Le chapitre 2 est dédié à la capture des besoins de l'application. Il permet de détailler
le cahier des charges en identiant les divers acteurs du programme ainsi que le rôle qui
leur est attribué. Il présente les diérentes entités du logiciel, et nalement les données
que celui-ci doit permettre de recenser.
Le chapitre 3 introduit rapidement la norme SVG ainsi que ses diverses variantes. Il
décrit ensuite la faisabilité d'une implémentation de FauneTracker, avec des données en
SVG, sur un PDA. Ceci à l'aide des langages Java et C#. Il considère la possibilité d'une
implémentation sur téléphone portable et fait nalement une synthèse des diérents
résultats obtenus.
Le chapitre 4 est consacré à la description succincte des diérents produits de la gamme
d'ESRI, an que le lecteur puisse mieux comprendre l'intérêt de chacun de ceux-ci dans
les chapitres ultérieurs.
Le chapitre 5 présente ArcPad et ArcPad Application Builder ainsi que leur fonc-
tionnement. Il contient notamment des exemples de chiers de conguration ainsi que
de scripts pour ces logiciels. Il explique nalement pourquoi ces logiciels n'ont pas été
retenus dans le cadre du projet.
Le chapitre 6 est dédié à la phase de préparation du développement pour travailler
à l'aide du SDK d'ArcGIS Mobile. Il détaille la conguration réseau et logicielle des
diérents clients et serveurs. Il présente également le schéma de base de données en
lien avec le cahier des charges, la structure de données retenue ainsi que les couches
sélectionnées pour la création d'une carte.
Les chapitres 7, 8 et 9 couvrent respectivement le développement de FauneTracker -
Conguration, FauneTracker - PDA et FauneTracker - Desktop. Après avoir introduits
le fonctionnement des logiciels, ces chapitres présentent les problématiques spéciques
rencontrées lors du développement de ceux-ci et comment elles ont été résolues. An
d'aider le lecteur à comprendre la manière dont l'implémentation a été réalisée, plusieurs
portions de codes ainsi que quelques-uns des motifs de conceptions (design patterns )
utilisés sont présentés.
Le chapitre 10 explique de quelle manière les chiers de déploiement ont été créés et
comment ceux-ci fonctionnent.
Enn, le chapitre 11 conclut ce mémoire en faisant une synthèse du travail réalisé.
Chapitre 2
Capture des besoins
2.1 Préambule
Il a été décidé d'intituler FauneTracker l'application qui permet de répondre à la pro-
blématique énoncée dans l'introduction de ce mémoire. Celle-ci est constituée de trois entités.
FauneTracker - PDA pour commencer, qui est l'application la plus importante du projet et
doit permettre aux gardes-faune d'eectuer des saisies d'observations faunistiques directement
sur le terrain. FauneTracker - Desktop donne quant à elle la possibilité de visualiser les obser-
vations eectuées et d'éditer celles-ci, sur un ordinateur de bureau. Finalement, FauneTracker
- Conguration sert à dénir les éléments qui peuvent être choisis par les gardes-faune lors des
saisies ainsi qu'à préparer les missions qu'ils devront eectuer.
Ce chapitre énonce les outils qui seront proposés par les diérents logiciels de l'application
de même que le rôle des diérents acteurs. Le diagramme des cas d'utilisations présenté sur la
gure 2.1, introduit de façon graphique les comportements de ces acteurs et les fonctionnalités
oertes par les diérents modules de l'application.
2.2 Identication des acteurs

2.2.1 Responsable
Cet acteur est chargé de dénir les missions des observateurs. Pour cela il a à sa disposition
le logiciel FauneTracker - Conguration qui permet de consulter, ajouter, supprimer et modier
simplement et ecacement des données sur les tables du serveur de base de données. Un
responsable peut, par exemple, ajouter une espèce, l'icône correspondante et saisir les divers
attributs liés à celle-ci.
À l'aide de ce logiciel, le responsable dénit la mission qu'il souhaite coner à ses gardes-
faune et sélectionne en fonction de celle-ci un sous-ensemble des classes, espèces et autres
informations de la base de données . Les observateurs n'auront donc à leur disposition que
les données qui leur seront strictement utiles pour leur mission, ce qui simpliera grandement
leur tâche de saisie. Le responsable déclenche nalement la génération d'un chier de mission,
à destination du logiciel de saisie embarqué sur les terminaux mobiles et constitué des données
choisies.
Lorsqu'il utilise FauneTracker - Desktop, le responsable a aussi la possibilité d'éditer les
données des saisies eectuées par les observateurs de son groupe.
3
CHAPITRE 2. CAPTURE DES BESOINS 4
Figure 2.1 Diagramme des cas d'utilisations de l'application.

Faune Tracker
FauneTracker – Configuration FauneTracker – Desktop
Charger/Générer
<<include>> Consulter les
fichier de mission <<include>>
observations
<<include>> Accès BDD <<include>>
Choisir les données

pour la mission
<<include>> Modification des
<<include>> observations
Interrogateur
Éditer les espèces,
Consulter
classes, etc.
carte/Naviguer
Responsable
Faune Tracker - PDA
Chargement <<include>>
Lire fichier de
Mission/Synchronisation configuration
<<include>>
«extends»
Saisir observation GPS
«extends»
Consulter
Observateur carte/Naviguer
2.2.2 Observateur
L'observateur dispose d'un PDA équipé de Faune Tracker - Saisie et de la carte liée à sa zone
d'activités. Il doit recenser les animaux dénit par la mission que lui fournit son responsable.
Il peut aussi, s'il le désire, récupérer et ltrer directement sur le terrain des informations sur
des observations précédemment eectuées.
À l'aide de FauneTracker - Desktop, l'observateur a la possibilité de visualiser les observa-
tions de tous ses collègues, ainsi que d'éditer ses propres saisies.
2.2.3 Interrogateur
L'interrogateur est une personne eectuant des recherches ou souhaitant seulement consul-
ter les données. Il a à sa disposition le logiciel FauneTracker - Desktop qui lui permet de
visualiser les observations et obtenir des informations sur celles-ci.
2.2.4 Combinaisons des rôles

Plusieurs rôles peuvent être conjugués par les acteurs. Un reponsable peut aussi être :
observateur ;
interrogateur.
Un observateur peut être :
interrogateur.
2.3 Entités de l'application

2.3.1 FauneTracker - PDA
Ce logiciel est le module central de l'application. Il permet aux gardes-faune d'eectuer des
saisies d'observations faunistiques et de synchroniser celles-ci avec une base de donnée centrale,
directement à partir d'un PDA. Cette synchronisation nécessite une connexion internet et est
eectuée à la demande des observateurs, puisque ceux-ci se trouvent principalement sur le
terrain, dans des milieux où ils ne disposent pas de connexions. Toutes les données ajoutées
entre deux synchronisations par l'observateur sont donc stockées dans un cache sur le terminal
mobile.
FauneTracker - PDA doit acher une carte à l'échelle 1/25000 sur laquelle le garde-faune
peut naviguer. Si celui-ci dispose d'un module GPS il a la possibilité de positionner la carte
en permanence, sur son emplacement GPS. Le logiciel, en plus de permettre d'eectuer des
saisies, autorise la consultation d'informations sur des observations eectuées antérieurement.
Il permet aussi d'eectuer des requêtes de ltrage, an de n'acher que les observations
répondant à certains critères sur la carte. En outre, an d'éviter tout conit quant à l'auteur
des saisies, l'application ne peut fonctionner qu'une fois que l'observateur s'est authentié avec
succès.
Un soin particulier doit être apporté lors de la conception de l'interface homme-machine
(IHM) de ce logiciel. Celle-ci doit, en eet, être la plus simple possible d'utilisation pour
minimiser les erreurs de saisie possibles et être fonctionnelle sur le terrain. Ses diérents menus
seront personnalisables dynamiquement via le chier de conguration fourni par FauneTracker
- Conguration, en fonction de la mission dénie par le responsable. Pour chaque saisie ou
requête, le garde-faune est guidé à travers des fenêtres se succédant et sur chacune desquelles
il peut entrer diverses informations.
2.3.2 FauneTracker - Conguration

Ce programme de conguration est destiné aux responsables de groupes. À l'aide de celui-ci
et après s'être authentiés, ils peuvent sélectionner les classes, espèces et autres informations
présentes dans la base de données, en fonction de la mission qu'ils souhaitent coner à leurs
gardes respectifs. Le programme se charge ensuite de générer un chier de mission au format
XML, comportant les données choisies. Il donne nalement la possibilité à l'utilisateur, de
recharger un ancien chier de mission.
En plus de permettre la création d'un chier de mission, ce programme sert à ajouter,
supprimer ou modier très simplement les éléments contenus dans la base de données, tels que
les classes, les activités, etc.
2.3.3 FauneTracker - Desktop

Cette application peut-être utilisée par tout un chacun dans le but de consulter la carte
ainsi que les diverses observations faunistiques eectuées. Si un observateur authentié comme
tel l'utilise, il a en plus la possibilité d'apporter des modications à ses propres saisies (déplacer
le point, changer l'espèce, etc.) dans le cas où il a commis une erreur ou s'il lui manquait un
paramètre. Le responsable peut quant à lui, éditer les données de n'importe lequel des membres
de son groupe d'observateurs.
2.4 Données à saisir

Selon le cahier des charges fourni par les mandants du projet, les données indispensables
suivantes doivent pouvoir être saisies lors d'une observation eectuée par un garde-faune :
coordonnées géographiques d'une observation d'un animal statique ;
coordonnées géographiques permettant d'illustrer le trajet du déplacement d'un animal,
sous la forme de lignes-brisées ;
nom de l'observateur ;
classe de l'espèce ;
espèce ;
eectif(s) par sexe(s) ;
eectif(s) par tranches d'age(s) (pontes-oeufs, juvénile, adulte) ;
saisie eectuée à l'aide d'un GPS ou non ;
activité (alimentation,repos,etc.) ;
Les informations suivantes pourront, éventuellement, être ajoutées par la suite :
type d'observation (capture,trace,etc.) ;
structure (talus,plaine,etc.) ;
environnement (site marécageux, zone forestières, etc.).
Chapitre 3
SVG et Java pour une plate-forme

mobile
3.1 Préambule
La première étape de ce travail de diplôme consiste à étudier SVG (Scalable Vector Gra-
phics ) ainsi que ses variantes SVG Tiny et SVG Basic, dans le but de déterminer la faisabilité
du projet en perspective d'une implémentation sur un PDA fonctionnant sous Windows Mo-
bile. Le SVG est très utilisé sur les téléphones portables ainsi que pour la cartographie. Il
permet de représenter des objets graphiques et accéder à ceux-ci programmatiquement, de
créer des animations, des ltres, des dégradés.
3.2 Normes
Figure 3.1 Diérences entre un format matriciel et vectoriel.
Format matriciel Format vectoriel
Agrandissement
10 X
Matrice de pixels Description de formes
SVG est un format de dessin vectoriel. Un tel format dénit des images par des objets
géométriques distincts caractérisés par leur forme, leur emplacement ainsi que divers attributs.
Par opposition, un format matriciel tel que le JPEG par exemple, dénit une image par une
matrice de pixel.
7
CHAPITRE 3. SVG ET JAVA POUR UNE PLATE-FORME MOBILE 8
Figure 3.2 Dessin SVG, correspondant au code du listing 3.1.
L'avantage d'un format vectoriel réside dans le fait qu'il permet de changer la taille d'une
image, pour une dimension quelconque sans pour autant obtenir un eet de pixellisation ou
escalier, contrairement à un format matriciel (voir la gure 3.1). En contrepartie, lors de
chaque visualisation du dessin, une nouvelle image doit être créée par l'ordinateur, ce qui est
coûteux en ressources.
Les spécications de ce format sont ouvertes et ont été édictées par le World Wide Web
Consortium (W3C). SVG décrit les objets vectoriels à travers un chier XML au sein duquel
1
ils sont organisés de façon hiérarchique.

<?xml v e r s i o n=" 1 . 0 "?>
<!DOCTYPE svg PUBLIC " −//W3C/ /DTD SVG 1 . 0 / /EN"
" h t t p : / /www . w3 . o r g /TR/ 2 0 0 1 /REC SVG − − 2 0 0 1 0 9 0 4 /DTD/ s v g 1 0 . d t d ">

<s v g x m l n s=" h t t p : / /www . w3 . o r g / 2 0 0 0 / s v g ">
5 <g i d=" g r o u p e _ c e r c l e s " s t y l e =" f i l l −o p a c i t y : 0 . 7 ; ">
<c i r c l e i d=" c e r c l e _ r o u g e " c x=" 6 . 5 cm" c y=" 2cm" r=" 1 0 0 " s t y l e =" f i l l : r e d ;
stroke : black ; stroke −w i d t h : 0 . 1 cm" t r a n s f o r m=" t r a n s l a t e ( 0 , 5 0 ) " />
<c i r c l e i d=" c e r c l e _ j a u n e " c x=" 6 . 5 cm" c y=" 2cm" r=" 1 0 0 " s t y l e =" f i l l : y e l l o w ;
stroke : black ; stroke −w i d t h : 0 . 1 cm" t r a n s f o r m=" t r a n s l a t e ( − 7 0 , 1 5 0 ) "/>

10 <c i r c l e i d=" c e r c l e _ b l e u " c x=" 6 . 5 cm" c y=" 2cm" r=" 1 0 0 " s t y l e =" f i l l : b l u e ;
stroke : black ; stroke −w i d t h : 0 . 1 cm" t r a n s f o r m=" t r a n s l a t e ( 7 0 , 1 5 0 ) " />
</g>
</ s v g >
Listing 3.1 Exemple de code source SVG.

Dans le cadre d'une utilisation nomade, deux prols mobiles ont été dénis par le W3C ;
SVG Basic et SVG Tiny. Ces deux prols consistent en un sous-ensemble de la norme SVG,
pour les périphériques bénéciant d'une puissance et mémoire limitée. SVG Tiny a été élaboré
pour les équipements disposant de très peu de ressources, comme les téléphones mobiles, alors
que SVG Basic a été créé pour les périphériques un peu plus puissants, par exemple les PDA.
1. http://www.w3.org
Figure 3.3 Empilement J2ME/J2SE.

J2SE J2ME Empilement
Librairies
supplémentaires
Librairies
Autres
J2SE Foundation MIDP Profil
CDC CLDC Configuration
Machine
JVM KVM
Virtuelle
3.3 Dénitions
3.3.1 Motivations
Avant d'aller plus loin dans ce chapitre, il existe plusieurs notions et concepts spéciques
aux applications Java mobiles qu'il est indispensable de comprendre. Celles-ci sont détaillées
dans la suite de cette section. Le schéma 3.3 présente une synthèse de l'ensemble de ces notions.
3.3.2 Java 2 Micro Edition (J2ME)

J2ME est une spécication contenant un sous-ensemble des éléments de Java Standard
Edition (JSE). Cette spécication a été conçue pour les applications devant s'exécuter sur des
terminaux mobiles, avec des ressources limitées. Elle est constituée d'un framework compre-
nant les éléments suivants :
une Kilobyte Virtual Machine (KVM) ou alors une Java Virtual Machine (JVM), per-
mettant l'exécution d'une application Java sur le périphérique ;
une conguration J2ME ;
un prol J2ME.
3.3.3 Conguration J2ME

Une conguration J2ME est une spécication qui dénit un ensemble de classes de bas-
niveau devant être implémentée sur les machines virtuelles l'utilisant. Elle spécie en outre
les performances et la mémoire minimale du périphérique qui l'utilise. La conguration per-
met d'avoir une base commune sur l'ensemble des périphériques qui l'implémente. Ainsi un
développement qui utilise uniquement les classes spéciées par une conguration donnée, doit
fonctionner sur n'importe quel terminal utilisant celle-ci.
3.3.4 Prol J2ME

Un prol J2ME est un ensemble de classes spéciques qui étendent la conguration d'un
appareil. Il peut par exemple s'agir d'un mécanisme d'entrées/sorties, d'une interface utili-
sateur, de la gestion des connexions, etc. Plusieurs prols peuvent être implémentés par un
même terminal.
Un prol permet de dénir deux API distinctes.
1. L'API de bas niveau, qui contient toutes les classes de bases, donne l'accès aux évène-
ments liés au clavier, à l'écran ou autre fonction de bas-niveau et favorise la portabilité
de l'application.
2. L'API de haut niveau, qui dénit l'interface utilisateur, la façon de saisir les données,
etc. Cette API sera réalisée en fonction des possibilités de saisie et achage du terminal
et n'est donc pas prévue pour être générique.
Le développeur devra, au nal, faire un compromis entre portabilité de son code et ergo-
nomie de son application an d'exploiter au maximum les capacités du périphérique cible.
3.3.5 Connected Device Conguration(CDC)

CDC est une conguration pour J2ME qui est conçue pour les terminaux possédant des
ressources limitées par rapport à un pc standard, tel que les PDA et s'exécute sur une JVM.
3.3.6 Connected Limited Device Conguration (CLDC)

CLDC est une conguration pour J2ME, à destination des ressources très limitées, comme
les téléphones mobiles ou les pagers.
3.3.7 Mobile Information Device Prole (MIDP)

MIDP est un prol pour CLDC implémenté par la plupart des téléphones mobiles récents.
Celui-ci dénit l'interface graphique, le cycle de vie de l'application, les diérentes connexions
ainsi que le stockage persistant.
Les applications créées avec MIDP sont appelées Midlets, elles héritent de la classe abstraite
javax.microedition.midlet.Midlet qui permet de communiquer avec le téléphone depuis
l'application. En outre, cette classe abstraite dénit des méthodes à implémenter pour gérer
le cycle de vie de l'application (création, pause, reprise, n). Elle permet aussi de dénir les
enchainements entre les diérents écrans (le ux du programme).
Figure 3.4 Exemple de ux pour un Midlet.
3.4 SVG sur PDA

3.4.1 Langage hôte
Le SVG permet un rendu graphique. Dans le cadre de notre projet, il est envisagé de
l'utiliser pour acher des cartes ainsi que diverses informations. Mais il faut impérativement un
langage hôte pour créer l'application elle-même. Ce langage doit comporter des bibliothèques
permettant d'acher et de modier du SVG correctement et doit fonctionner sur un PDA.
3.4.2 Java
Pour commencer, le langage de programmation Java a été étudié en vue de l'utiliser comme
langage hôte. Nous savons que sur un ordinateur fonctionnant avec un système d'exploitation
conventionnel comme Linux, Windows ou Mac OS, le Java permet de développer des applica-
tions achant des dessins en SVG et interagissant avec ceux-ci. Cela est réalisé à l'aide d'une
bibliothèque graphique telle que Batik. Le langage Java nécessite une machine virtuelle pour
exécuter du code, or aucune machine virtuelle Java n'est installée de base sur les Pocket PC.
La première démarche a donc été de chercher, installer et tester diérentes machines virtuelles
Java gratuites et bibliothèques SVG pour Java disponibles pour PDA.
Les paragraphes qui suivent décrivent les possibilités théoriques et les résultats obtenus
avec diérentes machines virtuelles Java. An de tester celles-ci, deux librairie permettant
d'acher et modier du SVG à partir d'une application Java ont été sélectionnées.
Batik SVG Toolkit , librairie gratuite développée par Apache et supportant la spéci-
2
cation complète du SVG, conçue originalement pour être utilisée sur une plate-forme
J2SE.
TinyLine alternative payante supportant la norme Tiny SVG et nécessitant une plate-
3
forme J2SE ou J2ME pour s'exécuter.

2. http://xmlgraphics.apache.org/batik/
3. http://www.tinyline.com
Mysaifu est une machine virtuelle permettant d'exécuter du code J2SE, sur Windows
4
Mobile 2003. Après installation de celle-ci, il s'avère que des programmes Java relativement
peu complexes s'exécutent correctement sur le PDA, avec toutefois une latence importante.
Cependant, il n'est pas possible d'acher du SVG avec cette machine virtuelle, aussi bien avec
la bibliothèque Batik que TinyLine.
CrEme est une autre machine virtuelle pour Windows Mobile, développée par NSIcom.
5
Celle-ci implémente la spécication J2ME. Le test de celle-ci a permis de montrer que l'exé-
cution de programmes Java simples se déroule correctement mais, ici aussi, avec une latence
élevée. L'achage de SVG avec la bibliothèque Batik ne fonctionne pas. En revanche il est
possible d'acher des dessins au format SVG dans un programme Java, à l'aide de la bi-
bliothèque TinyLine. Cependant l'achage n'est pas totalement exact (position des éléments
erronée) et il est impossible d'acher du texte en SVG.
SuperWaba s'est installé correctement sur le terminal de test, cependant il n'a pas
6
été possible avec cette machine virtuelle qui fonctionne sous Windows Mobile, d'exécuter un
programme Java quelconque correctement.
Si Mysaifu et CrEme ont permis d'exécuter des applications Java simples, il n'a malheureu-
sement pas été possible d'acher du SVG avec un rendu satisfaisant. De plus, les programmes
exécutés sur ces machines virtuelles, sourent de latences élevées dicilement acceptables pour
l'utilisateur nal.
3.4.3 C#
Le C# est un langage objet conçu par Microsoft et faisant partie de l'architecture .NET.
Les programmes créés à l'aide de ce langage s'exécutent sur une machine virtuelle, dont une
version gratuite existe pour Windows Mobile. la possibilité d'utiliser le C# comme langage
hôte a donc été étudiée.
Le développement d'application pour PDA depuis Microsoft Visual Studio est très convi-
vial, il a été possible de créer et tester très facilement de petites applications C# sur le PDA
à l'aide de la machine virtuelle fournie avec le .NET Compact Framework 2.0. Ces applica-
tions fonctionnent parfaitement et avec une latence tout à fait acceptable pour l'utilisateur.
Le .NET Compact Framework est en fait un sous-ensemble des classes disponibles sur le .NET
Framework qui est utilisé pour développer des applications à destination d'un environnement
Windows standard.
Aucune librairie SVG n'est fournie avec le framework .NET. Des bibliothèques de classes
ont toutefois été développées dans le but d'implémenter cette norme dans ce framework. Mal-
heureusement, il n'en existe aucune en version nale ou dont le développement est relativement
avancé. Il s'agit de versions bêta voir alpha pour lesquelles la conception a souvent été aban-
donnée (pas de mise-à-jour depuis des années). Ces versions n'implémentent pas correctement
et complètement les diérentes normes de SVG et ne sont pas utilisables dans le cadre de
notre projet.
4. http://www.nsicom.com
5. http://www2s.biglobe.ne.jp/~dat/java/project/jvm/index_en.html
6. http://www.superwaba.com.br
3.5 SVG sur téléphone mobile

La plupart des téléphones mobiles récents supportent une implémentation de la norme
Tiny SVG et disposent d'une machine virtuelle Java très simpliée. Les essais ont été eectués
sur un Sony Ericsson W910i, équipé de la Sony Ericson Java Platform dans sa version 8.
Le développement a, quant à lui, été réalisé à l'aide du Sony Ericsson SDK 2.5.0.2 for the
Java(TM) ME Platform.
La prise en main de la plate-forme Java pour le téléphone s'est montrée relativement
complexe. Après diverses expérimentations, il s'est avéré que le support de Tiny SVG est
prévu pour dessiner les menus ainsi que les "splash screens" ou autres, plutôt que pour une
implémentation comme moteur de rendu d'une application. De plus, le support de la norme
s'avère à nouveau hasardeux. Il existe par exemple des problèmes pour l'achage de texte.
3.6 Bilan
La première étape de ce travail de diplôme consistait en l'étude des possibilités d'implé-
mentations de SVG pour un PDA sous Windows Mobile. Ceci dans le but d'examiner la
faisabilité du projet, à l'aide de SVG.
Après l'examen des diérentes normes SVG, il est clair que c'est la norme SVG Basic qui
serait la mieux adaptée pour un PDA. Cependant, si plusieurs implémentations de SVG ou
SVG Tiny telles que lecteurs, bibliothèques et applications existent, les implémentations de
SVG Basic sont très rares que ce soit pour un ordinateur de bureau, un PDA ou un téléphone
mobile. Nous ne nous sommes donc pas limités à l'étude des solutions pour SVG Basic, mais
nous avons testé des solutions pour les diérentes normes.
L'analyse a malheureusement montré que pour un PDA et avec le langage Java ainsi que
les diérentes machines virtuelles gratuites pour Pocket PC, il n'est pas possible d'acher du
SVG conformément à la norme. Ces machines virtuelles ne sont de surcroit pas certiées par
SUN, l'éditeur de Java. Le support du Java n'est donc pas exact et plusieurs bugs et plantages
sont apparus lors de l'exécution de programmes Java. Il faut aussi souligner que les problèmes
de lenteurs des applications sont rédhibitoires. Finalement, le déploiement et l'exécution d'un
programme sur ces machines demande de nombreuses opérations et n'est pas forcément à la
portée d'un utilisateur lambda. Avec le langage C#, les bibliothèques ne sont pas au point et
ne permettent pas un achage correct de diérents éléments en SVG.
En ce qui concerne les téléphones mobiles, le support de la norme SVG s'est, à nouveau,
avéré incomplet. Il faut aussi noter que, bien que les téléphones portables aient l'avantage
d'être très répandus, ils ne sont pas l'équipement le plus approprié en termes d'interface
homme-machine pour une application comme la notre. En eet, les téléphones mobiles ne sont
en principe pas tactiles et possèdent un petit écran, par rapport à un PDA.
Pour les diérentes raisons évoquées dans cette conclusion, il n'est pas réaliste d'envisager
une implémentation de FauneTracker avec des cartes au format SVG, que l'application soit
développée avec le langage hôte C# ou Java et qu'elle soit à destination des PDA ou des
téléphones mobile.
Chapitre 4
Produits ESRI
4.1 Préambule
Environmental Systems Research Institute, Inc. (ESRI) est une société informatique ac-
1
tive dans le domaine des systèmes d'information géographique (SIG). Elle détient d'ailleurs la
plus grande part de marché en terme de vente de logiciels de SIG. C'est elle qui, en 1969, a
été la première à introduire ce concept dans le monde de l'informatique.
ESRI propose une gamme complète de produits permettant de gérer un SIG, du serveur de
cartographie à l'application mobile, en passant par le poste utilisateur et la création des cartes.
Puisque l'État de Genève, ainsi que la plupart des cantons suisses possèdent une licence pour
ces produits, la décision d'étudier la faisabilité du projet FauneTracker, en utilisant ceux-ci a
été prise.
Le schéma 4.1 représente la gamme de produits développés par ESRI. Celle-ci est très
large. An que le lecteur comprenne mieux le rôle des diérents produits d'ESRI dans les
chapitres ultérieurs, une brève description des applications présentant un intérêt pour notre
travail, reprenant les catégories du schéma est donnée dans les sections qui suivent.
4.2 Bureautique
Cette catégorie est principalement constituée d'ArcGIS Desktop, qui est le produit central
de la gamme. Celui-ci est notamment constitué des deux logiciels suivants :
1. ArcCatalog, dont l'interface ressemble beaucoup à l'explorateur de Windows et permet
de réaliser les opérations suivantes :
naviguer et trouver sur l'ordinateur ou sur des serveurs distants, des informations
géographiques ;
dénir, créer, exporter et importer des modèles de bases de données géographiques ;
créer, modier et visualiser les métadonnées des informations géographiques ;
administrer un serveur ArcGis.
2. ArcMap, qui implémente les fonctionnalités qui suivent :
créer, éditer, visualiser et imprimer les diérentes cartes et leurs couches respectives ;
dénir tout ce qui concerne l'apparence des cartes (symbologie, labels, couleurs, etc.) ;
interrogation et analyse des données, création de graphiques et de textes.
1. http://www.esri.com
14
CHAPITRE 4. PRODUITS ESRI 15
Figure 4.1 Gamme ArcGIS (source : ESRI).
4.3 Nomade
ArcPad permet de saisir, visualiser ou éditer des informations géographiques directement
sur le terrain, à l'aide de périphériques mobiles comme les PDA ou les tablettes PC. Ce
logiciel gère aussi les appareils photo numériques, certains récepteurs GPS ainsi que divers
autres équipements. Il est conçu pour les périphériques non-connectés. Il est donc nécessaire
de passer par un ordinateur xe disposant d'ArcGIS Desktop, an de synchroniser les données
du périphérique et du serveur. Une analyse plus détaillées de ce produit est réalisée au sein
du chapitre 5.
ArcPad Application Builder est une application qui permet de personnaliser ArcPad à
travers un outil de conguration ainsi que de scripts qui peuvent être écrits à l'aide des langages
VBScript ou JavaScript. Il permet aussi de d'éditer des formulaires ainsi que la manière dont
l'utilisateur pourra saisir des informations.
ArcGIS Mobile permet quant à lui de développer une application SIG légère pour des
périphériques nomades à l'aide d'un kit de développement logiciel (SDK) pour Microsoft .NET.
Ce SDK fournit des composants permettant notamment
d'acher une carte et de naviguer sur celle-ci ;
de mettre à jour le SIG ;
d'orir un support du GPS.
CHAPITRE 4. PRODUITS ESRI 16
ArcGIS Mobile possède de plus le grand avantage de pouvoir se synchroniser directement

avec un serveur, sans passer par un poste de travail intermédiaire. Il fonctionne en mode semi-
connecté, cela signie que lorsqu'une connexion entre le serveur et le périphérique est établie,
les données peuvent être mises à jour en temps-réél. Dans le cas contraire les données modiées
ou créées sont stockées dans le cache de l'application cliente, jusqu'à ce qu'une connexion
soit à nouveau établie avec le serveur pour synchroniser les données. ArcGIS Mobile est un
composant d'ArcGIS Server.
4.4 Serveur
ArcGIS Server permet de rendre facilement disponible à de multiples clients, des données
géographiques mises en forme avec ArcGIS Desktop. Avec ArcGIS Server, il est possible de
créer des applications web pour l'accès aux données et de faire de la modélisation avancée
pour l'analyse spatiale. Il permet aussi de gérer la réplication et la distribution des données
sur de multiples serveurs. ArcGIS Server possède une console d'administration web mais peut
aussi être administré par l'intermédiaire d'ArcCatalog.
ArcSDE, qui aujourd'hui est un composant à part entière du serveur, permet de stocker,
au sein de divers moteurs de bases de données, les informations géographiques du serveur
(Microsoft SQL Server, Oracle, IBM DB2, etc.).
Chapitre 5
ArcPad et ArcPad Application Builder
5.1 Description
ArcPad est un logiciel conçu pour fonctionner sur des dispositifs nomades à disposition
des agents de terrains, an de leur permettre de saisir et consulter des données sur des cartes
(cf. 4.3).
Ce logiciel fonctionne en mode non-connecté, cela signie que toutes les cartes que l'agent
de terrain consulte ainsi que toutes les données qu'il saisit sont stockées directement sur le
périphérique. La synchronisation s'eectue quand l'agent établit une connexion entre ArcPad
et ArcMap qui se trouvent respectivement sur le PDA et l'ordinateur de bureau de celui-ci.
C'est cet ordinateur qui se synchronisera ensuite avec le serveur via ArcCatalog pour mettre à
jour leurs données respectives, ceci est résumé sur le schéma 5.1. ArcPad Application Builder
permet quant à lui de créer une interface personnalisée pour le logiciel ArcPad.
Étant donné que la conjugaison de ces deux logiciels semble répondre aux exigences de
l'application FauneTracker, une analyse détaillée de ceux-ci est eectuée au sein de ce chapitre.
La version du programme utilisée, est la 7.1.1.
5.2 Fichier de conguration

ArcPad présente par défaut à l'utilisateur, un certain jeux d'outils et de composants. De
part sa nature générique, cette conguration n'est pas du tout adaptée à une application
spécique.
Figure 5.1 Synchronisation des données depuis ArcPad jusqu'au serveur.
ArcPad ArcMap ArcCatalog ArcGIS Server
Agent de terrain
17
CHAPITRE 5. ARCPAD ET ARCPAD APPLICATION BUILDER 18
Figure 5.2 Conguration par défaut d'ArcPad (gauche) et personnalisée (droite).
À l'aide d'ArcPad Application Builder, la possibilité de congurer en détails les diérents

outils qui seront proposés à l'utilisateur est fournie. L'utilisateur peut, en outre, créer de
nouveaux outils ainsi que des nouvelles fonctionnalités en développant des scripts.
L'image 5.2 montre sur le PDA de droite, un exemple de conguration personnalisée et

plus adaptée aux besoins de l'application. Les barres d'outils ont totalement été personnalisées.
Celles-ci contiennent notamment des boutons pour ajouter ou ltrer les animaux, pour centrer
la carte à partir des informations GPS et activer celui-ci ainsi que des commandes de zoom et
de déplacement. Certains de ces boutons, comme ceux qui permettent de se déplacer dans la
carte ou redimensionner celle-ci, sont des composants préprogrammés d'ArcPad Application
Builder qui peuvent être achés dans ArcPad si ceux-ci présentent une utilité. En revanche,
les composants tels que ceux qui permettent d'ajouter ou ltrer des données (observations),
sont des outils personnalisés dont le comportement est déni par des scripts rédigés par nos
soins.
Les chiers de conguration pour ArcPad, sont en fait de simples chiers XML qui portent
l'extension APX. Le chier de conguration qui est chargé lorsque ArcPad est lancé, doit être
placé dans le sous-répertoire System de ArcPad sur le terminal mobile. Le listing de la page
suivante (5.1), présente un exemple de chier de conguration.
<? xml v e r s i o n=" 1 . 0 " e n c o d i n g="UTF −8" ?>

<ArcPad d e b u g=" t r u e ">
<CONFIG>
<! -- Configuration de la barre d etat -->

5 <STATUSBAR v i s i b l e =" t r u e " s c a l e =" t r u e " r o c k e r m o d e=" f a l s e "
u n i t s=" t r u e " />
<! -- Configuration des formulaires -->

<FORMS/>
<! -- Configuration des barres d outils -->

10 <TOOLBARS>
<! -- Barre d outils personnalisee 1 -->

<TOOLBAR name=" t l b F a u n e C u s t T B " c a p t i o n=" O u t i l s "
v i s i b l e =" t r u e " >
<TOOLBUTTON command=" openmap " />
15 <TOOLBUTTON command=" modezoomin " />
<TOOLBUTTON command=" modezoomout " />
<TOOLBUTTON command=" modepan " />
<TOOLBUTTON command=" e x i t " />
<TOOLBUTTON command=" g p s e n a b l e " />
20 <! -- Dossier de bouttons -->

<TOOLBUTTON name=" t l C u s t o m F o l d e r " i m a g e=" G l o b e 1 . i c o ">
<MENUITEM name=" q u e r y " i m a g e=" $ b e x " o n c l i c k =" F i l t e r ( ) "
c a p t i o n=" q u e r y " />
<MENUITEM o n c l i c k =" R e m o v e F i l t e r s ( ) ; "
25 name=" r e m o v e F i l t e r s " i m a g e=" $ p i n 1 _ g r e e n "
c a p t i o n=" E n l e v e r F i l t r e s " />
<MENUITEM o n c l i c k =" O p e n A n d C o n f i g u r e F i l t e r F o r m ( ) "
name=" F i l t r e " i m a g e=" $ s a d " c a p t i o n=" F i l t r e " />
</TOOLBUTTON>
30 </TOOLBAR>
<! -- Barre d outils personnalisee 2 -->

<TOOLBAR name=" t l b F a u n e O u t i l s 2 " c a p t i o n=" " v i s i b l e =" t r u e " i m a g e=" ">
<TOOLBUTTON command=" g p s e n a b l e " />
<TOOLBUTTON command=" c e n t e r o n g p s " />
35 <TOOLBUTTON o n p o i n t e r u p=" AddAnimal ( ) " name=" AddAnimal "
s h o r t c u t=" " i m a g e=" A n i m a l 1 . i c o "
t o o l t i p =" A j o u t e r un animal "
prompt=" A j o u t e r un a n i m a l " />
<TOOLBUTTON name=" A d d F i l t e r " s h o r t c u t=" " i m a g e=" $ q u e s t i o n "
40 o n c l i c k =" O p e n F i l t e r F o r m ( ) "
t o o l t i p =" C o n f i g u r e r filtre "
prompt=" C o n f i g u r e r f i l t r e " />
<TOOLBUTTON name=" R m v F i l t r e " s h o r t c u t=" " i m a g e=" $ c o f f e e "
o n c l i c k =" R e m o v e F i l t e r s ( ) "
45 t o o l t i p =" E n l e v e r les filtres "
prompt=" E n l e v e r les f i l t r e s " />
<TOOLBUTTON command=" m o d e l a b e l " />
</TOOLBAR>
</TOOLBARS>
50 <SYSTEMOBJECTS>
<! -- Appel la fonction " LoadMap ( ) " au chargement de l application -->

<APPLICATION o n s t a r t u p="LoadMap ( ) " />
</SYSTEMOBJECTS>
</CONFIG>
55 <! -- Fichier contenant les scripts lies à la configuration -->

<SCRIPT s r c=" ArcPad . j s " l a n g u a g e=" J S c r i p t " />
</ ArcPad>
Listing 5.1 Exemple de chier de conguration.

Figure 5.3 Exemple de formulaire d'ajout, avec aide à la saisie et guidage étape par étape.
5.3 Fichier de données

5.3.1 Contenu
Un chier de données pour ArcPad porte l'extension AXF. Il s'agit en fait d'une base
de données relationnelle au format Microsoft SQL Server Compact Edition. Cette base de
données est constituées de plusieurs éléments :
Les tables de fonctions, qui rassemblent toutes les données sur la géométrie et les attri-
buts ainsi que les métadata. Cela correspond en fait aux informations contenues dans le
chier de formes (shapele ) SHP ainsi que les chiers liés à celui-ci (SHX, DBF et PRJ).
Les chiers de couches, qui permettent la représentation des tables du point précédent.
Ils contiennent la symbologie, les formulaires ainsi que le nom des couches.
Les tables ne possédant pas d'informations géographiques.
Les chiers externes, comme les chiers de script.
Les systèmes de coordonnées.
La plupart des données de ce chier sont crées depuis ArcMap, lors de l'export des données
pour ArcPad. Il existe cependant divers composants personnalisables sous ArcPad Application
Builder. Dans la suite de cette section, les principaux sont présentés.
5.3.2 Formulaires
Les diérents formulaires sont directement contenus dans le chier AXF. Ceux-ci sont créés
à l'aide d'ArcPad Application Builder qui permet de créer des formulaires personnalisés pour
la saisie, l'interrogation et la recherche de données.
5.3.3 Scripts
Toutes les actions personnalisées sont dénies par des scripts. Ceux-ci sont appelés lors
d'évènements précis tels que le chargement d'un formulaire, la pression sur un bouton, un
clique sur la carte, etc. Ils peuvent être écrits en JavaScript ou VB Script et utilisent le modèle
objet d'ArcPAD , qui est une bibliothèque de classes donnant accès à certaines fonctions et
1
outils du logiciel. Dans le cadre de ce travail, le choix de rédiger les scripts à l'aide du langage
JavaScript a été fait.
Voici un exemple simple : il faut créer un ltre an de pouvoir acher seulement les
animaux d'une certaine espèce et recensés par un observateur donné. Pour cela il faut créer
un formulaire ainsi que quelques fonctions, dans le but de remplir les listes déroulantes, réagir
aux évènements, rafraichir la carte, etc. Le code de la fonction permettant de récupérer les
données sélectionnées dans les listes déroulantes et qui créé le ltre correspondant est aché
ci-dessous.
/* * Permet de creer le filtre à appliquer sur la couche de recenssement .
*/
function CreateFilter () {
// Recuperation de la page du formulaire d ou vient l evènement .

5 var page = ThisEvent . Object . Pages ( 1 ) ;
// Recuperation des controles de listes deroulantes .

var ctrlEsp = page . C o n t r o l s ( cbFiltreEspeceName ) ;
var ctrlObs = page . C o n t r o l s ( c bF il tr eO bs er va te ur Na me ) ;
// Recuperation de la couche sur laquelle les animaux sont recensses .

10 var layer = L a y e r s . Item ( recenssementLayerName ) ;
// Initialisation du filtre .
var filter = "" ;
// Creation du filtre selon les donnees du formulaire .

15 if ( c t r l E s p . Enabled ) {
filter += " [ E s p e c e ]= "+c t r l E s p . V a l u e+" ";
if ( c t r l O b s . Enabled ) {
if ( filter != "" )
20 filter += " AND " ;
filter += " [ O b s e r v a t e u r ]= "+c t r l O b s . V a l u e+" ";
// Affectation du filtre , au filtre de la couche .

layer . Filter = filter ;
25
// Mise à jour du cache et reaffichage de la couche .
layer . visible = false ;
layer . visible = true ;
Listing 5.2 Création et exécution du ltre sur les animaux.
1. http://www.esri.com/library/fliers/pdfs/arcpad-objectmodel.pdf
5.4 Bilan
ArcPad est un logiciel performant et, pour autant que l'utilisateur prenne le temps de
se plonger dans son modèle objet et ses divers aspects techniques, relativement aisément
personnalisable. Grâce à la réalisation d'un prototype, il a été démontré que du point de vue
technique, il est possible de réaliser l'application FauneTracker avec celui-ci.
Il faut toutefois noter certains aspects peu concluants. Comme précédemment évoqué,
une application créée avec ArcPad, n'est pas une application à part entière, mais plutôt une
personnalisation d'ArcPad pour l'implémentation souhaitée. Si cela permet de créer des ap-
plications avec une certaine rapidité, cela entraine malheureusement en contrepartie de fortes
limitations dans la possibilité de création d'une interface répondant de façon optimale à des
besoins spéciques.
En ce qui concerne le projet FauneTracker, il n'est pas possible de créer une interface
homme-machine possédant la simplicité requise par le cahier des charges. De plus, il faut noter
que la synchronisation des données entre le PDA et le serveur est relativement complexe. Il
faut en eet eectuer une succession d'opérations qui ne laisse pas de place à une erreur
de l'utilisateur. En outre, cette synchronisation nécessite un ordinateur de bureau possédant
une certaine conguration (voir schéma 5.1). La synchronisation des données n'est donc pas
ouverte à un utilisateur lambda.
Chapitre 6
Préparation de l'implémentation
6.1 Préambule
Après une phase conséquente d'étude, il a été décidé d'implémenter le projet FauneTracker
à l'aide des diérents produits de la société ESRI et plus particulièrement à l'aide du SDK
d'ArcGIS Mobile, fourni avec la version 9.3 du serveur. Après divers tests, celui-ci semble en
eet être capable de répondre de la façon la plus optimale, au cahier des charges. Dans ce
chapitre, tout ce qui concerne la préparation du développement sera analysé. La description
de l'environnement de développement et de tests mis en place sera nalement donnée, avant
d'étudier la structure de données choisie ainsi que les diérentes couches sélectionnées pour
créer la carte.
6.2 Environnement de développement et de tests

6.2.1 Conguration réseau
La première étape pour la préparation du développement est une phase d'installation et
conguration d'un réseau, de diérents serveurs ainsi que des produits ESRI. Ceci an de
posséder un environnement de développement et de tests permettant de simuler un environ-
nement réel. Cette phase d'installation et de conguration a pris un temps non négligeable.
Toutefois, comme cette phase n'est pas le sujet de ce travail, il a volontairement été choisi de
pas parler de celle-ci au sein de ce mémoire.
Les éléments réseau suivants sont nécessaires pour implémenter le système de GIS :
serveur ArcGIS Server ;
serveur web pour l'administration d'ArcGIS Server ;
serveur de base de données ;
poste de développement ;
station de test ;
périphérique Windows Mobile de test.
En raison des ressources disponibles, l'implémentation physique d'ArcGIS Server, du ser-
veur web et du serveur de base de données a été eectuée sur la même machine physique. Une
installation distribuée n'aurait toutefois pas demandé d'étapes de conguration supplémen-
taires. Le réseau mis en place est représenté sur la gure 6.1.
23
CHAPITRE 6. PRÉPARATION DE L'IMPLÉMENTATION 24
Figure 6.1 Réseau mis en place.

Serveur ArcGIS Serveur SQL Express Serveur WEB
Internet
Station de tests PDA de tests
Station de développement
6.2.2 Conguration logicielle

ArcSDE permet d'utiliser plusieurs types de serveurs de base de données pour stocker
les informations utilisées par le serveur de GIS. En raison de sa gratuité, de sa simplicité
d'utilisation sur Windows et de son intégration à Visual Studio le choix d'utiliser SQL Server
Express a été fait. Pour les mêmes raisons de gratuité et de compatibilité avec Windows, le
serveur web Microsoft IIS a été installé.
Les logiciels indispensables suivants ont été installés et congurés sur le serveur :
Windows XP professionel, service pack 2 ;
Microsoft IIS version 5.1 (serveur web) ;
SQL Server Express 9.0.3042 ;
ArcGIS Server 9.3 ;
ArcSDE 9.3.
La conguration du poste de développement est la suivante :
Windows XP professionel, service pack 2 ;
Microsoft Visual Studio 2008 ;
.NET Framework v3.5 ;
.NET Compact Framework v2.0 et v3.5 ;
Windows Mobile 6 Professional SDK ;
Windows Mobile 5 Pocket PC SDK ;
ArcGIS Mobile SDK 9.3.
Finalement, l'essentiel des tests sur terminal mobile, ont été eectués sur un PDA HP
iPAQ 210E Handheld possédant la conguration suivante :
Windows Mobile 6 ;
ArcGIS Runtime 9.3 ;
module GPS bluetooth Kirrio BT-308.
Figure 6.2 Schéma UML théorique de la base de données.

1 n n 1 n 1
Utilisateurs Observations Espèces Classes
OBJECTID OBJECTID OBJECTID OBJECTID
+Nom +Saisie_Gps +Nom_Fr +Nom
+Prénom +Date_Observation +Nom_Latin +Description
+MD5_Pwd +Date_Saisie n +Image +Image
+User_Name +Commentaires
+Responsable +SHAPE
n n n
1 Tranches_Ages
1
Groupes OBJECTID
Activites +Nom
OBJECTID OBJECTID
Effectifs
+Nom +Nom +Sexe
+Nombre
6.3 Structures de données

6.3.1 Schéma de base de données
La gure 6.2, décrit le schéma de la base de données originalement conçu. Pour commencer,
la table Observations, qui est la table centrale de ce schéma a été créée. Cette table doit
être conçue à l'aide d'ArcCatalog, an que le serveur de GIS la reconnaisse comme une table
contenant des données géographiques et possédant un certain système de coordonnées. Cette
table pourra ainsi être achée comme une couche d'une carte et chacun des enregistrements
de celle-ci contiendra une forme pour cette couche.
La table Observations contient non seulement la référence vers la forme correspondant à
l'observation, mais aussi plusieurs informations. Celle-ci dénit principalement des attributs de
référence vers le nom de l'espèce, de l'observateur, des eectifs et de l'activité de l'animal. Elle
contient en outre, la date de saisie de l'observation, qui correspond au moment ou l'utilisateur
entre l'information dans le système, la date d'observation qui indique le jour ou l'utilisateur
a fait l'observation (la saisie peut être eectuée à postériori) et nalement une valeur pour
savoir si la saisie a été eectuée à partie d'une coordonnée fournie par un module GPS ou non.
La table Utilisateurs contiendra le nom et le prénom de ceux-ci, le condensé de leurs
mots de passes (voir 8.5), une valeur indiquant si ceux-ci font partie des responsables de
leur groupe d'observateurs respectifs ainsi que la référence vers ce groupe. Groupes contient
simplement le nom des diérents groupes d'observateurs.
Dans la table Especes, les noms français et latins des diérentes espèces, ainsi que la
référence vers la classe d'espèces qui les représente sont stockés. Les diérentes classes sont
enregistrées dans la table éponyme. La table croisée Effectifs permet quant à elle, pour
une observation donnée, de déterminer combien de mâles, femelles et indéterminés de chacune
des tranches d'âges stockées dans la table Tranches_Ages ont été aperçus. Comme la liste des
diérents genres est close, celle-ci est stockée dans un domaine. Finalement, la table Activités
dénit les diverses valeurs qui peuvent être choisies pour le champ correspondant.
Figure 6.3 Schéma UML de la base de données créée.

1 n n 1 n 1
Utilisateurs Observations Espèces Classes
OBJECTID OBJECTID OBJECTID OBJECTID
+Nom +Saisie_Gps +Nom_Fr +Nom
+Prénom +Date_Observation +Nom_Latin +Description
+MD5_Pwd +Date_Saisie +Image +Image
+User_Name +Commentaires
+Responsable +NbIndetAdultes
n +NbIndetJuveniles n 1
1 +NbIndetPontes Activites
+NbFemellesAdultes
Groupes +NbFemellesJuveniles OBJECTID
+NbMalesAdultes +Nom
OBJECTID +NbMalesJuveniles
+Nom +SHAPE
6.3.2 Schéma pour implémentation sur le PDA

Après une étude détaillée du SDK d'ArcGIS Mobile, il a été découvert qu'il n'était pas
possible d'eectuer des requêtes de jointures sur les bases de données utilisées par celui-ci.
Une solution a donc dû être trouvée pour pallier à ce manque.
Il a été décidé pour notre projet, de stocker au sein d'une unique table toutes les informa-
tions sur les observations. Dès lors, il fallait trouver une solution pour minimiser la redondance
des données ainsi que d'éviter de copier l'ensemble des champs de toutes les tables du schéma
de base de données originalement conçu, dans cette unique table.
En conséquence, le choix de garder la structure initiale de la table et de simplement lui
adjoindre les champs provenant de la mise-à-plat de la table croisée Effectifs a été fait.
Toutes les combinaisons de tranches d'âges et de sexes possibles ont ainsi été ajoutées à la
table Observations, sous la forme de nouveaux champs. Il en résulte, par exemple, un champ
Nb_Males_Juveniles qui contient, comme son nom l'indique, l'eectif des mâles juvéniles.
Ces modications sont visibles sur le schéma 6.3.
Pour tous les champs possédant une référence à destination d'une autre table, la jointure
sur le PDA sera implémentée manuellement et extraira ses informations d'un chier XML
généré à l'aide du programme FauneTracker - Conguration, qui possède un accès direct au
serveur de base de données.
6.3.3 Pictogrammes
Pour faciliter l'interface du programme et le rendre plus ludique, des pictogrammes per-
mettant à l'utilisateur d'identier les diérentes classes, espèces et activités lui sont présentés.
Pour gérer et stocker ces images, deux possibilités ont été envisagées : créer un champ dans
chacune des tables correspondantes, contenant l'adresse sur un serveur de chier de l'image
ou alors stocker directement l'image dans la base de données.
Chacune des méthodes possède des avantages. Il a cependant été choisi de stocker l'image
directement dans la base de données car cela permet de s'aranchir des risques liés à l'uti-
lisation d'un serveur de chier annexe. En eet, les images ne risquent pas d'être déplacées,
renommées ou supprimées. De plus, la gestion des droits s'eectue ainsi, via les droits d'accès
à la base de données et ne demande pas une nouvelle étape de conguration de gestion. Il faut
nalement noter que les images à stocker sont de faible taille (de l'ordre quelques kilo-octets),
de ce fait celles-ci ne risquent pas de surcharger la base de données. En contrepartie le procédé
pour extraire et enregistrer des images dans la base de données est un peu plus compliqué,
car celles-ci doivent être stockées sous forme d'un tableau d'octets.
6.3.4 Carte
La carte utilisée par notre application a été créée à l'aide du logiciel ArcMap qui fait partie
d'ArcGIS Desktop. Celle-ci est composée de trois couches de données géographiques :
1. la couche de fond, qui est une couche au format matricielle extraite des cartes topogra-
phiques à l'échelle 1/25000 de la Suisse ;
2. une couche vectorielle contenant des points, pour saisir les observations statiques ;
3. une couche vectorielle permettant de dessiner des lignes-brisées, pour les observations
de déplacements.
Les deux couches vectorielles contiennent en plus des données géographiques, les attributs
dénit par le schéma vu au point 6.3.2. Toutes ces couches sont stockées dans une base de
données géographiques administrée à l'aide d'ArcCatalog et se trouvant physiquement sur le
serveur SQL Express. Une partie de la carte créée est représentée sur la gure 6.4. Un service
sur le serveur ArcGIS a nalement été créé, an de rendre accessible les données de cette carte,
via internet.
Figure 6.4 Carte créée pour l'application.
Observation du trajet
d’un animal (couche n°3)
Observation statique
d’un animal (couche n°2)
Carte de la Suisse au
1/25000 (couche n°1)
Chapitre 7
FauneTracker - Conguration
7.1 Description
Cette application est destinée aux responsables des groupes de gardes-faune. Elle met à la
disposition de ces responsables, principalement deux fonctionnalités :
1. éditer les données présentes sur le serveur de base de données ;
2. dénir une mission pour les gardes-faune et générer automatiquement le chier de mission
correspondant.
L'interface de cette application doit impérativement être très simple, an qu'elle soit ou-
verte à un utilisateur lambda. Cela permettra d'éviter tout risque d'erreur de sa part. Diverses
fonctions supplémentaires, telles que le chargement d'un chier de mission précédemment créé
seront fournies à l'utilisateur.
Figure 7.1 Interface graphique de FauneTracker - Conguration.
28
CHAPITRE 7. FAUNETRACKER - CONFIGURATION 29
7.2 Fichier de mission

7.2.1 Rôles
Le chier de mission joue un rôle primordial dans le projet global. Il permet aux respon-
sables de dénir les critères à observer par leurs gardes-faune. Les responsables pourront ainsi
choisir les diérentes classes, espèces et activités qui seront présentées aux gardes-faune sur
le PDA lorsque ceux-ci seront sur le terrain. De plus, lorsqu'il est chargé sur le périphérique
mobile, ce chier permet de se substituer à une base de données pour l'application FauneTra-
cker - PDA, celle-ci ne pouvant avoir un accès direct et constant au serveur de données. Il
va aussi permettre de résoudre le fait que la jointure de tables n'est pas implémentée avec le
SDK d'ArcGIS Mobile. En eet, celle-ci sera implémentée par nos soins et les données seront
récupérées à partir du chier de mission. Finalement ce chier fournira divers paramètres de
conguration à l'application.
7.2.2 Format
<?xml v e r s i o n=" 1 . 0 " e n c o d i n g=" u t f −8" s t a n d a l o n e=" y e s "?>
<A p p l i c a t i o n >
<s e r v i c e _ u r l >
http : // 129.194.185.232/ arcgis10 / services / MapObs / MapServer / MobileServer

5 </ s e r v i c e _ u r l >




10 
<menus>
<menu name=" c l a s s e s " form_name=" C l a s s e d ' espèces " t y p e=" l i s t e _ i m a g e _ t x t ">
<menuitem i d=" 4 " img=" I m a g e s \ 0 . j p g ">A u t r e s </menuitem>
<menuitem i d=" 1 " img=" I m a g e s \ 1 . j p g ">Mammifères </menuitem>
15 <menuitem i d=" 2 " img=" I m a g e s \ 2 . j p g ">O i s e a u x </menuitem>
</menu>
<menu name=" e s p e c e s " form_name=" E s p è c e s " t y p e=" l i s t e _ i m a g e _ t x t ">
<menuitem i d=" 5 " img=" I m a g e s \ 4 . j p g " c l a s s e =" 2 ">A i g l e </menuitem>
<menuitem i d=" 1 9 " img=" I m a g e s \ 7 . j p g " c l a s s e =" 1 ">Chamois </menuitem>
20 <menuitem i d=" 1 " img=" I m a g e s \ 8 . j p g " c l a s s e =" 1 ">C h e v r e u i l </menuitem>
<menuitem i d=" 7 " img=" I m a g e s \ 9 . j p g " c l a s s e =" 2 ">Faucon </menuitem>
<menuitem i d=" 8 " img=" I m a g e s \ 1 0 . j p g " c l a s s e =" 4 ">Mouche</menuitem>s
</menu>
<menu name=" a c t i v i t e s " form_name=" A c t i v i t é s " t y p e=" l i s t e _ i m a g e _ t x t ">
25 <menuitem i d=" 7 " img=" I m a g e s \ 1 2 . j p g ">Combat</menuitem>
<menuitem i d=" 6 " img=" I m a g e s \ 1 3 . j p g ">S e d é p l a c e </menuitem>
<menuitem i d=" 5 " img=" I m a g e s \ 1 4 . j p g ">D o r t </menuitem>
</menu>
<menu name=" e f f e c t i f s " form_name=" E f f e c t i f s " t y p e=" S a i s i e E f f e c t i f s " />
30 <menu name=" d a t e _ o b s e r v a t i o n " form_name=" D a t e de l ' observation " t y p e=" S a i s i e D a t e "
/>
<menu name=" c o m m e n t a i r e s " form_name=" C o m m e n t a i r e " t y p e=" C o m m e n t a i r e " />
</menus>
</ A p p l i c a t i o n >
Listing 7.1 Exemple de chier de mission.

Le chier est organisé selon le standard XML. Un premier élément service_url permet
de dénir l'adresse du service de carte et du serveur ArcGIS le contenant. Vient ensuite une
section contenant les identiants, les logins ainsi que les condensés des mots de passes des
diérents utilisateurs faisant partie du groupe du responsable générant le chier.
Un élément menu est ensuite créé dans le chier de mission, pour chacun des formulaires de
saisie qui seront présentés à l'utilisateur dans l'application pour PDA. Cet élément est constitué
d'attributs dénissant le type du menu, le texte devant s'acher sur l'écran de l'utilisateur
et nalement un nom constituant un identiant unique pour le menu. Ces diérents menus
contiennent éventuellement des menuitems qui sont les éléments tels que les classes, espèces
et activités choisis par le responsable dans FauneTracker - Conguration et qui seront achés
au sein du formulaire. Pour chacun de ces éléments de formulaires plusieurs attributs en plus
du texte les dénissant sont fournis :
le dossier ainsi que le nom de chier de l'icône permettant de le représenter ;
un identiant unique au sein du menu courant ;
pour chacune des espèces, une référence permettant d'identier la classe dont elle fait
partie.
7.2.3 Génération
Les diérentes données contenues dans le chier de mission sont extraites à partir de la
base de données, selon les choix du responsable dans le programme de conguration. Lorsque
le responsable a ni de dénir sa mission, il clique sur le menu permettant de générer le chier
de mission et FauneTracker - Conguration s'occupe d'accéder aux éléments de la base de
données et de générer le chier XML à partir de ceux-ci. En parallèle, le programme crée un
répertoire, dans lequel tous les pictogrammes des éléments choisis sont ajoutés.
7.3 Authentication
Comme l'utilisation de ce logiciel est réservée aux responsables de gardes-faune, ceux-ci
doivent s'identier pour pouvoir l'utiliser. L'authentication utilise le même principe que celui
qui sera vu en détails pour FauneTracker - PDA au point 8.5, aux diérences près que l'on
doit en plus s'assurer que l'utilisateur est un responsable et que les données sont consultées
directement sur le serveur de base de données et non-plus à partir d'un chier de mission.
7.4 Accès base de données

Pour comprendre la manière dont les multiples accès à la base de données sont eectués,
un exemple simple mais présentant le mécanisme adopté pour chacune des requêtes dans ce
programme a été choisi pour être détaillé dans les paragraphes qui suivent. Celui-ci permet
de supprimer un enregistrement de la table Activites. Voici son code.
public void delete ( int id )
// Requête SQL paramètrée

string delete = "DELETE FROM Activites WHERE O b j e c t i d=@paramid ; " ;
5 // Création d ' une transaction

using ( TransactionScope scope
= new TransactionScope ( TransactionScopeOption . Required ) )
try
10 {
// Récupération de la connexion à la BDD

using ( SqlConnection sqlCon = BDDUtils . g e t C o n n e c t i o n ( ) )
// Création d ' une commande pour la requête

15 // " delete " , sur la connexion " sqlCon "

SqlCommand cmd = new SqlCommand ( d e l e t e , sqlCon ) ;
// Ajout du paramètre à la commande

cmd . P a r a m e t e r s . Add ( new S q l P a r a m e t e r ( " paramid " , id ) ) ;
// Ouvre la connexion
20 s q l C o n . Open ( ) ;
// Exécute la commande et vérifie

// qu 'un enregistrement a été supprimé
if ( cmd . E x e c u t e N o n Q u e r y ( ) == 0)
25 Dialogs . showErrorDialog (
" Erreur lors de la suppression , "
+ " aucun enregistrement affecté . ") ;
// Validation de la transaction
30 s c o p e . Complete ( ) ;
// Fermeture " standard " de la connexion

sqlCon . Close ( ) ;
35 // En cas d ' exception SQL

catch ( SqlException sqle )
throw new A p p l i c a t i o n E x c e p t i o n ( " Problème SQL . " + s q l e . Message ) ;
40 }
Listing 7.2 Exemple d'accès à la base de données.

Tout d'abord le texte de la requête est créé. Pour ne pas avoir à se préoccuper de la
syntaxe des valeurs de la requête, une requête paramétrée est utilisée. Plutôt que d'insérer
directement la valeur du paramètre avec la syntaxe appropriée dans la requête, un identica-
teur de paramètre précédé d'un @ est donné. Ce paramètre est ensuite déni via l'instruction
cmd.Parameters.Add(new SqlParameter("paramid", id)), qui insère automatiquement la
valeur de la variable id avec la syntaxe SQL adéquate, à la place du paramètre @paramid dans
la commande.
An de s'assurer que la commande ne corrompe pas l'état de la base de données en cas de
problème, une transaction est créée. Si une exception se produit lors de l'exécution du code
ou de la requête, l'instruction scope.Complete() qui valide les modications apportées à la
base de données ne sera pas atteinte, et aucun changement ne sera apporté à celle-ci. La base
de données restera donc dans son état initial.
Il est ensuite nécessaire de récupérer une connexion à la base de données. Pour cela nous
avons créé la méthode getConnection() qui est stockée dans la classe statique BDDUtils.
Comme son nom l'indique, cette classe ore divers outils en rapport avec la base de don-
nées à l'utilisateur. La connexion est récupérée au sein de la clause using qui dénit un espace
de visibilité dans lequel l'objet connexion sera utilisable. Cette clause s'assure que dès la sor-
tie de la zone qu'elle délimite, que la sortie soit normale ou provoqué par une exception, la
méthode dispose() de l'objet dénit par la clause soit appelée. Dans le cas d'une instance de
la classe SqlConnection, la méthode dispose() contient entre autres l'instruction permettant
de clore la connexion. La connexion est ouverte à l'aide de l'instruction sqlCon.Open() et
cmd.ExecuteNonQuery() permet d'exécuter la commande SQL, puis de retourner le nombre
d'enregistrements aectés par celle-ci.
Grâce à la transaction et l'utilisation de la clause using, nous avons la garantie que la

connexion est fermée proprement et que la base de données reste dans un état stable et ce,
quel que soit le comportement du programme. C'est pourquoi la même structure a été adoptée
pour toutes les requêtes vers la base de données créées dans cette application.
public static SqlConnection getConnection ()
// Retourne la connexion . La phrase de connexion est lue à partir d 'un

// fichier de configuration compilé avec le programme .
5 return new SqlConnection ( P r o p e r t i e s . S e t t i n g s . Default . sde10ConnectionString ) ;
Listing 7.3 Création d'un objet connexion.
7.5 Organisation des composants graphiques
Figure 7.2 Décomposition graphique des composants du GUI.

FrmMain
FauneTracker - Configuration
Classes Espèces Activités APanel
ADetailsItem
Détails
7.5.1 Organisation hiérarchique

Le formulaire principal, contient un gestionnaire d'onglet. Chacun de ces onglets contient
un membre dérivant la classe abstraite APanel. Celle-ci est elle même constituée d'une liste
d'éléments, de divers boutons et d'un composant abstrait - ADetailItem - permettant de
visionner les diérents attributs de l'élément sélectionné dans la liste. Chacun des panneaux
dérivant la classe APanel est chargé d'instancier une classe concrète dérivant ADetailItem. Le
schéma 7.2 représente graphiquement la séparation des composants du GUI. Le diagramme
représenté sur la gure 7.3, présente quant à lui, la manière dont ont été organisées les classes.
Figure 7.3 Composants du GUI, structure de classes.
7.5.2 Motif de conception template method

Les diérents panels permettant d'acher des données provenant du serveur SQL, comme
les classes, les espèces et les activités, sont tous très similaires. Ils possèdent en eet pra-
tiquement les mêmes composants graphiques, ainsi que plusieurs comportements communs.
Toutefois, selon le panel, lorsque l'on clique sur le bouton modier par exemple, le compor-
tement n'est pas le même. Pour une édition de classes, celui-ci ouvre en eet un dialogue
permettant de modier et accéder aux données de la classe (ID, Nom, Image, Détails) alors
que pour une espèce il faut prévoir une fenêtre autorisant l'édition des champs (ID, Nom_Fr,
Nom_Latin, ID_Classe et Image) de l'espèce.
Une première solution consiste à implémenter deux classes concrètes distinctes, sans une
classe parente commune. Cela présente cependant l'inconvénient majeur de créer du code en
forte partie identique, et non-factorisé pour les comportements communs.
C'est pourquoi il a été décidé d'utiliser le design pattern template method. Tout d'abord
une classe abstraite APanel a été introduite an de factoriser les méthodes communes. À l'aide
de ce pattern, nous allons cependant plus loin. Celui-ci permet, en eet, de factoriser du code
commun, au sein des méthodes elles-mêmes.
Voyons un exemple très simple. Pour la méthode permettant d'ajouter un enregistrement
et d'ouvrir la boite de dialogue permettant de saisir les informations de celui-ci il aurait pu
être écrit pour la classe dénissant le panel de gestion des classes d'animaux :
private void btAdd_Click ( o b j e c t sender , EventArgs e)
DetailsDialog detailsDialog = new C l a s s e s D e t a i l s D i a l o g ( dataAccess ) ;
showDetailsDialog ( detailsDialog ) ;
5 }
Et dans la classe gérant le pannel des espèces :

DetailsDialog detailsDialog = new EspecesDetailsDialog ( dataAccess ) ;
5 }
Figure 7.4 Implémentation du design pattern Template Method.
On peut constater que le comportement des deux méthodes est quasiment identique, la
seule diérence réside dans le choix du type concret du dialogue à créer. Pour simplier ce
comportement une classe abstraite possédant les instructions suivantes peut être introduite :
// Méthode abstraite dont l ' implémentation est laissée aux sous - classes
protected abstract DetailsDialog getDetailsDialogNewItem () ;
5 {
DetailsDialog detailsDialog = getDetailsDialogNewItem () ;
La méthode abstraite getDetailsDialogNewItem(), dont l'implémentation est sous la res-

ponsabilité des sous-classes de APanel, a aussi été introduite.
Selon le design pattern template method, la méthode btAdd_Click est une méthode patron.
Une méthode patron dénit une partie commune d'un algorithme et une partie spécique. Il
faut relever que, an de ne pas compliquer la tâche du lecteur, le cas démontré ici est très
simple. Le motif de conception a cependant été utilisé pour des méthodes plus complexes. Ce
pattern a aussi été utilisé pour le composant graphique permettant d'acher les détails d'une
classe ou espèce (ADetailsItem). Le diagramme 7.4 montre l'organisation des classes, dans le
cadre de ce travail, pour implémenter ce motif de conception.
dataAccess
IDataAccess
Interface Abstract Class
UserControl XMLReader
Abstract Class Abstract Class Class
Méthodes UserControl Form
Champs
CHAPITRE 7.
dataAccess Champs
btImage
Champs Champs
editMode dataXML
btAdd aDetailsItem btAnnuler
lblID Méthodes
btModify btRecord
pbImage getTable
btRemove components
readOnly XMLReader
checkedList Méthodes
aDetails Propriétés
menuName configureDetailsIt…
DataAccessComponent
Propriétés DetailsDialog
FrmMain EditMode
Class
CheckedItems DetailsDialog_For…
Form Méthodes
APanel Méthodes
Champs btAdd_Click
ADetailsItem
exitProgram btModify_Click
panels btImage_Click
LoadConfiguration btRemove_Click
loginResponsable checkedList_SelectedIndexChanged
mainMenu checkItems
SaveConfiguration configureDetailsItem ActivitesDetailsDialog EspecesDetailsDialog
tpActivites Class Class
tpClasses DetailsDialog DetailsDialog
tpEspeces refreshListBoxItems
Méthodes
createPanels
exitProgram_Click
FrmMain
ClasseDetails EspDetails XmlGenerator
LoadConfiguration_Click
Class Class Class
SaveConfiguration_Click CPanelClasses CPanelEspeces ADetailsItem ADetailsItem
FAUNETRACKER - CONFIGURATION
Class Class
APanel APanel
Champs
Champs Champs
idx
ImageParsing txtDetails cbClasses
Static Class Méthodes Méthodes images_directory
txtNom classesDico service_url
CPanelClasses CPanelEspeces
Propriétés txtNomFr
Méthodes getDetailsDialogModifyItem getDetailsDialogModifyItem Méthodes
ReadOnly txtNomLatin
getBitmapBytes getDetailsDialogNewItem getDetailsDialogNewItem createImagesFolder
TextID Propriétés
getImageBytes getItemDetails
Méthodes ReadOnly writeImageInFile
ClasseDetails TextID writeMenuActivites
isDataValids Méthodes writeMenuClasses
loadInformation EspDetails writeMenuCommentaires
recordModifications isDataValids writeMenuDateObservation
Figure 7.5 Diagramme de classes simplié de FauneTracker - Conguration.
loadCbClassesIte… writeMenuEffectifs
loadInformation writeMenuEspeces
recordModifications writeUsersFromGroupOfAResponsable
XmlGenerator
35
Chapitre 8
FauneTracker - PDA
8.1 Description
Le logiciel pour les PDA est destiné aux gardes-faune. Il doit principalement leur permettre
d'eectuer très simplement la saisie d'une observation d'animaux, fournir un positionnement
GPS et permettre de synchroniser facilement les données saisies, avec le serveur de donnée.
Il doit aussi permettre aux gardes-faune de consulter des informations sur d'anciennes ob-
servations et leurs permettre de ltrer celles-ci. Il faut que ce logiciel soit personnalisable
dynamiquement, par l'intermédiaire d'un chier de mission. Ce chier de mission sera régu-
lièrement fourni par le responsable du groupe de gardes-faune et dénira une mission pour
ceux-ci. Le diagramme de cas d'utilisations de la gure 2.1 synthétise ces fonctionnalités.
Figure 8.1 FauneTracker PDA, achage de la carte (gauche) et saisie de l'espèce (droite).
36
CHAPITRE 8. FAUNETRACKER - PDA 37
8.2 Achage et navigation sur une carte

Comme le bon sens l'impose, le développement a commencé par les points qui semblaient
les plus critiques. La première étape a donc été de réaliser les fonctions d'achage de la carte
ainsi que les outils de navigation sur celle-ci. Pour eectuer cette opération, les classes Map et
MobileService de la bibliothèque du SDK d'ArcGIS Mobile, sont à notre disposition.
La classe Map permet d'acher une collection de données géographiques fournie par un
MobileService. Le service mobile sert à gérer la connexion au serveur ArcGIS et à stocker
les données envoyées par ce serveur sur l'espace disque local, an de réduire le nombre de
requêtes et de pouvoir travailler en mode déconnecté. Dans le même but, il permet aussi de
lire les données à partir du cache, plutôt qu'à partir d'une connexion permanente au serveur.
An de démarrer le service mobile et de pouvoir acher des données sur le composant
Map, il faut réaliser les opérations suivantes :
1. dénir l'url du service mobile sur le serveur, au service mobile local à l'application ;
2. choisir l'emplacement du cache de cartes au sein du PDA ;
3. aecter le service mobile, comme source de données du composant carte sur le PDA ;
4. ouvrir le service mobile, en choisissant le mode d'ouverture du cache (Open correspond
à une simple lecture du cache sur le terminal, tandis que Create permet d'entièrement
renouveler le cache à partir du serveur).
// / Cette méthode permet d ' affecter au service mobile , l ' url du serveur
// / ainsi que l ' emplacement local du cache . Elle ouvre ensuite le service
// / mobile , à partir du cache et lève une exception en cas de problème
// / avec l ' ouverture de ce cache .
5 private void openMapService ()
// affectation de l ' url du service de gis

t h i s . m o b i l e S e r v i c e . Url = urlService ;
// choix de l ' emplacement du cache sur le PDA

10 t h i s . m o b i l e S e r v i c e . CacheStoragePath = cacheFolder ;
// affectation de mobileService comme source de données de la carte

t h i s . mapComponent . D a t a S o u r c e s . Add ( t h i s . m o b i l e S e r v i c e ) ;
// vérifie que le service a été correctement défini

15 if ( ! this . mobileService . IsValid )
CommonTools . s h o w E r r o r D i a l o g ( " Le cache de carte n ' est pas valide ! ") ;
else
20 {
try
// on ouvre le service de gis à partir du cache .

t h i s . m o b i l e S e r v i c e . Open ( CacheOpenMode . Open ) ;
25 }
catch ( Exception exc )
CommonTools . s h o w E r r o r D i a l o g (
" Le cache de carte n 'a pas pu être ouvert . "
30 + exc . Message ) ;
Listing 8.1 Méthode d'ouverture du service mobile.

Il faut maintenant fournir à l'utilisateur les outils suivants an qu'il puisse naviguer à
travers la carte :
zoom avant ;
zoom arrière ;
déplacement de la carte.
Pour réaliser ceci, les outils désirés fournis par le SDK d'ArcGIS Mobile sont ajoutés à
la collection d'actions MapActions de la carte. Les diérents outils vu ci-dessus ont donc été
ajoutés à la carte. Pour ajouter le zoom en avant, par exemple, il faut exécuter les instructions
suivantes :
// Création d 'un outil de zoom en avant
ZoomInMapAction zoomInAction
= new ESRI . ArcGIS . M o b i l e . M a p A c t i o n s . ZoomInMapAction ( t h i s . c o m p o n e n t s ) ;
// Ajout de cet outil à la carte

5 t h i s . c a r t e s . M a p A c t i o n s . Add ( z o o m I n A c t i o n )
Listing 8.2 Création de l'outil de zoom en avant.
Il sut ensuite, d'aecter l'outil correspondant au choix de l'utilisateur, lorsque celui-ci

en sélectionne un sur l'IHM. Un évènement de type click est donc ajouté sur les boutons liés
aux outils et appelle la méthode suivante (exemple pour le zoom en avant) :
// /
// / Déclenche le zoom en avant lorsque on appuie sur le menu correspondant .
// /
private void btZoomIn_Click ( o b j e c t sender , EventArgs e)
5 {
// Affectation de l ' outils zoom en avant , comme action

// courrante sur la carte .
c a r t e s . CurrentMapAction = zoomInAction ;
Listing 8.3 Exemple d'aectation d'un outils à la carte.
En ce qui concerne le zoom arrière et le déplacement de la carte, le code est presque identique,
il sut de choisir l'outil correspondant.
8.3 Lecture du chier de mission

L'application doit avoir accès à un chier de mission pour obtenir les données dont elle a
besoin. Le contenu ainsi que l'organisation de ce chier sont détaillés à la section 7.2. Il faut
donc lire ce chier et le rendre accessible facilement par les diverses classes de l'application.
Pour cela il a été décidé de le charger dans un objet contenant une collection de données,
appelé dataset.
Étant donné que les données contenues dans le dataset sont les mêmes tant que l'utilisateur
ne décide pas de changer de mission, il ne serait pas ecace de créer et remplir le dataset à
chaque fois que le programme doit accéder à un paramètre de conguration. C'est pourquoi
le choix a été fait d'utiliser le motif de conception singleton. Celui-ci permet de s'assurer qu'il
n'existe qu'une seule instance de la classe ConfigReader et que le dataset qu'elle contient ne
soit réinitialisé qu'en cas de changements de chier de mission.
Le code qui suit, illustre la manière dont a été implémenté le motif de conception singleton
ainsi que le remplissage du dataset, à partir du chier de mission.
// /
// / Permet de lire le fichier de configuration .
// / Utilise le motif de conception SINGLETON .
// /
5 class ConfigReader
// Dataset dans lequel est chargé le fichier de mission

private DataSet dsConfig ;
10 // Référence vers l ' instance unique de la classe

private static ConfigReader configReader ;
// Chemin du fichier de mission

private static String xmlCfgFilePath ;
15 // Le constructeur est privé , afin de s ' assurer

// que seule la classe ConfigReader puisse créer une instance
// d 'elle - même .
private ConfigReader ( ) {}
20 // Change l ' emplacement de lecture du fichier de mission .

public static void SetMissionFilePath ( String path )
// Change le répertoire
xmlCfgFilePath = path ;
25 // Remet l ' instance à null , afin qu ' une nouvelle instance

// et donc un nouveau dataset soient
// créés avec les nouvelles données
// lors de la prochaine demande du dataset .
configReader = null ;
30 }
// Renvoie l ' unique instance de la classe après avoir

// rempli le dataset
public static ConfigReader GetInstance ()
35 {
// Si l ' instance n ' existe pas encore ...

if ( configReader == null )
// ... elle est crée .

40 configReader = new ConfigReader ( ) ;
return configReader ;
45 // Lit le fichier de configuration et stocke le résultat

// dans un dataset , si le dataset n ' est pas déjà créé .
public DataSet getConfiguration ()
try
50 {
// Vérification de la non - existencec du dataset

if ( dsConfig == null )
// Création du dataset
55 dsConfig = new DataSet ( ) ;
// Chargement du fichier xml

XmlDocument xmlDoc = new XmlDocument ( ) ;
xmlDoc . Load ( x m l C f g F i l e P a t h ) ;
60 XmlNodeReader xnr = new XmlNodeReader ( xmlDoc ) ;
// Remplissage du dataset , à partir du fichier xml

d s C o n f i g . ReadXml ( x n r ) ;
65 return dsConfig ;
}
// Traitement de l ' exception levée si le fichier est introuvable

catch ( FileNotFoundException fnf )
70 CommonTools . s h o w E r r o r D i a l o g ( " F i c h i e r de mission introuvable ! ") ;
// Traitement de l ' exception levée si le fichier est invalide

catch ( Exception ex )
75 CommonTools . s h o w E r r o r D i a l o g ( " F i c h i e r de mission invalide . ") ;
return null ;
80
}
Listing 8.4 Lecture du chier de mission (implémentation du motif de conception singleton ).
8.4 Navigation GPS

Pour simplier le travail du garde-faune, un service qui consiste à centrer la carte sur sa
position GPS lui est proposé. An d'utiliser ce service, le garde-faune devra bien entendu
disposer d'un module GPS interne ou externe (un module bluetooth s par exemple).
Pour activer ce service, il faut disposer d'une instance de la classe GpsDisplay, qui permet
d'acher sur un objet Map, une position fournie par un objet SerialPortGpsConnection. Ce
dernier objet permet d'initier une connexion utilisant le protocole NMEA entre le terminal
et le récepteur GPS, à l'aide un port série. Toutes ces classes font partie du SDK d'ArcGIS
Mobile.
class FrmMap{
. . .
// / Configuration des éléments du formulaire .

5 private void InitializeComponent ()
. . .
// Pour que la carte suive le déplacement de l ' utilisateur .

10 t h i s . g p s D i s p l a y . AutoPan = true ;
// Affectation de la connexion GPS

t h i s . g p s D i s p l a y . GpsConnection = t h i s . serialPortGpsConnection ;
// Affectation de la carte
t h i s . g p s D i s p l a y . Map = this . carte ;
15 }
// / Ouvre ou ferme et configure la connexion GPS .

private void configureGPS ( )
20 // Si la connexion gps est deja etablie ,

// on verifie que l ' utilsateur veut bien
// desactiver celle - ci .
if ( s e r i a l P o r t G p s C o n n e c t i o n . IsOpen )
25 DialogResult dr = showQuestionDialog (
" Voulez −v o u s désactiver le suivi GPS? " ,
"GPS" ) ;
if ( dr == D i a l o g R e s u l t . Yes )
30 serialPortGpsConnection . Close () ;
}
// Sinon on ouvre une nouvelle connexion .

else {
DialogResult dr = showQuestionDialog (
35 " Voulez −v o u s activer le GPS? " ,
"GPS" ) ;
40 try
// Affectation du port , " AUTO " cherchera le port

// parmis les 20 premiers ports séries du terminal .
s e r i a l P o r t G p s C o n n e c t i o n . PortName = "AUTO" ;
45 // Ouverture de la liaison série avec le GPS .

s e r i a l P o r t G p s C o n n e c t i o n . Open ( ) ;
catch ( Exception e)
50 M e s s a g e B o x . Show ( " I m p o s s i b l e de connecter le GPS . "
+ " Vérifiez la configuration du système "
+ " et si le récepteur est allumé . " ) ;
55 }
Listing 8.5 Conguration et connexion du GPS.
8.5 Authentication
An de s'assurer que les données sont saisies par un garde-faune et que celui-ci utilise bien
le nom d'utilisateur qui lui est attribué, un mécanisme d'authentication par mot de passe a
été mis en place. Les diérents noms d'utilisateurs du groupe de gardes-faune pour lequel est
destinée la mission ainsi que le condensé (hash ) des mots de passe correspondants généré à
l'aide de l'algorithme MD5, sont stockés dans le chier de mission XML.
Figure 8.2 Principe de fonctionnement de l'authentication.

Algorithme de hachage
FauneTracker - PDA MD5
Mot de passe
entré par Condensé A
l’utilisateur
Condensé A = Utilisateur X
Vrai
Condensé B ? authentifié!
Condensé B
Fichier XML Lecture condensé

du mot de passe
de l’utilisateur X
Au moment de l'ouverture du programme et an d'éviter le plus possible les saisies avec
le clavier virtuelle, l'utilisateur pourra choisir son nom d'utilisateur parmi une liste achant
tous les noms d'utilisateurs du groupe. Il saisira ensuite son mot de passe qui sera haché et
comparé au hash stocké dans le chier XML. S'il s'avère que les deux condensés correspondent,
l'utilisateur sera authentié et pourra utiliser l'application. Cette technique évite de stocker
en un quelconque endroit les mots de passe en clair, ce qui serait désastreux au niveau de la
sécurité. Toutes ces étapes sont résumées sur la gure 8.2 et la portion de code qui suit, montre
la manière dont est généré le condensé d'une chaine de caractère dans notre application.
// /
// / Permet d ' obtenir le condensé MD5 d ' une
// / chaine de caractères .
// / < param name =" text " = Chaine de caractère
5 // / < returns > Condensé </ returns >
// /
public static string getMd5Hash ( S t r i n g text )
// Création d ' une instance de l ' implémentation par défaut

10 // de l ' algorithme de hachage .
MD5 md5Hasher = MD5 . C r e a t e ( ) ;
// Conversion du texte en un tableau d ' octet et calcul du hash

byte [ ] data = md5Hasher . ComputeHash ( E n c o d i n g . D e f a u l t . G e t B y t e s ( t e x t ) ) ;
15
// Recréation d ' une string a partir des octets
StringBuilder sBuilder = new StringBuilder () ;
for ( int i = 0; i < data . Length ; i ++)
20 // Ajoute le caractère , préalablement converti

// au format string depuis l ' hexadécimal .
s B u i l d e r . Append ( d a t a [ i ] . T o S t r i n g ( " x 2 " ) ) ;
return s B u i l d e r . ToString ( ) ;
25 }
Listing 8.6 Génération d'un condensé md5.
8.6 Synchronisation
Le garde-faune doit avoir la possibilité, lorsqu'il le désire et qu'une connexion à internet
est établie sur le PDA, de synchroniser celui-ci an de publier sur le serveur les observa-
tions qu'il a eectuées et de récupérer les modications faites sur les diérentes couches de
fonctionnalités. Étant donné que sur le PDA, l'observateur peut uniquement saisir de nou-
velles données et ne peut pas éditer ou supprimer les anciennes, lors de la synchronisation il
sut de poster ses nouvelles observations et de récupérer celles eectuées par ses collègues
ainsi que les mises-à-jour de celles qu'il possède déjà. Pour eectuer ces deux opérations, la
classe MobileService du SDK d'ArcGIS Mobile fournit deux méthode très pratiques. La pre-
mière, PostFeaturesAsync(), prend comme unique paramètre un objet permettant d'identier
la transaction et envoie au serveur toutes les nouvelles informations saisies sur les couches de
fonctionnalités de la carte, ceci de manière asynchrone. La deuxième, GetFeatureDataAsync(),
sert à récupérer les changements ainsi que les nouveaux enregistrements saisis dans les couches
de fonctionnalités, à partir du serveur. Elle agit aussi de façon asynchrone et prend comme
paramètre l'étendue sur laquelle les données doivent être récupérées, un booléen indiquant si
le cache doit être rafraichi et un identiant de transaction.
// /
// / Synchronisation des données entre le serveur et le périphérique .
// /
private void synchronizeData ()
5 {
// On vérifie si l ' url du cache de carte est valide .

if ( s t r i n g . IsNullOrEmpty ( m o b i l e S e r v i c e . U rl ) )
throw new I n v a l i d O p e r a t i o n E x c e p t i o n ( " Le cache de carte ne possède pas une URL
valide . ") ;
10 // Créé un dialogue demandant à l ' utilisateur s 'il veut effectuer la

synchronisation .
DialogResult dr = CommonTools . s h o w Q u e s t i o n D i a l o g (
" Voulez −v o u s synchroniser les données avec le serveur " ,
" Synchronisation ") ;
15 // Si oui
errorMessageDisplayed = false ;
// Réinitialisé pour chaque requête , mis à faux au début

20
// Publie les mises à jours
m o b i l e S e r v i c e . PostFeaturesAsync ( " Post from " + userID ) ;
// On récupère l ' étendue de la carte de base

25 Envelope zoneDeMiseAJour = m o b i l e S e r v i c e . Laye rs [ 0 ] . GetExtent ( ) ;
// Récupère la dernière version des couches

m o b i l e S e r v i c e . GetFeatureDataAsync ( zoneDeMiseAJour , true , " GetFeatures " +
userID ) ;
Listing 8.7 Synchronisation des données.

Finalement, il faut s'assurer que les données aient été synchronisées correctement. Pour cela
le programme reste à l'écoute de l'évènement RequestCompleted qui est déclenché lorsqu'une
requête de synchronisation est achevée. Une vérication est faite au sein de la méthode traitant
cet évènement, pour savoir s'il n'y a pas eu d'erreur de synchronisation. En cas d'erreur
l'utilisateur est notié.
// /
// / Déclenché lorsqu ' une requête vers le service de carte
// / est terminée . Permet d ' afficher un message d ' erreur
// / en cas de problème .
5 // /
private void mobileService_RequestCompleted (
object sender ,
sRequestCompletedEventArgs e)
10 // S 'il existe une erreur , et qu 'il n 'y pas déjà

// eu un message d ' erreur affiché pour cette requête
// => on notifie l ' utilisateur .
if ( e . Error != null && ! errorMessageDisplayed )
15 CommonTools . s h o w E r r o r D i a l o g ( " S y n c h r o n i s a t i o n impossible , "
+ " vérifiez la connexion . "+e . E r r o r . M e s s a g e ) ;
// Indique qu 'un message d ' erreur a été affiché .

errorMessageDisplayed = true ;
20 }
Listing 8.8 Vérication du bon déroulement de la synchronisation.

8.7 Saisie d'une observation

8.7.1 Ajout de données sur la carte
La première étape pour la saisie d'une observation, est la saisie de ses coordonnées géo-
graphiques. L'utilisateur a le choix d'eectuer une observation statique où une observation
de déplacement. L'observation statique consiste en la saisie d'un point ou se trouve l'animal
alors que l'observation d'un déplacement permet de saisir le trajet de l'animal, sous la forme
de lignes brisées.
Une couche géographique faisant partie de la carte est disponible pour chacun des types
d'observations vus ci-dessus. Il y a donc une couche de points et une de lignes-brisées. Lorsque
l'utilisateur dessine une nouvelle observation sur la carte, celle-ci est en fait saisie sur une
troisième couche, qui est une couche temporaire spécialement prévue pour la saisie de nouvelles
informations. Lorsque le dessin est validé, celui-ci pourra ensuite être copié sur la couche voulue
et eacé de la couche temporaire.
Les opérations suivantes sont réalisées pour préparer l'édition lors d'un clique de l'utilisa-
teur sur un bouton pour ajouter un point ou une ligne-brisée :
1. récupération de la couche correspondant au type de saisie que souhaite faire l'utilisateur ;
2. aectation de l'outil d'ajout de coordonnées comme action courante sur la carte ;
3. choix pour cet outil du type de forme qu'il devra dessiner, en fonction de la couche
éditée.
// /
// / Permet de préparer la couche géographique , et les outils
// / nécessaire à l ' ajout de la coordonnée . Le nom
// / de la couche à éditer est fourni en paramètre .
5 // /
private void debutEditionCarte ( s t r i n g layerName )
// On vérifie qu 'il n 'y a pas déjà une saisie en cours

if ( ! saisieEnCours )
10 {
// Affiche les contrôles liés à l ' ajout de nouvelles observations

this . pnlControlsObservations . Visible = true ;
// Récupère la couche à éditer à partir de la carte

editLayer = m o b i l e S e r v i c e . L a y e r s [ layerName ] as FeatureLayer ;
15 // Sélection de l ' outils d ' ajout de données géographiques

c a r t e . CurrentMapAction = ajouterCoordonnee ;
// Vérification de l ' existance de la couche

if ( editLayer == null )
20 throw new NullReferenceException (
" La couche recherchée n 'a pas été trouvée " ) ;
// Récupération du type de formes contenues

// dans la couche ...
25 GeometryType geometryType = e d i t L a y e r . GeometryType ;
// ... et choix de l ' outils de dessin correspondant .

switch ( geometryType )
case GeometryType . P o l y l i n e :
30 s k e t c h G r a p h i c L a y e r 1 . Geometry =
new Polyline () ;
break ;
case GeometryType . P o i n t :
s k e t c h G r a p h i c L a y e r 1 . Geometry =
35 new ESRI . ArcGIS . M o b i l e . G e o m e t r i e s . P o i n t ( ) ;
// Permet de savoir qu ' une saisie est en cours

saisieEnCours = true ;
40 }
Listing 8.9 Préparation de l'édition de la couche.

On attend ensuite que l'utilisateur termine sa saisie en cliquant le bouton pour valider
celle-ci. Il faut alors vérier que des informations ont bien été ajoutées à cette couche et
eectuer les traitements suivants :
1. récupération de la table d'attributs contenant les données de la couche en édition ;
2. récupération de la forme dessinée sur la couche de dessin ;
3. création d'un objet SaisieProcess ;
4. lancement du processus de saisie ;
5. eaçage des données saisies sur la couche de dessin.
// /
// / Appelé lorsque l 'on clique sur le bouton pour valider un dessin
// / et lance le début d 'un processsus de saisie .
// /
5 private void btValider_Click ( object sender , EventArgs e)
// Vérification de l ' existance d ' une session de saisie .

if ( saisieEnCours )
10 // On vérifie qu ' un élément a été ajouté

if ( ! c o u c h e D e D e s s i n . Geometry . I s E m p t y )
// Récupération de la table contenant les données de la couche

// en édition .
15 FeatureDataTable observations = e d i t L a y e r . GetDataTable ( ) ;
// Récupération de la forme dessinée sur la couche de dessin .

Geometry nouvelleForme = c o u c h e D e D e s s i n . Geometry ;
// Créé un nouveau processus de saisie .

20 SaisieProcess saisieProcess =
new SaisieProcess (
configData ,
observations ,
e d i t L a y e r . GeometryColumnIndex ,
25 s e r i a l P o r t G p s C o n n e c t i o n . IsOpen ,
userID ,
nouvelleForme ) ;
// Démarrage du processus
saisieProcess . s a i s i e () ;
30
// efface les données ajoutées sur la couche de dessin
c o u c h e D e D e s s i n . Geometry = null ;
saisieEnCours = false ;
35 // Masquage des controles relatifs à la saisie .

this . pnlControlsObservations . Visible = false ;
Listing 8.10 Validation du dessin et lancement du processus de saisie.

8.7.2 Collecte des informations

Une fois la position de l'observation faunistique saisie, l'observateur doit entrer plusieurs
informations sur celle-ci. Pour répondre aux objectifs du cahier des charges, le procédé doit
être aussi simple que possible. Il devra de plus minimiser les erreurs de saisie. C'est pourquoi il
a été décidé de guider l'observateur, à travers plusieurs formulaires se succédant pour collecter
les données sur l'observation.
Les formulaires permettent de saisir respectivement :
la classe d'espèce ;
l'espèce ;
l'activité de l'animal ;
les eectifs mâles, femelles et indeterminés, ainsi que pour chacun des sexes, la tranche
d'âge des animaux observés ;
la date de l'observation ;
un commentaire optionnel.
Comme on peut le voir sur la gure 8.3, le procédé de saisie peut être décrit par une
machine à états. En conséquence, an d'implémenter les diérents formulaires utilisés lors de
la saisie, il a été décidé d'utiliser le motif de conception état. Celui-ci permet à un objet de
modier son comportement en fonction de son état interne.
Figure 8.3 Machine à états de la saisie.
Saisie Classe
Précédent Suivant
Saisie espèce
Précédent Suivant
Saisie activité
Précédent Suivant
Saisie effectifs
Précédent Suivant
Saisie date d’observation
Précédent Suivant
Saisie commentaire
Précédent Suivant
Affichage récapitulatif
de la saisie
Suivant
Les participants au motif de conception sont les suivants :

IEtats est une interface introduisant notamment la signature des méthodes suivant()
et precedent() qui permettent d'eectuer les transitions entre états. Elle dénit aussi
diverses autres méthodes devant être implémentées par chacun des états.
SaisieProcess est une classe concrète, qui représente la machine à états. Elle possède
une référence vers une instance d'une classe implémentant l'interface IEtats.
SaisieClasse, SaisieEspece, SaisieActivite, SaisieEffectifs, SaisieDate et en-
n SaisieCommentaires sont des classes concrètes, décrivant les états éponymes.
public interface IEtats
// transition vers l ' état suivant

void suivant () ;
5 // transition vers l ' état précédent

void precedent () ;
// active l ' état courant

void activer () ;
// désactive l ' état courant

10 void desactiver () ;
// libère toutes les ressources occupées par l ' état

void libererRessources () ;
Listing 8.11 Interface IEtats.

Voici le code de la méthode permettant de passer à l'état suivant au sein d'un état (en
l'occurence SaisieActivite) :
class SaisieActivite : AFormSaisieObservationListView
. . .
5 // / Implémentation de la méthode du design pattern état

// / permettant de passer à l ' état suivant ( en l ' occurence " SaisieEffectifs ") .
// / La définition de cette méthode provient de l ' interface
// / IEtatSaisieObservation .
// / < param name =" nextMenuId "> numéro du menu suivant </ param >
10 public override void suivant ( int nextMenuId )
// Récupération de l ' élément sélectionné

string selectedItem = t h i s . getSelectedItemTag () ;
// Si un élément est sélectionné ...

15 if ( selectedItem != null )
// ... enregistrement dans la machine à état de la donnée saisie

// dans ce formulaire ...
( ( S a i s i e P r o c e s s ) machineEtats ) . A c t i v i t e I D
20 = i n t . Parse ( getSelectedItemTag ( ) ) ;
// ... et passage à l ' état suivant .

m a c h i n e E t a t s . e t a t S u i v a n t ( new S a i s i e E f f e c t i f s ( nextMenuId , m a c h i n e E t a t s ) ) ;
// ... sinon affichage d 'un message d ' erreur contraignant l ' utilisateur
25 // à sélectionner un élément .
else
M e s s a g e B o x . Show ( " V e u i l l e z choisir un element . " ) ;
30 }
Listing 8.12 Méthode suivant(), dénie par l'interface IEtats.

8.8 Filtrage des informations

L'utilisateur doit avoir la possibilité d'eectuer des requêtes de ltrage, directement sur
le PDA. Étant donné que le garde-faune n'est pas censé posséder des connaissances avancées
en informatique, il faut que l'utilisateur soit guidé pour la création de la requête, et non qu'il
ait à saisir le code SQL correspondant lui-même. C'est pourquoi il a été choisi de mettre à
sa disposition un assistant de création de ltres. Cet assistant récolte les informations selon
lesquelles le garde-faune souhaite ltrer les données et créé au fur et à mesure la requête
correspondante.
Les mandants du projet souhaitent que l'observateur puissent ltrer parmi les classes, les
espèces et les dates de saisies de l'observation (fourchette minimum-maximum). Ils désirent
en plus que plusieurs requêtes puissent être combinées. Voici deux exemples de requêtes que
les gardes-faune peuvent formuler :
acher les renards vulpes, aperçus du premier janvier 2007 au 31 novembre 2007 ;
visualiser toutes les espèces de la classe des mammifères vues depuis il y an un an.
Figure 8.4 Machine à états de la création d'un ltre.
Saisie Classe
Précédent Suivant
Saisie espèce
Précédent Suivant
Ajouter filtre
Saisie date
d’observation
minimum
Précédent Suivant
Saisie date
d’observation
Précédent maximum Suivant
Affichage du résultat
sur la carte
Terminer
Le diagramme 8.4 présente la machine à états correspondant au processus de création de

la requête. Le constat que les états décrits sur cette gure sont pratiquement les mêmes que
ceux de la machine à états de la saisie (gure 8.3), peut très vite être réalisé. De plus, les
formulaires utilisés pour saisir une observation, sont quasiment identiques à ceux qui doivent
être implémentés pour créer la requête. Il existe en eet, uniquement deux diérences :
l'utilisateur doit pouvoir sauter un écran, lorsqu'il ne souhaite pas ltrer selon le
critère correspondant à celui-ci ;
les transitions ne sont pas les mêmes.
C'est pourquoi, le choix de réutiliser les mêmes classes d'états que celles utilisées pour la
saisie a été fait. Une condition lors de la création des formulaire ainsi que pour les transitions a
simplement été ajoutée, an de savoir si la machine à états utilisée est la machine permettant
d'eectuer une saisie ou celle permettant de construire un ltre. Les actions appropriées sont
choisies en conséquence.
Une classe abstraite AStateMachine permet de factoriser les éléments communs aux deux
machines à états. Les classes SaisieProcess et ConstructRequestFilter dérivent de cette
classe abstraite et ajoutent les comportements spéciques. Il faut noter, qu'une fois encore,
le motif de conception template method est utilisé an de structurer au mieux et optimiser le
code. Le diagramme de classes partiel de la gure 8.5 présente les relations entre les classes
utilisées pour mettre en oeuvre ces machines à états.
Figure 8.5 Diagramme de classes du motif de conception état.

IEtatSaisieObservation
IEtatSaisieObservation
Abstract Class Interface Abstract Class
Form historiquesEtats
Méthodes Propriétés
Champs
RequeteType
dataSet
Abstract Class Méthodes
menuId etatCourant
AFormSaisieObservation
Méthodes
Champs activer
listView desactiver etatPrecedent
libererRessources machineEtats etatSuivant
Méthodes
precedent libererRessources
suivant
ConstructRequestFilter SaisieProcess
Class Class
SaisieClasse SaisieEspece AStateMachine AStateMachine
Class Class
AFormSaisieObservation… AFormSaisieObservation…
SaisieCommentaire SaisieDate SaisieEffectifs

Class Class Class
AFormSaisieObservation AFormSaisieObservation AFormSaisieObservation
8.9 Hiérarchie des composants

An de faciliter l'implémentation future de nouveaux formulaires de saisies et en plus du
design pattern état, les vues ont été organisées de façon hiérarchique. Tous les formulaires de
saisie héritent de la classe abstraite AFormSaisieObservation. Celle-ci dénit les éléments de
base d'un formulaire de saisie, à savoir :
un bouton suivant et précédent ;
un label pour acher l'étape en cours ;
une référence vers le dataset contenant les données de mission ;
les méthodes répondant aux évènements sur les boutons ;
un identiant de menu.
De plus, cette classe dénit les méthodes pour remplir le champ titre du formulaire ainsi
que le label achant l'étape en cours. Lors d'un clique sur le bouton suivant, celle-ci capture
l'évènement, calcule l'identicateur du formulaire suivant et appelle une méthode pour passer
à l'état suivant. Toutefois cette méthode étant abstraite, le choix de son implémentation est
laissé aux classes descendantes. Ceci correspond à la dénition du motif de conception template
method (voir point 7.5.2).
// / Classe abstraîte spécifiant les comportements de base .
public abstract class AFormSaisieObservation : Form , IEtatSaisieObservation
. . .
5 // Méthode à implémenter dans les classes descendantes

public abstract void suivant () ;
. . .
// Est appelé lorsque l ' utilisateur clique sur le bouton " suivant "
// Dans le design pattern , cette méthode est appelée " méthode patron "
10 private void btSuivant_Click ( o b j e c t sender , EventArgs e)
// Traitement factorisé
int nextMenuId = menuId++;
// Appel de suivant , qui est implémenté dans les sous - classes

15 t h i s . s u i v a n t ( nextMenuId ) ;
// / Classe qui concrètise " AFormSaisieObservation "

20 class SaisieDate : AFormSaisieObservation
// Implémentation concrête de la méthode définie dans la classe abstraîte

AFormSaisieObservation
public override void suivant ( int nextMenuId )
25 s a i s i e . DateObservation = t h i s . calendarDateObs . SelectionEnd ;
s a i s i e . e t a t S u i v a n t ( new SaisieCommentaire ( s a i s i e , nextMenuId ) ) ;
Listing 8.13 Illustration du design pattern template method.

Les classes SaisieEffectifs, SaisieDate, AffichageRecapitulatif et enn Saisie
Commentaire héritent directement de la classe abstraite AFormSaisieObservation et ajoutent
des composants graphiques selon le type de données à saisir et dénissent le comportement des
diverses méthodes abstraites héritées. SaisieEspece, SaisieClasse et SaisieActivites hé-
ritent quant à elles d'une classe abstraite intermédiaire, AFormSaisieObservationListView.
Celle-ci ajoute le composant graphique permettant d'acher une liste d'images (listview ) et
implémente diverses méthodes liées à celui-ci, telle que loadListViewItems() qui charge des
éléments et images dans la liste, à partir du chier de mission.
CHAPITRE 8.
IEtats
IEtats
Interface Abstract Class
Form
etatCourant
SaisieCommentaire AffichageRecapitulatif SaisieDate SaisieEffectifs

Class Class Class Abstract Class Class
AFormSaisieObservation AFormSaisieObservation AFormSaisieObservation AFormSaisieObservation AFormSaisieObservation
FAUNETRACKER - PDA
machineEtats
typeRequete TypeRequete SaisieActivite SaisieEspece SaisieClasse

Abstract Class Enum Class Class Class
AFormSaisieObservation… AFormSaisieObservation… AFormSaisieObservation…
ctrlFemellesJuveniles
ConstructRequestFilter SaisieProcess Effectifs StructEffectifs FrmMenu FrmMap CtrlEffectifs

Class Class Struct Class Class Class
AStateMachine AStateMachine Form Form UserControl
CommonTools ConfigReader
Static Class Class
Authentification
Class
Figure 8.6 Diagramme de classes simplié de FauneTracker - PDA.
Form
Program
Static Class
51
Chapitre 9
FauneTracker - Desktop
9.1 Description
Dans le cadre du projet, il peut être très utile d'avoir la possibilité de consulter les données
directement sur un ordinateur de bureau, plutôt que sur un PDA. L'ordinateur est en eet, bien
plus adapté pour visualiser des cartes et avoir une vision globale des résultats. De plus, en cas
d'erreur dans les saisies ou pour apporter un complément d'informations aux observations, il
faut prévoir un moyen d'éditer celles-ci. Or, cela compliquerait considérablement et inutilement
l'interface de FauneTracker - PDA si des fonctions d'édition lui étaient directement ajoutées.
Il faut en outre relever, qu'il ne serait pas commode pour l'utilisateur d'éditer les observations
directement sur le PDA.
C'est pourquoi, il a été décidé de développer FauneTracker - Desktop. Cette application
fonctionnera sur un ordinateur de bureau standard, utilisant Windows. Elle devra permettre
de résoudre les problématiques soulevées ci-dessus. Les développements spéciques à cette
application seront vus dans ce chapitre. Le fonctionnement de l'achage et de la navigation
sur une carte, les mécanismes d'accès aux données, ainsi que tous les points qui ont déjà été
abordés et détaillés dans les chapitres précédents, ne seront pas évoqués ici.
9.2 Gestion des droits

La politique suivante a été adoptée pour la gestion des droits d'utilisation du programme :
Un utilisateur quelconque, peut utiliser l'application pour consulter les données.Il n'a
cependant en aucun cas la possibilité d'éditer la géométrie ou les attributs d'une obser-
vation.
Un observateur qui s'authentie lors de la connexion, hérite des droits de l'utilisateur
simple. Il peut, qui plus est, éditer les observations dont il est l'auteur.
Un responsable authentié hérite quant à lui, des droits de l'observateur. Il a en outre
la possibilité d'éditer les données de tous les membres faisant partie de son groupe
d'utilisateurs.
52
CHAPITRE 9. FAUNETRACKER - DESKTOP 53
Figure 9.1 Interface graphique de FauneTracker Desktop.
9.3 Informations sur une observation

La première vocation de l'application est de pouvoir consulter les informations sur les ob-
servations. Pour cela, l'utilisateur dispose d'un outil de sélection, qui lui permet de choisir une
observation. Dès la sélection d'une de celles-ci, le composant OservationDetailsComposant
ache ses diérents attributs sur le formulaire principal. Voyons à présent la façon dont ces
opérations ont été implémentées.
Tout d'abord, lorsque l'utilisateur clique sur le bouton permettant d'obtenir des informa-
tions sur une observation, l'outil de sélection est activé :
private void choixSelection_Clique ( object sender , EventArgs e)
// Choix de l ' action

c a r t e . CurrentMapAction = outilSelection ;
5 // Choix de la légende
l b l S t a t u s A c t i o n . Text = " Sélection " ;
Cet outil est lié à une sur-couche de la carte appelée coucheSelection. Quand un élément
est sélectionné sur une des couches d'observation, la couche de sélection permet de le mettre en
évidence en dessinant un symbole au-dessus de celle-ci, sans aecter l'observation elle-même.
Il faut à présent écouter les évènements intervenants sur l'outil de sélection, an de savoir
si une observation a été sélectionnée. Si c'est le cas, les opérations suivantes sont eectuées :
1. récupération de la table contenant les données de la couche de sélection ;
2. récupération de l'enregistrement correspondant à l'observation sélectionnée ;
3. récupération de la clé de l'observation ;
4. chargement dans l'instance de la classe OservationDetailsComposant, des informations
sur l'observation ;
5. selon les droits de l'utilisateur du programme, achage des boutons permettant de
modier l'enregistrement.
Ces opérations sont eectuées dans la méthode appelée lorsque le statut de l'outil de
sélection change. Voici le code correspondant :
private void selectionAction_StatusChanged (
object sender ,
MapActionStatusChangedEventArgs e)
5 // Vérifie que l ' action est terminée et qu ' une observation a été sélectionnée
if (( e . StatusId == MapAction . C o m p l e t e d )
&& ( o u t i l S e l e c t i o n . S e l e c t e d F e a t u r e s . Count > 0) )
// On récupère la table correspondant à la couche de sélection

10 FeatureDataTable selectedFeatureTable = outilSelection . SelectedFeatures [ 0 ] ;
// Récupère la première ligne de la première table , qui correspond

// à l ' observation sélectionnée puisqu 'on ne peut
// sélectionner qu 'un seul point à la fois
DataRow consultedFeature = s e l e c t e d F e a t u r e T a b l e . Rows [ 0 ] ;
15 // Récupère la clé de l ' observation

int idx_observation = i n t . P a r s e ( c o n s u l t e d F e a t u r e [ "OBJECTID" ] . T o S t r i n g ( ) ) ;
// Chargement des informations de l ' observation dans le panneau latéral

t h i s . observationDetailsComposant . chargerInformations (
idx_observation , o u t i l S e l e c t i o n . S e l e c t e d F e a t u r e s [ 0 ] . F e a t u r e L a y e r . Name ) ;
20 // Vérifie les droits , et si l ' utilisateur à les droits d ' éditions ,

// active les boutons correspondants .
if ( verifierDroitObservateur (
i n t . P a r s e ( c o n s u l t e d F e a t u r e [ " ID_Observateur " ] . T o S t r i n g ( ) ) ) )
activeOrDeactiveSaisieButtons ( true ) ;
25 }
Listing 9.1 Méthode selectionAction_StatusChanged de FrmMain.

La méthode charger() de la classe OservationDetailsComposant, s'occupe d'interroger la
base de données, an de prélever toutes les informations sur l'observation, puis de mettre en
forme ces résultats pour l'utilisateur.
9.4 Édition d'une observation

9.4.1 Géographie
Le premier élément qui peut être à corriger dans une observation, est sa géométrie. En
eet, un point représentant une observation statique a pu être mal placé, ou alors les segments
d'une ligne-brisée peuvent, par exemple, ne pas être susamment nombreux pour décrire
correctement une observation de déplacement.
Il faut donc prévoir un moyen de corriger la géométrie des formes saisies. Le SDK d'ArcGIS
Mobile propose diérents outils permettant d'eectuer ces opérations.
Après avoir sélectionné une observation, si celui-ci possède les droits pour l'éditer, l'utili-
sateur peut choisir un outil pour l'édition des formes dans le menu du programme :
déplacement d'un vertex ;
insertion d'un vertex ;
suppression d'un vertex.
Lors d'un clique sur l'un de ces éléments de menus, l'outil correspondant sera chargé. Ces
outils sont liés à une couche supplémentaire de la carte permettant de dessiner sur celle-ci.
La forme choisie est ensuite copiée de la couche de sélection vers la couche de dessin ; ainsi,
toutes les modications sont achées et enregistrées au sein de cette couche tampon. À la n
de son édition l'utilisateur possède le choix d'enregistrer ou de rejeter les modications qu'il
a apporté à la géométrie de la forme.
Le code suivant est appelé lorsque l'utilisateur a choisi un outil parmi le menu et permet
de préparer l'édition :
// outil est l ' outil choisit par l ' utilisateur
// legende est le texte à afficher dans la barre de statut
private void c h o i s i r O u t i l ( MapAction outil , String legende )
5 // Choisit la légende affichée dans la barre de statut

t h i s . l b l S t a t u s A c t i o n . Text = legende ;
// Désactive les boutons sans liens avec l ' édition

activeOrDeactiveNotSaisieButtons ( true ) ;
// Choisi l ' outil permettant d ' insérer un vertex

10 c a r t e . CurrentMapAction = outil ;
// Si la couche de dessin est vierge ,

// on copie la forme sélectionnée sur la couche de sélection ,
// sur la couche de dessin , dans le but de l ' éditer .
if ( c o u c h e D e s s i n . Geometry == null
15 || c o u c h e D e s s i n . Geometry . I s E m p t y
&& c o u c h e S e l e c t i o n . S e l e c t e d G e o m e t r i e s . Count >0)
c o u c h e D e s s i n . Geometry = coucheSelection . SelectedGeometries [ 0 ] ;
20 }
Listing 9.2 Méthode choisirOutil() de FrmMain.

L'utilisateur peut ensuite utiliser les diérents outils d'édition et modier la forme selon
ses besoins. Lorsqu'il a nit d'éditer celle-ci et s'il décide enregistrer les modications, le
programme doit eectuer les opérations suivantes :
1. remplacement de l'ancienne forme dans la table de la couche d'observations, par celle
modiée ;
2. enregistrement des changements eectués dans la table de la couche d'observations, dans
la couche elle-même ;
3. transmission des modications au serveur ;
4. suppression des formes dessinées sur la couche de dessin ;
5. désactivation des menus d'édition.
Le code décrivant ces opérations est présenté sur la page suivante.
private void enregistrerModification_Click ( object sender , EventArgs e)
// Récupère la table correspondant à la couche sélectionnée

FeatureDataTable tableCoucheSelectionnee = outilSelection . SelectedFeatures [ 0 ] ;
5
// Récupération de la couche à modifier
FeatureLayer coucheEditee = o u t i l S e l e c t i o n . S e l e c t e d F e a t u r e s [ 0 ] . FeatureLayer ;
// Récupération de l ' index de la colonne de la table ou sont stockées les

informations géométriques
int geometryIndex = c o u c h e E d i t e e . GeometryColumnIndex ;
10 // Récupération de la version éditée de la forme

Geometry nouvelleGeometrie = c o u c h e D e s s i n . Geometry ;
// Récupération de l ' enregistrement contenant les données de l ' observation

DataRow editedFeature = t a b l e C o u c h e S e l e c t i o n n e e . Rows [ 0 ] ;
15 // Mise à jour de la géométrie dans la table de

// la couche d ' observations
e d i t e d F e a t u r e [ geometryIndex ] = nouvelleGeometrie ;
// Enregistrement des changements dans la couche

// d ' observations .
20 tableCoucheSelectionnee . SaveInFeatureLayer ( ) ;
// Transmission des modifications au serveur

m o b i l e S e r v i c e . PostFeaturesAsync ( " M o d i f i c a t i o n forme " ) ;
25 // Suppression des formes sur la couche de dessin

c o u c h e D e s s i n . Geometry . C l e a r ( ) ;
// Remise des menu à leurs états initiaux

razActivationsMenus () ;
Listing 9.3 Méthode pour enregistrer les modications (enregistrerModication_click ).
Figure 9.2 Formulaire d'édition des attributs d'une observation.

9.4.2 Attributs
L'utilisateur peut aussi avoir à renseigner une information supplémentaire sur une observa-
tion ou alors modier une erreur. Il faut donc mettre à sa disposition une interface utilisateur
permettant de le faire facilement.
Lorsque l'utilisateur sélectionne une observation pour laquelle il possède les droits d'édition,
le bouton Éditer s'active. Si l'utilisateur presse sur celui-ci, un formulaire d'édition apparait à
l'écran. Pour éviter la redondance de code, ce formulaire sera constitué du même composant
qui permet de visualiser les informations sur l'observation, OservationDetailsComposant, à
la diérence près que celui-ci deviendra éditable. L'édition de certains champs, tels que le nom
de l'observateur et la date de saisie, restera proscrite car ces informations ne sont pas saisies
par l'utilisateur, mais directement par le programme et ne sont donc pas sujettes à des erreurs
de saisies.
FrmMain FrmAuthentification OservationDetailsComposant
CHAPITRE 9.
Class Class Class

Form
utilisateur StructUsers Utilisateur Form UserControl
Struct
Champs Propriétés Champs

btDeplacer NomResponsable cbActivites
btEditer Méthodes cbClasses
btSupprimer Dispose cbEspeces
CACHE_PATH RouletteZoomHandler chkGPS
Class FrmAuthentification
carte dtpDateObs
coucheDessin dtpDateSaisie
coucheSelection Champs BDDUtils lblFA
carte Static Class
mobileService lblFJ
outilDeplacerVertex rouletteZoomHandler etendueCarte lblIA
outilInsererVertex OnMouseWheel Méthodes lblID
outilSelection Méthodes faitPartieDuGroupeDunResponsable lblIJ
outilSupprimerVertex MouseWheel getConnection lblIP
panMapAction RouletteZoomHandler getUtilisateur lblMA
statusBar StartListening getUtilisateurs lblMJ
URL_SERVICE StopListening pbEspece
FAUNETRACKER - DESKTOP
Méthodes txtCommentaires
annulerModificationsToolStripMenuItem_Click txtObservateur
Dialogs
btEditer_Click Static Class Propriétés
btSupprimer_Click FrmEdit ReadOnly
Class
carte_ExtentChanged Méthodes Méthodes
Form
choisirOutil showErrorDialog chargerCbActivites
choixSelection_Clique Champs showStandardQuestionDialog chargerCbClasses
deplacerVertexToolStripMenuItem_Click showWarningDialog chargerCbEspeces
btAnnuler
enregistrerModification_Click chargerInformations (+ 1 surcharge)
btEnregistrer
FrmMain enregistrerModifications
FrmMain_Load Méthodes observationDetailsComposant
getImage
insererVertexToolStripMenuItem_Click btEnregistrer_Click
OservationDetailsComposant
FrmEdit (+ 1 surcharge)
Figure 9.3 Diagramme de classes simplié de FauneTracker - Desktop.
mobileService_RequestCompleted rafraichir
selectionAction_StatusChanged observationDetailsComposant supprimer
verifierDroitObservateur
58
Chapitre 10
Déploiement
10.1 Introduction
Le cahier des charges établi lors de la capture des besoins, stipule qu'il est indispensable
que le programme soit aussi simple que possible d'utilisation. Cette facilité doit cependant
être étendue au-delà du programme lui-même. An que l'utilisateur nal puisse installer le
programme sur son ordinateur et son PDA sans recourir à l'aide d'un administrateur système
ou autre, deux programmes d'installations (installateurs) dont l'utilisation est très aisée ont
été réalisés. Le premier permet d'installer la partie de l'application résidant sur des ordinateurs
de bureau FauneTracker - Desktop et FauneTracker - Conguration, et le second pour la partie
mobile FauneTracker - PDA.
10.2 Déploiement de FauneTracker pour PC

An de simplier la procédure d'installation pour l'utilisateur, la décision a été prise de
créer un installateur unique, permettant de déployer en même temps FauneTracker - Desktop
et FauneTracker - Conguration. En plus d'installer ces deux logiciels, celui-ci ajoute des rac-
courcis pour ceux-ci dans le menu démarrer de l'utilisateur et installe les diverses bibliothèques
(DLL) nécessaires pour exécuter les composants du SDK d'ArcGIS Mobile.
10.3 Déploiement de FauneTracker - PDA

10.3.1 Génération d'un cache de cartes
La première étape du déploiement, consiste à créer un cache de carte à partir du service
mobile créé au point 6.3.4. Cela permet d'éviter lors de la première connexion du terminal,
d'avoir à télécharger le fond de carte ainsi que toutes les données déjà saisie lors de la création
du cache. De plus un outils d'ArcCatalog (Generate Mobile Service Cache ) permet de générer
un cache spécialement pour les appareils mobiles. Celui-ci occupera beaucoup moins d'espace
disque qu'un cache de carte standard et sera optimisé pour pouvoir être aché rapidement
par un dispositif possédant peu de ressources, tel qu'un PDA.
59
CHAPITRE 10. DÉPLOIEMENT 60
Figure 10.1 Génération du cache de carte et synchronisation.
Synchronisation quotidienne
Service web
Application
Développement de
FauneTracker-PDA
Exécutable
(.EXE)
ArcGIS Server
Génération du cache de carte Cache de cartes Deploiement
10.3.2 Génération d'un chier cab

Les application PocketPC sont installées par l'exécution de chier CAB sur le PDA. Il
s'agit de chiers d'archives qui peuvent s'auto-extraire et qui contiennent les instructions
d'installation ainsi que tous les chiers requis par l'application.
Dans le cadre du projet, un chier CAB contenant l'application FauneTracker - PDA va
donc être généré. Cette application est elle-même compilée avec le cache de cartes, tel qu'on
peut le voir sur le schéma 10.2. Diverses DLL d'ArcGIS nécessaires au fonctionnement du
projet sont aussi incluses et des raccourcis pour l'utilisateur sont créés, an qu'il puisse lancer
le programme à partir du menu démarrer.
10.3.3 Installateur Windows

Le choix de s'arrêter ici aurait pu être fait. En eet l'utilisateur dispose d'un chier d'ins-
tallation à utiliser sur le PDA pour installer FauneTracker.
Figure 10.2 Création du chier d'installation CAB.

Application
Exécutable
(.EXE) Fichier de
Géneration déploiement
du fichier .CAB
Cache de cartes
DLL
ArcGIS
Instruction FauneTracker.cab
d’installations,
raccourcis, etc.
Cependant il doit tout de même eectuer certaines manipulations qui ne lui sont pas
forcément familières : transférer le chier CAB sur le PDA, naviguer sur le PDA pour retrouver
celui-ci et enn l'exécuter. De plus, l'utilisateur doit eectuer les mêmes opérations pour un
autre CAB fournis par ArcGIS et contenant les librairies du SDK d'ArcGIS Mobile permettant
d'exécuter un programme réalisé à l'aide de celui-ci.
C'est pourquoi il a été décidé d'aller encore plus loin, en proposant à l'utilisateur un
installateur Windows. Ce dernier s'occupe de notier le gestionnaire d'applications mobiles,
des chiers CAB à transférer sur le PDA. Dès la connexion de celui-ci (il n'est pas nécessaire
de le connecter pendant l'exécution de l'installateur Windows), le gestionnaire d'applications
lancera automatiquement le transfert des diérents chiers CAB à destination du PDA, puis
les exécutera sur celui-ci. La seule action nécessaire de l'utilisateur nal sera donc d'exécuter
l'installateur Windows, ce qui ne devrait pas lui poser de problème.
La première étape consiste à créer un chier de conguration INI, dont le chemin sera
envoyé en paramètre au gestionnaire d'applications mobiles. Ce chier indique au gestionnaire
d'application les noms des chiers CAB à installer sur le périphérique. Voici son code :
[ CEAppManager ]
Version = 1.0
// Indique le nom du composant à installer .

Component = FauneTracker
5
// Composant
[ FauneTracker ]
Description = Faune Tracker pour PDA
// Fichiers CAB à déployer , dans l ' ordre d ' installation .

10 CabFiles = AGMRuntime . CAB, S e tu p F au n eT r a ck e r PD A . CAB
Listing 10.1 Code du chier de conguration ini.

Un composant pour l'installateur est ensuite créé. Celui-ci permet de personnaliser l'ins-
tallateur en le programmant an d'eectuer des actions spéciales. Voici le code de la méthode
la plus importante de celui-ci. Cette méthode permet de lancer le gestionnaire d'applications
Windows CE en lui précisant le chemin du chier INI préalablement conçu.
// / Lance le gestionnaire d ' applications Windows CE ,
// / avec le fichier de configuration ini .
private void runAppManager ( s t r i n g arg )
5 // Récupération du chemin ou ActiveSync est installé ,

// à partir de la base de registres
RegistryKey keyActiveSync = R e g i s t r y . L o c a l M a c h i n e . OpenSubKey (CEAPPMGR_PATH) ;
string appManager = ( s t r i n g ) k e y A c t i v e S y n c . GetValue ( " " ) ;
10 if ( appManager != null )
// Lance le gestionnaire
Process . Start (
s t r i n g . Format ( " \ " { 0 } \ " " , appManager ) ,
15 ( arg == null ) ? "" : s t r i n g . Format ( " \ " { 0 } \ " " , arg ) ) ;
else
// Si on ne trouve pas le gestionnaire => une exception est levée .

20 throw new Exception ( " Impossible de lancer le gestionnaire d ' applications "
+ " de Windows CE . \ n Vérifiez l ' installation d ' ActiveSync . " ) ;
Listing 10.2 Lancement du gestionnaire d'applications Windows Mobile.

Finalement, un installateur Windows est créé. Celui-ci contient les références des diérents
chiers CAB, le chier de conguration INI ainsi qu'un appel vers le composant d'installation
personnalisé. L'utilisateur nal dispose donc, à présent, d'un installateur au format MSI qu'il
lui sura d'exécuter sur son PC de bureau, pour installer l'application sur le PDA. Le schéma
10.3 illustre le fonctionnement de l'installateur.
Figure 10.3 Fonctionnement de l'installateur Windows.

Composant
Composé de
Fichiers CAB Setup.ini d’installation
Installateur MSI
Utilise
Appelle
Gestionnaire
d’applications Fichiers CAB
Installe
Utilisateur final Windows CE
Chapitre 11
Conclusion
Ce travail de diplôme a premièrement consisté en l'étude des diérents moyens de mettre
en ÷uvre une application de recensement de la faune sur un terminal mobile. Il a ensuite fallu
choisir parmi ceux-ci le moyen le plus adapté, par rapport au cahier des charges et au temps
de développement qu'il nécessitait. Finalement, un prototype de l'application FauneTracker,
permettant de répondre à toutes les questions que soulevait le cahier des charges a du être
réalisé.
Dans un premier temps, nous avons choisi d'étudier s'il existe un moyen de résoudre cette
problématique, à l'aide de technologies libres. L'examen des normes SVG, SVG Tiny et SVG
Mobile qui permettent d'orir un rendu graphique a dont été eectué. Ces normes doivent
être utilisées au sein d'un langage hôte, avec lequel l'application est elle-même développée.
C'est pourquoi nous avons envisagé de programmer le logiciel pour le PDA en Java, qui
est à présent aussi une technologie libre. Malheureusement, nous avons vite été confronté à
plusieurs problèmes. Les diérentes machines virtuelles Java testées, sourent de latences très
élevées et inacceptables pour l'utilisateur, dès que le programme devient un tant sois peu
conséquent. Ces machines virtuelles ne sont de surcroit, pas certiées par l'éditeur de Java
(SUN) et comportent de multiples bogues . Finalement, les bibliothèques SVG pour Java
qui ont été testées n'implémentent pas correctement le support de cette norme. L'utilisation
du C# comme langage hôte a ensuite été envisagée, mais nous nous sommes aussi heurtés au
problème de l'inexistence de bibliothèques SVG appropriées.
Nous avons ensuite étudié les technologies proposées par le concepteur de logiciels ESRI.
Ces produits ne sont pas libres, toutefois la grande majorité des cantons suisses dont Genève,
possèdent une licence pour ceux-ci, ce qui nous a permis d'envisager une implémentation
de FauneTracker avec leur aide. Après une étude détaillée des produits ArcPad et ArcPad
Application Builder, nous avons constaté que si ceux-ci permettent de répondre d'un point de
vue technique au cahier des charges, ils ne permettent pas d'orir à l'utilisateur une interface
homme-machine possédant la simplicité requise. C'est pourquoi nous nous sommes penchés
sur le SDK ArcGIS Mobile pour la technologie .NET. Ce produit fait partie d'ArcGIS Server
et fournit de nombreux outils permettant de développer une application interagissant avec
des données géographiques. Après une phase de tests, il s'est avéré que ce SDK répondait
parfaitement à nos besoins.
63
CHAPITRE 11. CONCLUSION 64
Puisque l'implémentation en SVG n'était pas faisable et que ArcPad ne permettait pas
d'obtenir une interface répondant de manière optimale au cahier des charges, nous avons choisi
d'implémenter le projet à l'aide du SDK ArcGIS Mobile, même si celui-ci demande un temps
de développement plus conséquent qu'ArcPad. La première étape de cette implémentation a
commencé par l'installation logicielle et réseau de diérents serveurs et clients, dans le but
de posséder un environnement semblable à celui qui serait utilisé en production. Nous avons
ensuite créé la base de données nécessaire à l'application. Le développement de la suite de
logiciels FauneTracker a nalement pu commencer. Cette suite est constituée de trois appli-
cations :
1. FauneTracker - PDA, dont la vocation est de fournir aux gardes-faune un moyen de
saisir leurs observations faunistiques sur un PDA. Pour cela, cette application permet
de naviguer et de se positionner sur une carte via un module GPS, d'eectuer des
requêtes pour consulter d'anciennes observations et d'eectuer une synchronisation avec
un serveur, à travers une connexion internet. Tout ceci en mettant un accent particulier
sur la réalisation d'une interface homme-machine très simple, an que l'application puisse
être utilisée sur le terrain et qu'elle laisse le moins de place possible à des erreurs de
saisies.
2. FauneTracker - Conguration ore la possibilité à un responsable de service de dé-
nir la mission de ses gardes-faune et de personnaliser les éléments des menus qui seront
achés dans FauneTracker - PDA. Ce logiciel permet, de plus, d'éditer les éléments
contenus dans la base de données.
3. FauneTracker - Desktop permet à tout utilisateur de consulter depuis un poste de
bureaux les observations saisies par les gardes-faune. Ce programme permet aussi aux
gardes-faune et responsables de service disposant de privilèges, d'éditer les saisies eec-
tuées selon une certaine politique de gestion des droits.
Ce travail de diplôme a permis de remplir tous les points du cahier des charges. Il est
même allé plus loin, dans la mesure où l'application développée, qui devait rester au stade de
prototype, est complète et comporte des fonctions qui n'étaient initialement pas demandées.
Dès lors, nous pouvons considérer que le travail a été achevé avec succès.
Il faut de plus noter que le projet a été suivi par les collaborateurs de l'École d'ingénieurs
de Lullier qui souhaitent dans le futur mettre ce logiciel à la disposition des gardes-faune.
Après avoir permis de cibler les besoins des gardes, ces personnes ont pu intervenir plusieurs
fois lors du développement et émettre des critiques constructives an d'orienter celui-ci ou de
remettre en cause le fonctionnement de certains outils. Elles ont aussi proposé, au fur et à
mesure, diverses nouvelles fonctionnalités. C'est pourquoi le projet répond de façon optimale
à leurs besoins. Bien entendu, comme les mandants du projets ne sont pas eux-mêmes gardes-
faune et qu'il n'a pas été possible de rencontrer ceux-ci, certaines fonctions peuvent ne pas être
tout à fait adaptées à leurs besoins pratiques. Cependant, dans le souci d'orir la possibilité
de développer une application nale, les classes des applications ont été organisées de façons à
ce que l'adjonction de nouvelles fonctionnalités ou la rectication de certains comportements
du programme puissent être réalisés facilement. Ceci a pu être réalisé grâce à l'utilisation de
plusieurs motifs de conceptions (design patterns ). De plus, de multiples exemples de codes
représentants les fonctionnalités clés du projet ont été expliqués, détaillés et commentés au
sein de ce mémoire.
Bibliographie
[DEB07] Laurent DEBRAUWER. Design Patterns, les 23 modèles de conception. 2007.
[NEG+ 08] Nagel, Evjen, Glynn, Watson, and Skinner. Professional C# 2008. Wiley, 2008.
[WIK] Encyclopédie internet libre wikipedia. http://www.wikipedia.com.
65

Recensement de La Faune Avec PDA (.AXF D'arcpad

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Recensement de La Faune Avec PDA (.AXF D'arcpad

Uploaded by

Copyright:

Available Formats

Recensement de la faune à

l'aide d'un PDA

Mémoire de diplôme en informatique Aurélien Poscia

2 Capture des besoins 3

3 SVG et Java pour une plate-forme mobile 7

5 ArcPad et ArcPad Application Builder 17

8.7.2 Collecte des informations . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.1 Diagramme des cas d'utilisations de l'application. . . . . . . . . . . . . . . . . . 4

1.2 Organisation du mémoire

Capture des besoins

2.2 Identication des acteurs

Figure 2.1 Diagramme des cas d'utilisations de l'application.

FauneTracker – Configuration FauneTracker – Desktop

Choisir les données

2.2.4 Combinaisons des rôles

2.3 Entités de l'application

2.3.2 FauneTracker - Conguration

2.3.3 FauneTracker - Desktop

2.4 Données à saisir

SVG et Java pour une plate-forme

Matrice de pixels Description de formes

Figure 3.2 Dessin SVG, correspondant au code du listing 3.1.

ils sont organisés de façon hiérarchique.

<!DOCTYPE svg PUBLIC " −//W3C/ /DTD SVG 1 . 0 / /EN"

" h t t p : / /www . w3 . o r g /TR/ 2 0 0 1 /REC SVG − − 2 0 0 1 0 9 0 4 /DTD/ s v g 1 0 . d t d ">

5 <g i d=" g r o u p e _ c e r c l e s " s t y l e =" f i l l −o p a c i t y : 0 . 7 ; ">

stroke : black ; stroke −w i d t h : 0 . 1 cm" t r a n s f o r m=" t r a n s l a t e ( 0 , 5 0 ) " />

stroke : black ; stroke −w i d t h : 0 . 1 cm" t r a n s f o r m=" t r a n s l a t e ( − 7 0 , 1 5 0 ) "/>

stroke : black ; stroke −w i d t h : 0 . 1 cm" t r a n s f o r m=" t r a n s l a t e ( 7 0 , 1 5 0 ) " />

Listing 3.1  Exemple de code source SVG.

Figure 3.3 Empilement J2ME/J2SE.

J2SE Foundation MIDP Profil

CDC CLDC Configuration

3.3.2 Java 2 Micro Edition (J2ME)

3.3.3 Conguration J2ME

3.3.4 Prol J2ME

3.3.5 Connected Device Conguration(CDC)

3.3.6 Connected Limited Device Conguration (CLDC)

3.3.7 Mobile Information Device Prole (MIDP)

Figure 3.4 Exemple de ux pour un Midlet.

3.4 SVG sur PDA

forme J2SE ou J2ME pour s'exécuter.

3.5 SVG sur téléphone mobile

Figure 4.1 Gamme ArcGIS (source : ESRI).

ArcGIS Mobile possède de plus le grand avantage de pouvoir se synchroniser directement

ArcPad et ArcPad Application Builder

5.2 Fichier de conguration

Figure 5.1 Synchronisation des données depuis ArcPad jusqu'au serveur.

ArcPad ArcMap ArcCatalog ArcGIS Server

Figure 5.2 Conguration par défaut d'ArcPad (gauche) et personnalisée (droite).

À l'aide d'ArcPad Application Builder, la possibilité de congurer en détails les diérents

L'image 5.2 montre sur le PDA de droite, un exemple de conguration personnalisée et

<? xml v e r s i o n=" 1 . 0 " e n c o d i n g="UTF −8" ?>

<! -- Configuration de la barre d etat -->

u n i t s=" t r u e " />

<! -- Configuration des formulaires -->

<! -- Configuration des barres d outils -->

<! -- Barre d outils personnalisee 1 -->

v i s i b l e =" t r u e " >

<TOOLBUTTON command=" openmap " />

15 <TOOLBUTTON command=" modezoomin " />

<TOOLBUTTON command=" modezoomout " />

<TOOLBUTTON command=" modepan " />

2.2 Identication des acteurs

2.3.2 FauneTracker - Conguration

Listing 3.1 Exemple de code source SVG.

3.3.3 Conguration J2ME

3.3.4 Prol J2ME

3.3.5 Connected Device Conguration(CDC)

3.3.6 Connected Limited Device Conguration (CLDC)

3.3.7 Mobile Information Device Prole (MIDP)

Figure 3.4 Exemple de ux pour un Midlet.

5.2 Fichier de conguration

Figure 5.2 Conguration par défaut d'ArcPad (gauche) et personnalisée (droite).

À l'aide d'ArcPad Application Builder, la possibilité de congurer en détails les diérents

L'image 5.2 montre sur le PDA de droite, un exemple de conguration personnalisée et

Listing 5.1 Exemple de chier de conguration.

Listing 5.2 Création et exécution du ltre sur les animaux.

6.2.2 Conguration logicielle

Figure 7.1 Interface graphique de FauneTracker - Conguration.