Le prototype du distributed Service Manager (dsm)

Le prototype du distributed Service Manager (dsm) a été développé pour prouver la faisabilité du modèle défini dans le chapitre 6, et réaliser des tests de per141 Prototype et expérimentations formance et d’utilisabilité. Le système central (dsm core), une interface utilisateur (ui), une interface de programmation (api) et enfin deux applications de test ont en tout été développés et publiés sous forme de projet open source lgpl sur le site Launchpad [90] (le projet s’appelle dsm, nom de code « Chameleon » rapport à sa propriété d’adaptation). Le projet est entièrement écrit en Java et organisé en trois parties de la manière suivante. – Un système central. Les principaux mécanismes du dsm font partie du système central (core) qui gère entre autres le pse, le réseau overlay sous-jacent (découverte, communication et transferts de données entre terminaux via un protocole pair-à-pair implémenté par la bibliothèque Java jxta [91][92]), les capacités du terminal, les services, les ressources ainsi que les messages entrant et sortant. – Une interface utilisateur. Une interface graphique minimale (gui) qui permet à l’utilisateur d’interagir avec le système et qui peut (et devrait) être remplacée par une interface tierce plus évoluée grâce aux évènements générés par le core. À noter qu’une console est également disponible. – Une interface de programmation. Cette api est essentielle, intégrée aux applications elle leur permet d’interagir avec le dsm, facilitant considérablement le travail des développeurs de solutions compatibles. En plus de ces trois grands axes de développement, deux applications tierces ont été modifiées afin de les rendre compatibles avec le dsm dans le cadre de nos tests. Pour cela nous avons intégré l’api du dsm à des éditeurs de texte open source Java relativement basiques. Ces applications sont également disponibles dans le cadre du projet open source, plus de détails seront fournis en section 8.3.2. La Figure 8.1 est une représentation fonctionnelle de l’architecture du distributed Service Manager qui positionne les différents blocs du prototype, l’annexe B propose également un diagramme de classes du système, enfin vous trouverez plus d’informations sur le site du projet [90]. Ces travaux ont été publiés dans [93]. Le système complet a été conçu afin d’être indépendant du se sous-jacent. Le choix de Java comme langage de programmation a été fait grâce à ses qualités de portabilité mais également pour des questions de vitesse de développement. De plus, l’ensemble des communications entre le dsm et les applications se font via Figure 8.1 – Architecture fonctionnelle du prototype dsm. des ports réseaux (le dsm utilise par exemple le port udp 20100) pour les mêmes raisons d’indépendance avec l’environnement. L’interface graphique n’est pas un axe actif du projet, en contrepartie un mécanisme d’évènements est fourni afin de permettre le développement d’interfaces plus évoluées sans avoir à modifier le système central. Une interface minimale de type « console » a également été développée pour les tests, permettant un accès rapide et exhaustif aux fonctions du dsm tout en limitant les mesures aux performances intrinsèques du modèle (dont le gui ne fait pas partie). Le fichier exécutable du distributed Service Manager (.jar) représente moins de 100ko (sans compter les bibliothèques externes et l’interface graphique). L’api, elle, fait moins de 40ko, offrant aux applications tous les mécanismes requis pour interagir avec le dsm. Il reste à l’application compatible d’initialiser l’api et d’assurer les fonctions pause et resume (cf. 7.2.2) qui ne représentent que quelques lignes de code par ressource à gérer. Pour exemple, l’implémentation de ces fonctions dans les éditeurs de texte que nous avons modifiés a requis environ 50 lignes de code supplémentaires, soit moins de 2 à 5% de la taille totale de ces applications. Nous avons estimé que l’ajout d’une ressource supplémentaire ne coûterait qu’approximativement 5 lignes de code en plus. 

Expérimentations 

Évaluer la valeur ajoutée apportée par un modèle générique de mobilité de service n’est pas une simple tâche. En effet, nous ne proposons pas une solution qui accélère les applications ou augmente le débit d’un réseau, en réalité nous cherchons à permettre à l’utilisateur d’interagir de manière plus intuitive et plus libre avec ses terminaux, rendant la consommation des services en mobilité plus naturelle dans des environnements hétérogènes. Or il est difficile d’évaluer ces valeurs abstraites qui ont pourtant un impact bien concret au niveau de l’expérience utilisateur. Comment mesurer l’utilisabilité et la praticité ? D’un autre côté, le modèle que nous proposons se doit de respecter certaines contraintes pour prouver sa faisabilité, typiquement en terme de délai de transfert comparé aux approches existantes. L’approche originale de mobilité de service que nous proposons doit convaincre sur deux plans afin de garantir une expérience satisfaisante : offrir à l’utilisateur une interaction intuitive avec ses services via des mécanismes de continuités temporelle et contextuelle performants. Nous avons ainsi réalisé deux expérimentations pour évaluer les deux aspects de notre modèle : utilisabilité et efficacité via une approche qualitative et quantitative de notre solution. Dans la première expérimentation, nous avons étudié la relation des utilisateurs avec leurs services dans des situations de mobilité. Nous avons interrogé un échantillon d’utilisateurs afin de répertorier et analyser les méthodes de mobilité existantes. Dans la seconde expérience, nous avons mesuré la performance de notre prototype durant un transfert et analysé l’impact sur son environnement selon différentes métriques.

Évaluation qualitative 

