Travail effectué

1. Cahier des charges

Pour différentes raisons, notamment d'ordre organisationnelles, il n'a pas été fourni de cahier des charges à proprement parler.

Le dossier des spécifications fonctionnelles détaillées a été écrit au fur et à mesure de l'apparition et/ou de la définition des besoins, tout au cours de l'étude. C'est la version finale — du moins à la date de l'écriture du rapport — qui figure plus loin dans ce document.

Au départ, le travail demandé était tout ce qu'il y a de plus flou, et pouvait se résumer par ces quelques points :

2. Compte-rendu d'activité

Si l'essentiel du travail a porté sur le développement du client embarqué sur le PDA, il ne faut pas négliger les étapes d'étude des techniques et possibilités de ces appareils, ainsi que l'adaptation nécessaire du serveur central de synchronisation. La maintenance de l'existant — à savoir, le client autonome pour PC — a par contre été relativement négligeable en terme de temps consommé.

Le détail de l'utilisation du temps durant le stage est présenté dans le chronogramme de la figure 4.

3. Spécifications fonctionnelles

3.1. Fonctionnalités du système

L'application est destinée à fournir aux commerciaux en visite en magasin le moyen d'accéder au système de reporting de l'entreprise de manière mobile afin de pouvoir générer les rapports de visite sur le site, puis de synchroniser ces informations avec le serveur central de l'entreprise.

Les fonctionnalités seront les suivantes :

3.1.1. Saisie des formulaires de visite

La saisie des rapports doit pouvoir se faire comme dans le client autonome sur PC, sans imposer d'ordre de rentrée des informations. Il ne doit pas être possible de rentrer un rapport incomplet.

3.1.1.1. Synchronisation des données

La synchronisation doit pouvoir se faire de la façon la plus transparente possible, depuis n'importe quel accès réseau. Elle doit permettre de propager les informations saisies au serveur central, et de redescendre depuis celui-ci des informations qui auraient été entrées par un autre moyen (console d'administration, rapports enregistrés directement sur l'interface Internet ...).

3.2. Contraintes de l'organisation sur le système et du système sur l'organisation

Le système devant s'intégrer au SFA, il doit tendre à s'approcher le plus possible — dans sa logique — du client autonome avec lequel travaillent actuellement les commerciaux.

De plus, il faut réduire au plus court les temps de chargement lors du remplissage des formulaires puisque cette opération peut être amenée à être effectuée sur le terrain.

Par contre, les limitations techniques des terminaux mobiles (faible mémoire, processeur relativement lent, petit écran) vont conduire à devoir repenser l'organisation des écrans et le volume de données traité à un instant t.

3.3. Solution technique choisie

Utilisation de la machine virtuelle superwaba, basée sur une redéfinition de java, optimisée pour une utilisation sur plate-forme mobile en faisant abstraction des APIs des différents matériels1.

Comme pour le client autonome sur PC, une base de données locale sera utilisée pour le stockage entre synchronisations. Celle-ci sera basée sur le PDBDriver embarqué dans superwaba.

3.4. Processus de l'application et cas d'utilisation

Deux états initiaux sont possibles : l'état jamais synchronisé, et l'état déjà synchronisé.

Cas d'utilisation
Figure 5 : Cas d'utilisation

3.4.1. État jamais synchronisé

Si l'application n'a jamais été synchronisée, la seule action possible est la synchronisation initiale, qui requiert l'authentification après du serveur central.

3.4.2. État déjà synchronisé

Si l'application a déjà été synchronisée, l'authentification locale permet l'accès aux différents modules :

3.5. Écrans et états d'utilisation

Il existe deux possibilités à l'initialisation du système : système neuf ou système déjà synchronisé.

3.5.1. Écran d'erreur

Dans le cas ou une défaillance aurait lieu à l'initialisation du programme (telle l'impossibilité de lire la clef de chiffrement), un écran d'erreur décrivant la défaillance et disposant d'un bouton « Quitter » sera affiché.

3.5.2. Système initial

Dans le cas d'un système initial, la seule possibilité offerte par l'application est le contact du serveur central afin de synchroniser l'utilisateur. Un seul écran sera donc disponible.

