Vu de l’ext´erieur, un service d’observation du contexte doit offrir une vision structur´ee des connais- sances qu’il a du contexte. Ces informations doivent ˆetre disponibles pour l’application `a travers une interface bien d´efinie, qui doit r´epondre `a trois besoins principaux :
D´ecouverte. L’application doit pouvoir interroger le service pour d´ecouvrir la structure du contexte, c’est-`a-dire quels sont les ´el´ements qui le constitue. Par exemple, « L’utilisateur dispose-t-il d’une souris ? ».
Interrogation. L’application doit pouvoir interroger ponctuellement le service pour obtenir imm´ediate- ment la valeur courante d’une propri´et´e du contexte, connaissant d´ej`a l’existence de cette propri´et´e. Par exemple, si une souris est pr´esente, « Combien a-t-elle de boutons ? ».
Abonnement et notification. 1 L’application doit pouvoir s’enregistrer aupr`es du service pour ˆetre notifi´ee de fa¸con asynchrone lorsque certaines circonstances se produisent. Par exemple, « Pr´e- viens moi si l’utilisateur branche ou d´ebranche un p´eriph´erique d’entr´ee (souris, clavier, manette de jeux. . .) ».
Les diff´erents crit`eres d’´evaluation inspir´es de l’´etat de l’art du domaine [Courtrai et al., 2003; Hen- ricksen et al., 2002; Dey and Abowd, 2000] qui nous ont servi pour guider la conception de WildCAT sont les suivants :
Configurabilit´e. Puisque, par d´efinition, ce qui fait partie du contexte d´epend de l’application, le service d’observation du contexte doit pouvoir ˆetre configur´e pour chaque application. Par exemple, les
1
informations concernant le trafic r´eseau font partie du contexte d’un serveur web, mais pas de celui d’un traitement de texte. `A l’inverse, la taille et la r´esolution de l’´ecran sont importants pour ajuster l’interface du traitement de texte, mais n’ont aucun impact sur le serveur web. Chaque application doit pouvoir configurer le service pour observer tous les ´el´ements de son contexte, et uniquement ceux-ci.
G´en´eralit´e. Le mod`ele de donn´ees utilis´e pour repr´esenter le contexte de fa¸con structur´ee doit ˆetre le plus g´en´erique possible. Notre objectif n’est pas de fournir un service limit´e `a un nombre pr´ed´efini de domaines, comme par exemple les pr´ef´erences utilisateur, ou bien les caract´eristiques des p´eri- ph´eriques physiques pr´esents sur une machine. De tels syst`emes existent d´ej`a, par exemple GConf2
et HAL3 pour les deux exemples de domaines cit´es. Les concepts propos´es par le mod`ele doivent
pouvoir ˆetre utilis´es pour repr´esenter tous les diff´erents domaines contextuels potentiels.
Richesse du mod`ele. Au del`a de la g´en´ericit´e, le mod`ele de donn´ees doit ˆetre suffisamment riche pour pouvoir repr´esenter tous les aspects pertinents du contexte. Ce besoin de richesse concerne aussi bien les possibilit´es de structuration des donn´ees entre elles, que les types de donn´ees possibles et leurs caract´eristiques.
Pouvoir d’abstraction. Le mod`ele doit permettre d’offrir une vision plus ou moins abstraite et simpli- fi´ee du contexte pour les clients du service. Ainsi, si certaines applications peuvent ˆetre int´eress´ees par des d´etails tr`es pr´ecis concernant le trafic r´eseau (nombre de paquets re¸cus et perdus par exemple), la plupart peuvent se contenter d’un indicateur moins pr´ecis mais plus simple `a appr´e- hender (un niveau de qualit´e sur une ´echelle de 1 `a 10 par exemple).
Dynamicit´e. Si certains ´el´ements du contexte changent rarement (par exemple la localisation g´eogra- phique d’un serveur), d’autres ´evoluent continuellement (quantit´e de m´emoire disponible, p´eriph´e- riques pr´esents. . .). Le service d’observation du contexte doit prendre en compte cet aspect dyna- mique, qui peut se manifester aussi bien au niveau des valeurs d’une propri´et´e du contexte qu’au niveau structurel (apparition ou disparition de certains ´el´ements).
Pouvoir d’expression `a la disposition des clients. L’interface de programmation que fournit ce ser- vice `a ses clients doit ˆetre suffisamment expressive pour d´ecouvrir les ´el´ements pr´esents, interroger le service concernant une propri´et´e donn´ee, et s’enregistrer aupr`es du service pour ˆetre notifi´e de l’occurrence de certains ´ev´enements (voir la liste des besoins d´efinis plus haut).
Disponibilit´e d’une impl´ementation. Plus pragmatiquement, le service d’observation du contexte doit exister concr`etement sous la forme d’une impl´ementation utilisable, et pas seulement d’une sp´ecification plus ou moins pr´ecise.
Non-interf´erence de l’impl´ementation. L’ex´ecution du service doit avoir un impact minimal sur le fonctionnement du syst`eme observ´e [Schroeder, 1995]. En particulier, il doit ˆetre le plus efficace possible afin d’utiliser le moins de ressources possibles (processeur, m´emoire, etc.), d’une part pour permettre aux applications de disposer du maximum de ces ressources, et d’autre part pour ne pas interf´erer avec ses propres mesures (« effet Heisenberg »).
Facilit´e d’utilisation. En plus de l’interface qu’il offre aux programmes clients, le service, puisqu’il est configurable, doit offrir une interface de configuration. Celle-ci doit permettre aux programmeurs d’une application de sp´ecifier exactement quels ´el´ements font partie du contexte de cette application, sans qu’ils aient `a devenir des experts dans des domaines qui ne sont pas les leurs. Cette interface doit donc `a la fois permettre d’acc´eder `a toute la richesse du service, tout en restant facile d’acc`es. En plus de ces crit`eres qui concernent les aspects g´en´eriques du service et de son impl´ementation, d’autres crit`eres d´eterminent la qualit´e des configurations (ou instanciations) particuli`eres effectivement utilis´ees par les applications :
Correction des mesures. Les informations fournies par le service doivent bien entendu ˆetre correctes. Si une mesure n’est pas certaine, il vaut mieux donner une valeur approch´ee, en indiquant qu’il s’agit d’une approximation, qu’une valeur pr´ecise mais fausse.
2
http://www.gnome.org/projects/gconf/
3
Pr´ecision des mesures. Les observations du contexte effectu´ees par le service doivent ˆetre le plus pr´e- cises possibles. Notons que correction et pr´ecision ne d´esignent pas la mˆeme chose. Dans le cas d’une mesure num´erique par exemple, une valeur de 50 ± 10% peut ˆetre tout aussi correcte qu’une mesure de 52, 5, mais est moins pr´ecise. Un autre aspect de la pr´ecision concerne la fr´equence des mesures concernant le param`etres ´evoluant au cours du temps. Plus ces mesures seront fr´equentes, plus les informations fournies aux clients seront pr´ecises concernant l’´evolution du contexte.
Richesse de la mod´elisation. La mod´elisation doit prendre en compte le plus possible des ´el´ements du contexte de l’application, et des aspects pertinents de ces ´el´ements.
Parmi ces crit`eres d´etaill´es, on retrouve bien tous les crit`eres g´en´eraux concernant la conscience de son contexte d’ex´ecution qu’un logiciel adaptatif doit avoir, tels que nous les avions identifi´es dans a section 1.2.3, page 12 : pr´ecision, richesse, g´en´eralit´e et modularit´e, et enfin performances.
Notons que certains de ces crit`eres sont incompatibles ou du moins contradictoires :
Configurabilit´e et pouvoir d’expression vs. facilit´e d’utilisation. Plus le mod`ele de donn´ees dis- ponible pour d´ecrire le contexte est riche, plus il est complexe `a appr´ehender pour les programmeurs qui veulent utiliser le service dans leur application. Il faut conserver `a l’esprit que les programmeurs d’applications sensibles au contexte ne doivent pas ˆetre oblig´es de devenir des experts dans ce domaine.
G´en´ericit´e vs. richesse du mod`ele. Dans une certaine mesure, l’enrichissement du mod`ele de donn´ees peut le rendre moins g´en´eral, en introduisant des notions qui n’ont de sens que pour certains domaines. D’un autre cˆot´e, un mod`ele trop g´en´erique risque de n’avoir aucune s´emantique propre, et donc de laisser l’interpr´etation des donn´ees enti`erement `a la charge des clients.
Non-interf´erence de l’impl´ementation vs. tous les autres. Quasiment tous les crit`eres (richesse du mod`ele, dynamicit´e, correction et pr´ecision des mesures) n´ecessitent pour ˆetre mis en œuvre une impl´ementation sophistiqu´ee qui utilise beaucoup de ressources (temps de calcul, espace m´emoire ou disque). Si ces ressources sont utilis´ees par le service, elles ne sont donc plus utilisables par l’application, ce qui nuit `a son bon fonctionnement.
Le r´esultat final ne pourra donc ˆetre qu’un compromis, que l’on esp`ere cependant adapt´e au plus grand nombre de cas d’utilisations possibles. Comme nous le verrons plus loin, WildCAT est con¸cu sp´ecifiquement pour permettre `a chaque application l’utilisant de choisir le compromis qui lui convient le mieux.