Modifications logicielles apportées à l’infrastructure 117 

Plusieurs ajouts logiciels ont été apportés à notre infrastructure pour relayer les requêtes de l’utilisateur aux deux appareils multifonctions retenus mais aussi pour collecter les données nécessaires à l’évaluation des interfaces proposées et des algorithmes utilisés (cf. section 5.5.4).

Conception logicielle des adaptateurs

Suite à l’introduction, du côté des appareils multifonctions, d’adaptateurs capables de recevoir les commandes de l’utilisateur mais aussi de répondre à ses requêtes, le premier ajout logiciel apporté à notre infrastructure fut la conception des deux modules requis, du côté des ordinateurs de contrôle, pour 1) assurer une communication bidirectionnelle avec notre plateforme et pour 2) contrôler les machines représentées. Comme les autres modules présentés au chapitre 4, ces deux modules, dont les fonctions sont décrites ci- dessous et le rôle est résumé à la Figure 5.9, furent programmés en langage C/C++.

Module de communication : sur le plan des échanges d’informations, un module de communication fut introduit à la frontière des adaptateurs. Ce module acquit différentes fonctionnalités réseaux en se basant sur les librairies Winsock de Microsoft Visual Studio (connexion sur sockets, assemblage, transmission et réception de messages sur réseau TCP/IP). Il fut, entre autres, chargé d’accepter toute demande de connexion de la part de notre plateforme et de répondre à ses requêtes, notamment lors de la phase d’initialisation (identification de la classe d’appartenance de l’appareil représenté, de ses

capacités et de la description géométrique de son interface matérielle). Pour supporter ce rôle, une description des fonctionnalités de chaque appareil fut mise au point, sous forme d’une énumération de variables (cf. Tableau 5.4), pouvant être restreinte à différents types et à différents intervalles ou ensembles, tout en prenant soin de ne pas suggérer ou imposer, dans ce format, une quelconque présentation de cette information (ex. : utilisation d’une description numéraire de la qualité d’impression au lieu d’une description textuelle, qui imposerait un certain formatage au niveau de l’interface virtuelle). Cette liste fut mémorisée par chaque adaptateur et transmise à la plateforme lors de l’établissement d’une connexion, pour que notre moteur puisse prendre conscience des limitations d’un appareil lors de l’initialisation d’une interface. Parallèlement à la transmission de cette liste, le module de communication fut aussi chargé de transférer, du côté client, une description géométrique de l’interface matérielle de l’appareil représenté, sous forme d’une énumération de points clés (cf. section 4.2.1), afin que le module SIFT de détection, situé du côté de la plateforme, puisse localiser cette interface, pour la remplacer par une autre, mieux adaptée à l’utilisateur. Une fois la connexion établie et cette phase d’initialisation complétée, ce même module fut chargé d’acheminer les instructions de l’utilisateur au module de contrôle, décrit ci-dessous, et de relayer à la plateforme toute réponse de la part de ce dernier (ex. : passage de l’appareil d’un état occupé à un état prêt, après avoir effectué une copie).

Tableau 5.4 : Extrait du fichier de description des capacités du Canon Pixma MP750 Variable:  Variable:  Variable:  Variable:  Variable:  Variable:  Variable:  STATES  ZOOM  IMAGEQUALITY  EXPOSURE  COLLATE  2ON1  NBOFCOPIES { SCAN, COPY, PHOTO }  [ 25; 400 ]  [ 1; 3 ]  [ 1; 9 ]  TRUE  TRUE  [ 0; 99 ] 