3.5.2.1. Écran de login et synchronisation

Cet écran proposera à l'utilisateur d'entrer son login et le mot de passe qui lui est associé dans deux boites de texte ; afin de pouvoir synchroniser les bases de données avec le serveur hôte.

Un bouton proposera de synchroniser avec la base centrale, et si celle-ci réussit, l'application sera réinitialisée en mode déjà synchronisé. Dans le cas contraire, l'utilisateur sera renvoyé à l'écran initial.

3.5.3. Système déjà synchronisé

Le système est considéré comme déjà synchronisé si au moins un profil utilisateur est défini en base locale — ce qui indique que le système a auparavant été synchronisé (voir 3.5.2 Système initial).

3.5.3.1. Écran de login

Cet écran proposera à l'utilisateur d'entrer son login et le mot de passe qui lui est associé dans deux boites de texte afin d'accéder au reste de l'application.

Si le login est reconnu, l'utilisateur sera envoyé vers l'écran principal, sinon, il sera renvoyé au début.

3.5.3.2. Écran principal

L'écran principal propose d'accéder aux différents modules, et offre un menu permettant d'effectuer diverses opérations :

Les modules prévus sont :

Seul ce dernier est absolument nécessaire.

3.5.3.3. Écran du module de gestion des formulaires

Cet écran permettra de choisir entre les trois types d'opérations possibles avec le module, et de choisir le formulaire auquel l'appliquer :

3.5.3.4. Écran de création de formulaire

Cet écran sera subdivisé en onglets, chacun regroupant un type d'information sur le formulaire. Chaque modèle de formulaire pourra — ou pas — afficher chacun des onglets. Les onglets seront les suivant :

