Mode de notification adapt´e au contexte d’utilisation

Lorsqu’un nouveau courrier est re¸cu par le composant connexion (seul `a ˆetre en communication directe avec le serveur de courriers), ce dernier l’envoie `a la base de donn´ee des messages (store), qui le stocke et pr´evient `a son tour le composant ui pour qu’il puisse notifier l’utilisateur. Le composant ui dispose de deux m´ethodes de notification :

– une notification visuelle simple et non-intrusive sous la forme d’une icˆone dans la barre de tˆaches du bureau de l’utilisateur ;

– une notification sonore, sous la forme d’un fichier audio du type « Vous avez un message ». L’application initiale permet `a l’utilisateur de choisir l’une de ces m´ethodes dans son panneau de configu- ration. Si cette possibilit´e de choix est une bonne chose pour l’utilisateur en ce qu’elle lui permet d’adapter le comportement de l’application `a ses pr´ef´erences, la fa¸con dont elle se pr´esente pose probl`eme. En effet, la m´ethode de notification la plus appropri´ee `a un moment donn´e d´epend du contexte d’utilisation de l’application, et un choix statique comme celui propos´e ne conviendra pas `a toutes les situations :

– Si l’utilisateur est absent de son bureau, une notification sonore est inutile, et peut mˆeme ˆetre gˆenante pour les personnes proches non concern´ees. De plus, une telle notification ´etant par nature ponctuelle, l’utilisateur ne saura pas en revenant `a son poste s’il a re¸cu du courrier.

5

Une limitation actuelle de safran est que les politiques n’ont pas d’´etat propre. Dans cet exemple, cela signifie qu’il n’est pas possible de m´emoriser l’ancienne valeur du param`etre pollIntervall.

– En revanche, la notification sonore ˆetre plus utile si l’utilisateur est pr´esent car il peut la percevoir sans interrompre son activit´e, mˆeme s’il ne travaille pas directement sur son ordinateur (dans ce cas, une notification visuelle passerait inaper¸cue).

Notre second sc´enario aura donc pour objectif de rendre adaptative la s´election du mode de notification utilis´e. Ainsi, l’application utilisera toujours le mode le plus appropri´e au contexte actuel et en particulier `

a l’activit´e de l’utilisateur, sans intervention de la part de ce dernier.

La partie de l’application initiale qui correspond `a la fonction de notification est repr´esent´ee par la figure suivante 8.3. La demande de notification est re¸cue par l’interface notification du composant ui, qui la redirige vers un de ses sous-composants. Chaque mode de notification est impl´ement´e par un composant Fractal distinct fournissant cette mˆeme interface. Le composant utilis´e est celui connect´e `

a l’interface interne du composite ui. Dans l’application initiale, le choix explicite de l’utilisateur par l’interm´ediaire du panneau de configuration se traduit par la connexion de l’un ou l’autre des composants disponibles.

Fig. 8.3 – Syst`eme de notification dans l’application initiale.

L’impl´ementation du sc´enario d’adaptation d´ecrit ci-dessus avec safran se fait tr`es simplement en cr´eant une politique d’adaptation qui sera associ´ee au composant ui. Les diff´erentes r`egles qui constituent cette politique d´etectent les changements significatifs dans l’activit´e de l’utilisateur, et reconfigurent le composant cible ui afin d’activer le mode de notification appropri´ee `a chaque situation.

Informations contextuelles. Puisque l’activit´e de l’utilisateur fait partie du contexte d’ex´ecution, elle est r´eifi´ee par WildCAT, et ses changements se traduisent par l’occurrence d’´ev´enements exog`enes auxquels les politiques d’adaptation peuvent r´eagir. Concr`etement, WildCAT est configur´e pour fournir un domaine contextuel nomm´e user, qui regroupe et organise toutes les informations concernant l’´etat et l’activit´e de l’utilisateur. Nous n’entrerons pas dans les d´etails techniques de l’impl´ementation des sondes n´ecessaires. Notons cependant que de telles sondes, et plus globalement le domaine contextuel user, ont un int´erˆet beaucoup plus g´en´eral que notre sc´enario sp´ecifique. Bien que la mod´elisation du domaine et le d´eveloppement des sondes n´ecessaires soit relativement coˆuteux, ce travail n’est `a effectuer qu’une seule fois et peut ensuite ˆetre r´eutilis´e par de nombreux sc´enarios dans des applications tr`es diverses6_.

Concr`etement, les ´el´ements du domaine user qui nous int´eressent pour notre sc´enario sont les suivants : – user ://location/current/logical@room est le nom de la salle dans laquelle est actuellement l’utilisateur, par exemple B-206. Ce type d’information peut ˆetre connu par exemple par l’utilisation de badges, comme dans le projet Active Badge d’Olivetti [Want et al., 1992], d’ailleurs consid´er´e par beaucoup comme la premi`ere application « context-aware », i.e. sensible au contexte.

– user ://location/office@room est le nom du bureau de l’utilisateur. Il s’agit d’une information statique facilement r´ecup´erable par exemple dans un annuaire de type ldap.

6

– user ://activity@working est un bool´een qui indique si l’utilisateur est actuellement en train de travailler. En premi`ere approximation, on consid`ere que l’utilisateur est en train de travailler si l’on d´etecte une activit´e sur son ordinateur (clavier, souris) dans la derni`ere minute.

Politique. La politique d’adaptation correspondant au sc´enario est la suivante : action set-notification-mode(target, mode) = {

if ($target/binding::notification != $mode) { unbind($target/internal-interface::notification); bind($target/internal-interface::notification, $mode); } } policy adaptive-nofitication = { rule {

when realized(user://location/current/logical@room != user://profile/office@room) do { if (not($target/child::icon) { notifier = new("example.mail.VisualNotifier"); set-name($notifier, "icon"); add($target, notifier); start($notifier); } set-notification-mode($target, $target/child::icon/interface::notifier); } } rule {

when realized(user://location/current/logical@room == user://profile/office@room and user://activity@working) if (not(user://profile/disabilities@hearing_impaired)) do { if (not($target/child::sound) { notifier = new("example.mail.AudioNotifier"); set-name($notifier, "sound"); add($target, notifier); start($notifier); } set-value($notifier/@volume = 0.3); set-notification-mode($target, $target/child::sound/interface::notifier); } } }

Cette politique est constitu´ee de deux r`egles, qui utilisent une action FScript d´efinie en dehors de la politique elle-mˆeme (mais dans le mˆeme fichier). C’est cette action set-notification-mode qui effectue la reconfiguration elle-mˆeme, en s’assurant que le mode de notification demand´e (mode, une interface) est bien connect´e. La premi`ere r`egle de la politique d´etecte le d´epart de l’utilisateur de son bureau, grˆace `a un descripteur d’´ev´enement exog`ene utilisant deux des attributs WildCAT d´ecrits plus haut. Lorsque cela se produit, la r´eaction correspondante est d’effecteur la connexion du mode de notification appropri´e, grˆace `

a set-notification-mode, apr`es s’ˆetre assur´e que le composant qui impl´emente ce mode de notification est bien pr´esent et prˆet `a ˆetre utilis´e. La seconde r`egle est similaire, mais r´eagit `a un ´ev´enement diff´erent, `a savoir « l’utilisateur est dans son bureau et en train de travailler », et sa r´eaction est d’activer le mode de

notification sonore, mais uniquement si l’utilisateur n’est pas malentendant (auquel cas une notification sonore est bien sˆur inutile). Pour s’assurer que l’utilisateur entendra bien la notification mais afin qu’elle ne le d´erange pas trop (puisqu’il travaille), le composant de notification sonore est configur´e pour utiliser un volume sonore relativement faible.