Dans cette première expérimentation nous avons voulu étudier le comportement des utilisateurs exposés à des contraintes de mobilité et plus particulièrement comment ils gèrent leurs services dans une telle situation. L’objectif est d’identifier les méthodes de transfert dans un cas de mobilité de service simple et réaliste. Cette première approche est une étape clé dans notre étude dans la mesure où l’expérience utilisateur est la métrique la plus importante dans l’évaluation de la mobilité de service. Ainsi, comprendre qu’est ce qui gêne ou empêche les utilisateurs de gérer 144 de manière simple, naturelle et intuitive leurs services parmi plusieurs terminaux nous aidera a identifier la réelle problématique. Méthode. Lors de cette expérience, nous avons demandé à des utilisateurs de répondre à des questions concernant une situation simple et leur expérience passée (questionnaire disponible en annexe C). Nous avons sélectionné un échantillon de personnes qui possèdent un ordinateur et l’utilisent au moins une fois par jour. Ainsi nous avons supposé que ces personnes avaient, de manière consciente ou non été confrontées au moins une fois à une situation de mobilité de service. Les participants étaient 33 personnes de différents âges (de 12 à 55 ans) et possédant des connaissances informatiques variées. Nous les avons classés en deux catégories selon leur niveau dans le domaine des Technologies de l’Information et de la Communication : les spécialistes (ingénieurs, chercheurs, étudiants) représentant 80% de l’échantillon et les non-spécialistes représentant les 20% restants. L’hétérogénéité de l’échantillon était recherché et nécessaire pour garantir des résultats de qualité et une vision consistante de la méthodologie utilisateur adoptée. Nous avons présenté à chaque participant une situation simple d’utilisation d’un service informatique, puis nous avons introduit une contrainte de mobilité et nous leur avons demandé de décrire leur solution selon leur expérience. La situation proposée était basique : un utilisateur qui édite un document sur son ordinateur doit subitement interrompre son travail et le poursuivre sur un autre terminal. Les participants étaient alors invités à décrire en détails comment ils ont (ou auraient) réalisé un tel transfert. Nous avions sciemment fourni peu de détails dans la description de la situation afin de faciliter l’adoption du cas par chaque participant. Des questions additionnelles étaient ensuite posées afin d’obtenir des informations plus précises en rapport avec leur expérience de la mobilité de service : besoins, praticité, simplicité, sentiment d’interruption, etc. Les données recueillies ont ensuite été analysées et rapprochées afin d’extraire des informations et des tendances sur les utilisateurs et leur perception des contraintes de mobilité. Les résultats sont présentés dans la section suivante.

Le premier constat est le nombre de solutions différentes pour répondre à une même problème et ce uniquement sur un échantillon de 33 personnes (7 méthodes distinctes pour les spécialistes, 3 pour les non-spécialistes). Il n’y a pas d’approche commune, un modèle générique pour gérer une contrainte de mobilité dans un cas relativement basique. De plus, les trois approches les plus utilisées : stockage usb, courrier électronique et lecteur réseau sont partagées par les deux catégories de l’échantillon, ce qui indique que c’est bien une problématique globale et qu’il n’existe pas de solution miracle réservée aux initiés. 146 On peut également remarquer que ces solutions sont simples : usb et email sont manipulés presque quotidiennement et le partage réseau est intégré nativement aux systèmes d’exploitations, souvent prêt à l’emploi dans le milieu de travail des utilisateurs. La popularité de ces solutions familières est liée à leur simplicité d’utilisation qui en font un choix naturel bien que non prévues a priori à la mobilité de service. Cependant, simplicité n’est pas synonyme de praticité. Nous avons également demandé aux participants d’évaluer la simplicité et la praticité de leur propres solutions, nous avons ensuite traduit leurs réponses en valeurs numériques (1, 2 et 3) selon le barème suivant : 1. non simple/pratique, 2. simple/pratique, 3. très simple/pratique. Finalement non avons calculé la moyenne pour chacune des propriétés et de manière finalement peu surprenante, leurs méthodes sont évaluées comme assez simples (2.58) mais tout juste pratiques (1.91). En fait, par manque de solution dédiée, les approches proposées sont des alternatives « bricolées » basées sur des applications connues, maîtrisées par l’utilisateur et donc simples mais qui ne peuvent en aucun cas offrir des mécanismes efficaces et pratiques de continuité. Pour illustrer ce manque d’efficacité, 66% des participants prétendent se sentir interrompus dans leur tâche en employant leur solution de mobilité. De plus, ils ont décrit les problèmes et les contraintes liées à leur solution, celles-ci sont résumées, par approche, ci-dessous. – Stockage usb. Contraintes matérielles et logicielles (interface et lecteur usb requis, compatibilité du système d’exploitation, système de fichier, etc). – Courrier électronique. accès à Internet nécessaire, limitations sur le taille et le type des données transférées (problèmes de sécurité). Délai de transfert important. – Partage réseau. Problèmes de compatibilité avec le système d’exploitation, le protocole utilisé et le système de fichier. Solution moins triviale généralement pour les spécialistes. Néanmoins, les utilisateurs sondés ont recours en moyenne à un transfert de service 2.73 fois par semaine, spécialistes et non-spécialistes confondus, ce qui 147 est particulièrement important considérant le manque de praticité des méthodes utilisées et l’absence d’un mécanisme dédié à la continuité de service. Cela prouve qu’un réel besoin existe et pas seulement pour les « geeks ». La table 8.1 résume les résultats obtenus dans le cadre de cette expérimentation.