On pourra passer de l'un à l'autre sans distinction d'ordre, et sans influencer la saisie. Il sera par contre nécessaire d'avoir rempli tous les champs obligatoires (c'est à dire tous les champs affichés, sauf pour la cas particulier de la liste des Produits à saisir, ou certains champs pourront être omis.

3.5.3.4.1 Informations relatives au magasin

L'onglet d'informations relatives au magasin comportera deux champs obligatoires, et deux champs facultatifs dont l'affichage est conditionné par le modèle de formulaire. S'ils sont présents, leur remplissage est obligatoire.

Les champs toujours présents sont :

Les champs conditionnels — indépendants l'un par rapport à l'autre — sont :

3.5.3.4.2. Liste des priorités

Cet onglet proposera une liste contenant les priorités associées au type de magasin visité. Chacune de ces priorités est définie par une phrase, et un champ de texte permettra d'y répondre. Au besoin, une barre de défilement sera utilisée.

3.5.3.4.3. Action menées et à mener

Cet onglet proposera deux choses :

3.5.3.4.4. Visibilité des marques et des produits

Cet onglet proposera quatre listes de choix, pour définir, respectivement :

3.5.3.4.5. Produits à saisir

Cet onglet donnera accès, dans un premier temps, à la liste des gammes de produits disponible dans le magasin. Une fois une gamme sélectionnée, la liste sera remplacée par une grille permettant le remplissage des champs définis par le modèle de formulaire pour tous les produits de la gamme sélectionnée disponibles pour le magasin.

La première colonne contiendra le nom du produit, et un clic sur celle-ci affichera dans une fenêtre jaillissante les autres informations disponible (référence, prix indicatif ...),

les autres colonnes contiendront les valeurs entrées pour les champs associés à ces produits. Un clic sur cette valeur affichera l'éditeur associé au type de champs sous la grille, pour permettre sa modification.

3.5.3.4.6. Récapitulatif de fin de visite

Cet onglet permettra d'entrer la durée de la visite, ainsi qu'un commentaire libre.

Il proposera aussi le bouton de validation du formulaire, qui procédera à la vérification des champs (remplissage de tous les champs nécessaires, validité des informations rentrées ...) puis, si tout est correct, à la mise en base locale du nouveau formulaire.

3.6. Profils et droits utilisateurs

Une partie des profils utilisateurs seront stockés sur le pda, avec les données qui lui sont associées. Celles-ci, ainsi que les droits associés aux utilisateurs sont définis par la base centrale, et non exportés sur le pda.

3.7. Éléments permettant l'utilisation du système

Le système nécessite pour son utilisation un dispositif mobile (pda) sur lequel s'exécuter, la présence de la machine virtuelle superwaba dédiée au dispositif pour exécuter le programme en lui-même, ainsi que d'une connexion pour permettre la synchronisation des données.

Cette synchronisation se fera par le biais d'une connexion HTTP au serveur central, ce qui requerra une connexion à Internet, soit directement (via bluetooth, ou la base d'un PocketPC, et un PC disposant d'un accès à Internet, par exemple), soit par le biais d'un programme faisant le relais entre le pda et le réseau, via sur le port série.

3.8. Éléments permettant l'administration du système

Le système est destiné à se greffer à l'outil sfa actuel, et sera donc administré indirectement par les outils d'administration du sfa.

Des tâches administratives supplémentaires pourront être nécessaires, telle la mise à jour des clefs de chiffrement des communications, qu'il pourrait être prudent de changer de temps à autre3.

3.9. Éléments de sécurisation du système

Le système devant fonctionner sur un dispositif mobile — et par conséquent plus facilement sujet au vol ou à la perte — il faudrait au maximum limiter les données sensibles stockées localement.

La seule solution sûre serait le cryptage à la volée des informations stockées, mais cette solution est inapplicable, à moins de dégrader les performances de manière inacceptable.

La synchronisation ne doit se faire qu'après validation de l'identifiant et du mot de passe par le serveur central, et non par rapport à la base locale, corruptible plus facilement.

Les mots de passes doivent être hachés, de façon non réversible, dans la base locale, et le mot de passe entré en clair haché à son tour pour être comparé.

Les données échangées entre le client et le serveur seront cryptées. En raison des contraintes dues au matériel (faible puissance de calcul, entre autres) le cryptage asymétrique — basé sur des opération arithmétiques complexes — n'est pas utilisable, en conséquence de quoi nous utiliserons un algorithme symétrique. L'algorithme retenu est TEA4, dans sa version corrigée (dite XTEA) par David Wagner5.

La clef sera stockée sur le serveur et sur les clients, et jamais échangée via le réseau, elle sera contenue dans un fichier indépendant pour pouvoir être facilement changée.

4. Déroulement concret des études

4.1. Étude détaillée

4.1.1. Technologie

Les premières semaines de l'étude ont consisté en un travail de recherche des différentes technologies disponibles sur les plates-formes visées, ainsi que des outils disponibles pour le développement, déploiement et le maintien.

La préférence allant vers une plate-forme Java, plusieurs environnements ont été envisagés, parmi lesquels :

Les études les plus poussées ont été menées sur les machines virtuelles J2ME et Superwaba.

4.1.1.1. J2ME

J2ME (Java 2 Micro Edition) est le framework Java spécialisé dans les applications mobiles. Des plate-formes Java compatibles avec J2ME sont embarquées dans de nombreux téléphones portables et PDA.

Une plate-forme J2ME est composée de plusieurs éléments :

Les configurations les plus courantes sont :

Les profils les plus courants sont :

4.1.1.1.1. Avantages

Le principal avantage de cette machine virtuelle est sa large répartition. C'est en effet la machine virtuelle java « officielle » pour les appareils mobiles. Elle est donc abondamment traitée, que ce soit sur Internet ou dans divers ouvrages.

De plus, elle est supportée par Sun Microsystems, et utilise les mêmes API que la machine virtuelle java standard (J2SE).

4.1.1.1.2. Inconvénients

Le principal inconvénient vient justement de la modularité de cet environnement : l'application devant pouvoir tourner à la fois sur Palm et sur PocketPC. En effet, les « configurations » sont différentes entre ces deux architectures, pas toujours uniformes pour deux matériels de la même catégorie. La configuration des Palm étant largement plus limitée que celle disponible pour PocketPC.

Cette différence empêche de produire du code identique pour les deux gammes, ce qui entrait en contradiction avec un des — rares — pré requis du cahier des charges.

4.1.1.2. Superwaba

Superwaba est une plate-forme de développement open-source pour PDA et « smartphones ». Le kit de développement logiciel Superwaba (SWSDK) contient les différents composants suivants :

Le projet Superwaba a été créé au début de l'année 2000 par Guilherme Campos Hazan, et dérive d'un autre projet open-source — moins évolué — appelé Waba7.

Superwaba est conçu comme une redéfinition d'une partie de Java, mais sans en implémenter aucune partie. Cela permet d'utiliser les éditeurs et outils de développements Java classiques, sans être en relation avec Sun Microsystems, le propriétaire de la marque Java, et celles qui lui sont associées.

4.1.1.2.1. Avantages

Superwaba permet une (presque) totale portabilité des programmes, en implémentant les mêmes API sur Palm et PocketPC (ainsi que les smartphones, même s'ils n'entrent pas en compte dans la définition des besoins).

Sa diffusion en open-source (distribuée sous licence GNU/LGPL8) permet la modification, l'adaptation, et la correction des parties du logiciel le nécessitant.

L'API graphique simple permet de construire des interfaces homme-machine rapides et adaptables à la taille de l'écran.

Le fait que ce soit un projet emmené par une communauté permet aussi un accès direct et rapide à l'information via les développeurs et la communauté qui gravite autour.

4.1.1.2.2. Inconvénients

La petite taille de l'équipe de développement implique une relative lenteur du développement, même si le projet est à l'heure actuelle utilisable en production.

Même si le code généré est du même type que le code Java standard, les API sont incompatibles, et la machine virtuelle Superwaba doit donc obligatoirement être installée sur les machines de destination pour permettre l'exécution des applications.

4.1.1.3. Conclusion

Le choix s'est finalement porté sur Superwaba, en raison de la grande portabilité, qui ne sacrifie pas pour autant les fonctionnalités. Le moteur de base de données locale PDBDriver faisait aussi partie des points qui ont poussé le choix dans cette direction.

4.1.2. Moteur de base de données

Pour pouvoir fonctionner en mode déconnecté, l'application nécessite de disposer d'une partie de la base de donnée en local sur l'appareil. Trois moteurs de base de données embarquée sur PDA ont été testés :

4.1.2.1. IBM DB2e

DB2e (pour DB2 Everyplace), est la solution de base de données mobile d'IBM. Conçue pour faciliter la synchronisation avec la base de données DB2 du même éditeur, le moteur consomme 200 à 300 ko de mémoire sur le PDA.

Les fonctions supportées sont néanmoins plus que respectables :

Le mécanisme de synchronisation étant déjà en place, cette fonction était inutile pour l'application étudiée. Le prix des licences et les bogues du driver DB2e inclus dans Superwaba — dont l'utilisation était fortement pressentie au moment de l'étude — ont conduit à abandonner ce moteur.

4.1.2.2. Oracle Lite

Oracle Database Lite 10g est une solution intégrée de déploiement de base de données sur des client mobiles et non connectés. Tout comme DB2e, elle offre un système de synchronisation avec la base centrale, Oracle Database Entreprise 10g.

Pour la même raison que précédemment, cette fonction était inutile — et même contre-indiquée. De plus, seul un driver J2ME était disponible, ce qui aurait exclu toute utilisation avec Superwaba.

4.1.2.3. PDBDriver

PDBDriver est la solution de base de donnée embarquée proposée par Superwaba. Proposée dans le SDK « professionnel » de l'environnement de développement, elle est supportée par la même équipe, et complètement intégrée.

Le moteur est distribué sous forme de librairie native pour améliorer les performances par rapport à un code entièrement en java, avec un pont pour l'utiliser depuis la machine virtuelle.

Ses fonctions sont réduite par rapport à un moteur relationnel classique :

Néanmoins, sa parfaite intégration et sa simplicité étaient des arguments de poids en sa faveur.

4.1.3. Conclusion

Il a donc été choisi d'utiliser la plate-forme superwaba, associée au moteur de base de données qui lui est dédié : le PDBDriver.

Les points suivant ont été déterminants dans le choix :

4.2. Réalisation

La réalisation du projet a proprement parler — étude préalable et recette exclue — peut être divisée en trois grandes parties :

L'annexe II présente le diagramme des classes développées pour l'application.

4.2.1. Communications

La communication entre les clients et le serveur de synchronisation s'effectuent à deux occasions :

Il existe deux moyens de contacter le serveur :

Toutes les connexions passent à travers une couche de chiffrement xTEA.

4.2.1.1. Synchronisation initiale

La synchronisation initiale est le procédé qui permet de mettre en place la base de données locale. Le client se connecte au serveur, envoyant la chaîne d'authentification chiffrée. Si celle-ci est correcte, le serveur renvoie un flux XML — toujours chiffré — décrivant la structure des tables de la base de données, ainsi que certaines données qui doivent y être stockées.

Un exemple de ce flux est présenté en Figure 6.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sync SYSTEM "sync.dtd"> 
<hf> 
  <create>
    <table name="utilisateur">
      <value name="id" type="int" attr="primary key"/>
      <value name="nom" type="char(30)"/>
      <value name="pass" type="char(32)"/>
    </table>
  </create>
  <insert>
    <table name="utilisateur">
      <value>42</value>
      <value>'Bastien'</value>
      <value>'f71dbe52628a3f83a77ab494817525c6'</value>
    </table>
  </insert>
  <create>
   <table name="caracteristique_pdt">
     <value name="id" type="int" attr="primary key"/>
     <value name="libelle" type="char(50)"/>
   </table>
 </create>
</hf>
Figure 6 : Exemple de flux XML de synchronisation initiale.

4.2.1.2. Synchronisation des données

La synchronisation des données est beaucoup plus complexe, car il faut à la fois envoyer sur le serveur les nouvelles informations entrées par l'utilisateur, et prendre en compte les modifications qui ont été faites sur celui-ci pour les redescendre sur le PDA. En effet, un utilisateur peut entrer des informations via d'autres moyens (client autonome sur PC, interface web) entre deux synchronisation.

La solution utilisée dans le client autonome était d'envoyer toutes les nouveautés et les modifications au serveur, puis de vider les bases et de télécharger à nouveau l'intégralité de celle-ci. Cette solution implique le transfert et le traitement d'un important volume de données — on parle ici en dizaines de méga-octets — ce qui est peu compatible avec l'utilisation d'un PDA, dont la connexion peut être lente, voire instable, et dont le mémoire et les capacités de traitement sont faibles.

Cela permettait, entre autre, de ne pas avoir à traiter les modifications des identifiants sur les nouveaux enregistrements. En effet, lorsqu'on crée un enregistrement, il est impossible de prédire quel identifiant lui sera attribué par la base de données centrale lors de la synchronisation ; donc l'identifiant utilisé est temporaire, et sera mis à jour — ainsi que toutes les références à celui-ci — lors de la synchronisation.

Le procédé a donc été modifié, et peut être décrit en 8 étapes, du coté du client :

Tous les fichiers sont en format XML, et transitent de manière chiffrée ; les opérations étant authentifiées à l'aide de la chaîne d'authentification. La Figure 7 présente un exemple de liste d'enregistrements, la Figure 8 un exemple de fichier d'insertions, tandis que la Figure 9 présente un fichier de mise à jour.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<database>
  <rayon id="1">
    <nom>Multimédia</nom>
  </rayon>
</database>
Figure 7 : Exemple de liste d'enregistrements

<?xml version="1.0" encoding="ISO-8859-1" ?>
<database>
  <listdone id="13">
    <nom>Formation</nom>
    <todolist_id>0</todolist_id>
    <formulaire_id>5</formulaire_id>
  </listdone>
</database>
Figure 8 : Exemple de fichier d'insertions

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sync SYSTEM "sync.dtd">
<hf>
  <table name="client">
    <value>1</value>
  </table>
  <table name="rendez_vous">
    <value>33</value>
    <value>34</value>
    <value>35</value>
    <value>16226</value>
  </table>
</hf>
Figure 9 : Exemple de fichier de mise à jour

4.2.1.3. Proxy série-TCP/IP

Le proxy série-TCP/IP est un programme qui écoute le port série spécifié par l'utilisateur (COM1 par défaut). Les demandes de connexions sont relayées par des messages à travers la liaison série, puis la socket Série se comporte comme une socket réseau classique. Les informations transitant par le câble sont directement relayées à l'hôte auquel le proxy est connecté, et ses réponses relayées au client telles quelles. La Figure 10 présente l'interface de ce logiciel.

Interface du proxy Série-TCP/IP
Figure 10 : Interface du proxy Série-TCP/IP

4.2.1.4. Chiffrement

Les transmissions, que ce soit les transferts de fichiers ou les authentifications, sont chiffrées à l'aide de l'algorithme xTEA. Un filtre de chiffrement a été écrit, qui s'intercale entre l'application et la socket réseau.

4.2.2. Interface

Grâce à l'API graphique de superwaba, l'interface s'adapte sans problème à la taille de l'écran et au système d'exploitation. Par exemple, la Figure 11 présente l'écran d'identification dans l'émulateur Palm, tandis que la Figure 12 présente le même écran (mais en mode non encore synchronisé, voir les points 3.5.2 et 3.5.3 du dossier des spécifications fonctionnelles) dans l'émulateur Pocket PC. La Figure 13 présente l'écran principal lors d'une synchronisation.

Écran d'identification sous Palm OS
Figure 11 : Écran d'identification sous Palm OS

Écran d'identification sous Pocket PC
Figure 12 : Écran d'identification sous Pocket PC

Synchronisation sous Palm OS
Figure 13 : Synchronisation sous Palm OS

Deux contrôles supplémentaires ont été écrits : le calendrier présent sur la Figure 14, dans l'écran de saisies des informations magasin d'un formulaire, et la grille de présentation de données éditables, utilisée dans la Figure 15 pour la saisie des produits du formulaire, et des champs qui lui sont associés.

Écran de saisie des informations magasin
Figure 14 : Écran de saisie des informations magasin

Écran de saisie des produits
Figure 15 : Écran de saisie des produits

4.2.3. Serveur de synchronisation

En raison des ajouts, et des modifications du processus de synchronisation, il a fallu apporter des modifications au serveur de synchronisation :

La modification du processus de synchronisation implique les changements suivants :

4.3. Recette

La phase de recette est en cours à l'heure de la rédaction de ce document. Un faible nombre de bogues ont été détectées, et quelques modifications cosmétiques effectuées.

Les dernières semaines de travail devraient conduire à la validation de l'application en vue de sa mise en production, et à la rédaction des spécifications techniques détaillées.

5. Interprétation et critique des résultats

5.1. Maintien de l'existant

Si quelques bogues ont été corrigés dans le client autonome sur PC en début de mission, les résultats sont plutôt maigres à ce sujet. L'étude a surtout permis l'analyse du processus de synchronisation, afin de le reproduire en l'améliorant.

5.2. Client embarqué

Le logiciel a été développé conformément au dossier des spécifications fonctionnelles, lui même écrit au fur et à mesure de l'avancement de la mission.

Cette démarche n'est pas très pertinente du point de vue du contrôle, mais a été imposée par des contraintes humaines, et non pour des raisons techniques.

L'application remplis néanmoins les besoins tels qu'ils ont été grossièrement définis au début de la mission, qu'on peut donc estimer remplie. Seule la validation et la mise en production reste à effectuer à l'heure qu'il est.

Notes :

1 Voir l'étude détaillée pour plus de détails.
2 Une fenêtre pop-up contenant un nouvel écran de saisie
3 Au minimum en cas de disparition d'un des pda
4 Tiny Encryption Algorithm, cf. l'annexe I : Systèmes de cryptage.
5 cf. http://www.cs.berkeley.edu/~daw/
6 Peut être traduit par : « Écrivez-le une fois, faites-le tourner partout. »
7 cf. http://www.wabasoft.com
8 cf. http://www.gnu.org/licences/lgpl
9 cf. http://mcrypt.sourceforge.net