Module de contrôle : ce module, hébergé du côté de nos adaptateurs, fut couplé à chacun des appareils multifonctions en recourant à leurs pilotes propriétaires, à l’interface de programmation TWAIN [83] et au pilote shimgvw.dll, responsable de l’affichage des images sous Microsoft Windows. Suite au recensement des différentes capacités supportées par chaque appareil, nous fûmes en mesure de bâtir une table de correspondances traduisant les requêtes de l’utilisateur, reçues sur le réseau sans-fil, en commandes TWAIN. Cette table, initialement localisée du côté de l’utilisateur telle que présentée à la section 4.4.1, fut transférée au module de contrôle, afin d’alléger la plateforme. Une telle migration permit à la fois de standardiser les requêtes transmises par le module de communication situé du côté de l’utilisateur, en l’empêchant de s’abaisser au niveau des appareils contrôlés, et de confier à chaque appareil la mémorisation de sa propre table, afin d’être en mesure, ultérieurement, de modifier ses capacités et ses modes de communications internes sans impact extérieur. En guise de résumé, la Figure 5.8 illustre le flot d’informations à l’intérieur de ce module et montre la traduction des requêtes de l’utilisateur et leur relais, par port USB, à l’appareil connecté, afin de mettre à jour ses paramètres (ex. : assombrissement et qualité de la

numérisation), pour ultimement lancer la numérisation et l’impression du document placé sur la glace, lors de la réception d’une commande de copie.

Modifications apportées au module de communication de la plateforme

Le module de communication client, situé du côté de la plateforme, fut bâti par-dessus l’ancien module de communication présenté à la section 4.4.1. Comme sa contrepartie située du côté des adaptateurs, il hérita des mêmes fonctionnalités réseaux que celles décrites plus haut et fut chargé :

1. de l’initiation des communications, sur un port dédié du réseau sans-fil ad-hoc établi entre la plateforme et l’adaptateur;

2. de l’obtention de la classe d’appartenance de l’appareil représenté, de ses capacités (ex. : agrandissement supporté, capacité à imprimer en couleurs, etc.) et de la description géométrique de l’interface matérielle à remplacer, reçue sous forme de points clés;

3. du relais, à l’interne, des informations obtenues afin d’initialiser le module SIFT de détection (cf. section 4.2.1), le module de présentation des interfaces personnalisées (cf. section 4.3.2) et la machine à états (cf. section 4.3.3), en tenant compte des limitations de l’appareil et des préférences de l’utilisateur; 4. de l’initialisation de l’état de base de l’appareil, communiquée sur le réseau sans-

fil, en fonction des préférences de l’utilisateur face à cette classe de machines; 5. et finalement, de la transmission des instructions de l’utilisateur, sous forme de

demandes continues de mises à jour des variables obtenues au point 2 et mémorisées par la machine à états du côté de la plateforme.

Figure 5.9 : Schématisation des modules ajoutés ou modifiés, ainsi que de leurs rôles et interactions, pour supporter les interfaces virtuelles testées

Recueil de traces durant les tests utilisateurs

Mentionnons finalement, sur le plan des ajouts logiciels, qu’une classe d'enregistrement fut intégrée à notre machine à états, afin de conserver sur fichiers une trace des séquences d'interactions entre les utilisateurs et les interfaces testées. Bien que

l'affichage de notre plateforme fut dupliqué sur un écran de contrôle sur les lieux, comme expliqué plus tôt, la sauvegarde des boutons utilisés et des marques temporelles nous semblait essentielle à une interprétation exhaustive des interfaces virtuelles proposées et à la comparaison post-expérience des résultats, notamment en ce qui a trait aux nombres d'erreurs commises, aux temps pour récupérer de ces erreurs et à l’étude des chemins pris. Notons aussi qu’une classe d'enregistrement similaire fut utilisée durant les expériences au niveau de la couche de détection, pour collecter plusieurs mesures techniques touchant à notre implémentation, afin d’évaluer la robustesse et les performances de nos algorithmes en situation réelle. Parmi celles-ci, mentionnons le recensement des pertes des interfaces identifiées par nos modules de détection et de suivi ainsi que le nombre de trames affichées par seconde (fps), témoin de la fluidité de notre affichage.