Dans la suite de ce document, nous reprenons tour `a tour chacune des contributions qui composent le syst`eme safran en les d´ecrivant plus en d´etail. Le chapitre 5 d´ecrit ainsi comment le syst`eme WildCAT permet de construire facilement des applications sensibles `a leur contexte, et le chapitre 6 pr´esente en d´etails le langage FScript qui permet de sp´ecifier et d’ex´ecuter des reconfigurations dynamiques sˆures de
composants Fractal. Nous d´ecrivons ensuite dans le chapitre 7 le langage d´edi´e qui permet `a safran de programmer des politiques d’adaptation r´eactives et de les associer dynamiquement `a des composants Fractal. Ce langage est construit en partie au dessus des deux contributions pr´ec´edentes, bien que ces derni`eres aient ´et´e con¸cues pour ˆetre plus g´en´erales et applicables en dehors du cadre de safran. Enfin, le chapitre 8 montre comment l’utilisation du syst`eme safran dans sa globalit´e s’int`egre dans le cycle de d´eveloppement des applications en l’appliquant `a plusieurs cas d’utilisation concrets.
Chapitre 5
WildCAT : un outil pour le
d´eveloppement d’applications
sensibles au contexte
Sommaire
5.1 Introduction . . . 71 5.2 Objectifs et crit`eres d’´evaluation . . . 73 5.3 Le mod`ele de donn´eesWildCAT . . . 75 5.3.1 Structuration des donn´ees . . . 75 5.3.2 Evolutions dynamiques du contexte´ . . . 78 5.3.3 Conclusion . . . 79 5.4 Interface de programmation . . . 79 5.4.1 D´esignation des ressources et des attributs . . . 79 5.4.2 Interrogation du contexte et navigation . . . 80 5.4.3 Abonnement et notifications asynchrones . . . 81 5.5 Instanciation et configuration du syst`eme . . . 85 5.5.1 D´efinition de la structure statique . . . 85 5.5.2 D´efinition des sondes pour les attributs primitifs . . . 86 5.5.3 D´efinition d’attributs synth´etiques . . . 87 5.5.4 Mod´elisation des aspects dynamiques du contexte . . . 89 5.5.5 Conclusion . . . 91 5.6 M´ecanismes d’extensions deWildCAT . . . 92 5.6.1 D´eveloppement de nouvelles sondes . . . 92 5.6.2 Cr´eation d’une nouvelle impl´ementation . . . 96 5.7 Conclusion . . . 98
C
e chapitred’ex´ecution et d’ˆetre pr´evenue automatiquement lorsque certaines circonstances – d´efinies par l’ap-d´ecrit WildCAT, un syst`eme permettant `a une application Java d’observer son contexte plication – se produisent. Cette capacit´e `a percevoir son environnement afin de pouvoir r´eagir `a ses ´evolutions est indispensable pour une application adaptative, puisque c’est en r´eponse `a ces changements que l’application d´ecide de s’adapter.5.1
Introduction
Fondamentalement, toute adaptation d’un syst`eme est une modification de ce syst`eme en r´eponse `a un changement de son contexte d’utilisation, avec pour objectif que le syst`eme r´esultant soit mieux adapt´e
au nouveau contexte (cf. Sect. 1.2, page 10). Avant mˆeme de se poser les questions des reconfigurations `
a appliquer au syst`eme, et de la fa¸con de les d´ecrire (qui seront les sujets des chapitres suivants), nous devons r´esoudre le probl`eme de la perception du contexte d’ex´ecution par l’application.
Le terme « contexte » est tr`es vague, et d´efini de mani`eres diff´erentes et incompatibles selon les auteurs, quand il est d´efini. Certains se contentent d’en donner un synonyme, comme « environnement ». D’autres [Brown, 1998] ont une vision restreinte qui n’inclut par exemple que le contexte physique (localisation g´eographique, heure, temp´erature. . .). Dans [Dey and Abowd, 2000] les auteurs pr´esentent et critiquent diverses d´efinitions existantes dans la litt´erature, mais celle `a laquelle ils aboutissent (« Context is any information that can be used to characterize the situation of an entity. ») est beaucoup trop vague et difficilement utilisable en pratique pour d´ecider si une information fait ou non partie du contexte. Dans [Henricksen et al., 2002], les auteurs tentent de d´egager une d´efinition `a partir d’une ´etude de cas. Cependant, ils ne font qu’´enum´erer certaines caract´eristiques des informations contextuelles (dynamicit´e, imperfection des mesures, corr´elations entre informations. . .) et, encore une fois, ne donnent aucun crit`ere op´erationnel pour d´eterminer quelles sont les informations qui font partie du contexte.
Dans ce document, nous adopterons la d´efinition suivante : le contexte d’ex´ecution d’une application regroupe tous les ´el´ements externes `a l’application – autres que ses entr´ees explicites – qui influencent la qualit´e de son fonctionnement telle que per¸cue par son utilisateur. Cette influence peut se faire sentir par exemple au niveau des performances, de la s´ecurit´e, ou des fonctionnalit´es. Les « ´el´ements » qui font partie du contexte d’une application peuvent ˆetre eux aussi de natures tr`es diverses : les autres logiciels interagissant avec l’application, la machine hˆote qui l’ex´ecute, l’environnement physique de celui-ci, le ou les utilisateur(s), etc.
Cette d´efinition du contexte met en ´evidence le fait que celui-ci est d´etermin´e par l’application. Ainsi, si le niveau de bruit ambiant dans une pi`ece ne fait pas partie du contexte d’un tableur, il fait partie de celui d’un lecteur multim´edia, qui peut par exemple ajuster son volume sonore pour rester audible `a son utilisateur.
Notons que notre d´efinition, contrairement `a celles des articles cit´es ci-dessus, fournit un crit`ere op´e- rationnel simple pour d´eterminer si une entit´e fait ou non partie du contexte d’une application.
La qualit´e de fonctionnement per¸cue par l’utilisateur inclut les crit`eres de performances temporels (ex : temps de r´eponse maximal) et spatiaux (ex : utilisation de la m´emoire) g´en´eralement d´esign´es par l’expression Quality of Service (QoS ), mais n’est pas limit´ee `a ceux-ci. Par exemple, la taille des fontes ou les couleurs utilis´ees par une application graphique peut ˆetre tr`es importante pour son utilisabilit´e, surtout si son utilisateur a des probl`emes de vision (myopie, daltonisme. . .). Ce genre de crit`eres n’est en g´en´eral pas pris en compte par les syst`emes g´erant la Qualit´e de Service, entre autre car ils ne se prˆetent pas facilement `a des mesures objectives. Notre d´efinition du contexte d’ex´ecution fait r´ef´erence `
a la qualit´e per¸cue par l’utilisateur du syst`eme (toujours un humain), la seule r´eellement importante au bout du compte. Il est donc n´ecessaire d’inclure dans le contexte d’ex´ecution des ´el´ements subjectifs comme les pr´ef´erences de l’utilisateur. Bien entendu, inclure ce genre d’information dans le contexte rend plus difficile l’´evaluation de la qualit´e d’une adaptation, mais il s’agit d’un tout autre probl`eme. Dans ce chapitre, nous nous pr´eoccupons uniquement de permettre aux applications de percevoir leur contexte ; ce qu’elles font de ces informations rel`eve d’une autre probl´ematique.
Puisque le contexte d’ex´ecution est externe `a l’application et qu’il ne fait pas partie de ses entr´ees, il n’est g´en´eralement pas explicitement repr´esent´e dans l’application. Or, puisqu’une application adaptative doit ˆetre consciente de son contexte (context-aware) pour pouvoir s’y adapter, nous devons trouver un moyen pour observer le contexte et de rendre le r´esultat cette observation accessible `a l’application afin qu’elle puisse raisonner dessus.
G´en´eralement, lorsqu’une application a besoin de s’adapter `a un ´el´ement de son contexte, elle impl´e- mente cette observation de fa¸con sp´ecifique `a son cas particulier. Par exemple, un programme qui veut utiliser une taille de fonte appropri´ee `a la r´esolution de l’´ecran de l’utilisateur devra interroger le syst`eme d’exploitation ou de fenˆetrage pour obtenir cette information. Cette approche pose plusieurs probl`emes :
– le code de d´etection correspondant doit ˆetre r´e´ecrit par chaque application ;
– ce code n´ecessite souvent d’interagir directement avec le syst`eme d’exploitation, voire avec le ma- t´eriel, ce qui r´eduit la portabilit´e de l’application ;
– si l’´el´ement du contexte dont l’application d´epend peut ´evoluer pendant l’ex´ecution de l’application, le code n´ecessaire pour r´eagir dynamiquement rend l’application beaucoup plus complexe, et pour cette raison est souvent omis (obligeant par exemple l’utilisateur `a red´emarrer l’application pour prendre en compte les nouveaux param`etres) ;
– les programmeurs d’une application ont rarement les comp´etences techniques pour ´ecrire correcte- ment et efficacement ce genre de code de bas niveau, qui n´ecessite une grande expertise syst`eme ; ce ne devrait d’ailleurs pas ˆetre leur travail.
La solution que nous proposons, et qui est d´ecrite dans ce chapitre, consiste `a fournir aux program- meurs d’application un service g´en´erique et r´eutilisable d’observation du contexte d’ex´ecution. Le rˆole de ce service est d’offrir aux applications qui l’utilisent une vision pr´ecise, compl`ete et correcte de leur contexte d’ex´ecution, leur permettant de raisonner sur celui-ci et de d´etecter l’occurrence de certaines circonstances, sp´ecifiques `a leur application. Cette approche r´esout les probl`emes cit´es plus haut, et offre en outre d’autres avantages :
– ´etant donn´e qu’il s’agit d’un syst`eme `a part enti`ere, d´evelopp´e une fois pour toute, il peut ˆetre beau- coup plus sophistiqu´e que les solutions ad hoc g´en´eralement simplistes d´evelopp´ees pour r´esoudre un probl`eme ponctuel ;
– la modularisation et l’encapsulation de ce service permettent son enrichissement ind´ependamment des applications qui l’utilisent, tant que l’interface entre les deux reste la mˆeme ;
– ce type de service peut ˆetre utilis´e pour d’autres besoins que l’adaptation d’application, comme par exemple la surveillance ou la collecte de statistiques.
Dans ce chapitre, nous d´ecrivons la conception, l’utilisation et la mise en œuvre de WildCAT, un service g´en´erique d’observation du contexte d’ex´ecution. Nous indiquons pour commencer les objectifs et les crit`eres d’´evaluation d’un service d’observation du contexte (Section 5.2) avant de pr´esenter le syst`eme que nous proposons, WildCAT. Nous d´ecrivons tout d’abord le mod`ele de donn´ees utilis´e pour repr´esenter le contexte (Section 5.3), puis l’interface de programmation (api) permettant aux applications d’utiliser ce service (Section 5.4), et le format des fichiers de configurations qui permettent d’instancier le mod`ele g´en´erique pour les besoins sp´ecifiques d’une application (Section 5.5). Nous donnons ensuite quelques d´etails les possibilit´es d’extension du framework (Section 5.6), avant de conclure le chapitre (Section 5.7).