Espace de modélisation des entités

Suite à l’analyse des taxonomies que nous avons développées, nous avons déterminé trois catégories d’entités couvrant les champs étudiés : les capteurs physiques et virtuels, les capteurs de configuration et de suivi, et les composants de calcul. La présentation de ces catégories met en évidence l’expressivité du langage de taxonomie, et plus particulièrement la pertinence des concepts choisis pour définir les interfaces d’interaction des entités.

8.2.2.1 Capteurs physiques et virtuels

La plupart des applications ubiquitaires dépendent fortement des changements aléatoires survenant dans l’environnement où elles sont déployées. Par exemple, une application gérant la consommation d’énergie doit réagir aux changements de température. Nous modélisons la nature versatile de l’environnement au moyen de capteurs physiques et virtuels, par exemple, un capteur physique de luminosité ou de température. Ces informations sont naturellement représentées en Pantagruel par des attributs volatile sur des classes d’entités représentant de tels capteurs.

Lorsque l’environnement est virtuel, par exemple s’il s’agit d’un ordinateur ou d’un compo-sant logiciel avec lequel l’utilisateur peut interagir, nous parlons de capteurs virtuels. Ceux-ci expriment alors une situation captée par un ordinateur, provoquée par l’utilisateur ou par une application logicielle tournant sur l’ordinateur. Par exemple, la classe PresenceAgent de notre exemple du chapitre 4 est un capteur virtuel qui modélise un client de messagerie instantané capable de détecter si une personne utilise son ordinateur ou pas (via l’attribut volatile status,

8 Evaluation globale

dans la mesure où la personne permet l’accès à cette information). De la même façon, une application logicielle de calendrier envoyant des événements selon les conférences prévues est un capteur virtuel. Enfin, les éléments constituants d’interfaces (logicielles ou non) avec les-quels l’utilisateur peut interagir peuvent également être vus comme des capteurs virtuels. Nous avons ainsi modélisé un bouton de panique sur le capteur virtuel Prompteur pour Henrick, ainsi que les interrupteurs permettant de contrôler manuellement l’alimentation des plantes, dans l’application de gestion des plantes.

8.2.2.2 Composants de configuration et de suivi

Configurer un environnement selon l’information recueillie par les capteurs, ou selon les pré-férences de l’utilisateur, est une caractéristique clé des applications ubiquitaires. En particulier, dans le champ de la domotique, le comportement des applications doit être configuré selon les habitants et leurs préférences. Nous appelons composants de configuration les entités destinées à effectuer ce type de réglage. Prenons l’application de personnalisation musicale de la maison développée pour iCAP [DSSK06] : la musique jouée par les radios installées dans une maison doit être configurée selon les préférences musicales des personnes se déplaçant de pièce en pièce. Dans cet exemple, que nous avons aussi utilisé pour motiver les participants de l’évaluation d’accessibilité, la classe Radio est un composant de configuration, tout comme la classe Réveil de l’exemple d’Henrick. Pour modéliser une entité représentant un composant de configuration, nous utilisons les attributs write ; ainsi, le genre musical music est un attribut write sur la classe Radio. Il peut être configuré selon les préférences d’une personne, représentée par exemple par des attributs constant, en affectant l’attribut write à ces derniers. On peut ainsi imaginer une classe Badge qui rassemble les préférences d’une personne (musiquePréférée) et les informations de sa localisation. Configurer la musique revient alors à affecter l’attribut musique d’une radio à la valeur de musiquePréférée d’une personne entrant dans la pièce où cette radio est installée. La configuration de l’environnement peut aussi dépendre de méthodes appelées antérieu-rement par l’application. Prenons le cas des applications d’assistance à une personne pour accomplir différentes tâches de sa journée (se lever, prendre une douche et s’habiller) dans le bon ordre. Pour que l’assistance soit adaptée à la personne, il faut configurer l’environnement selon les tâches effectuées ou à accomplir. Par exemple, si l’environnement est composé d’un prompteur de tâches et d’un écran affichant les tâches restantes, ces applications doivent mettre à jour l’affichage de l’écran lorsqu’une tâche est supprimée dans le prompteur. Une manière de procéder est de suivre les différentes méthodes déclenchées sur les entités suite à la perception du comportement de la personne par les différents capteurs installés dans la maison. Nous appelons composants de suivi les entités destinées à faire ce suivi ou monitoring. Par exemple, lorsque la douche a coulé un certain temps, l’application peut en déduire (mais non garantir) que la personne a bien pris sa douche et ainsi lui suggérer de passer au séchage puis à l’habillement. Ces composants peuvent également être modélisés au moyen des attributs write sur les entités, servant alors d’indicateurs des méthodes déclenchées. Par exemple, l’attribut write nommé etat et défini sur la classe d’entités Mitigeur permet de savoir si la méthode ouvrir déclenchant le dé-bit d’eau a été exécutée. D’après cette spécification, cet attribut est supposé être mis à jour dès que la méthode en question est invoquée, permettant à l’application de l’utiliser pour modifier

8.2 Périmètre d’expressivité de Pantagruel

la liste des tâches enregistrées dans le prompteur de tâches. 8.2.2.3 Composant de calcul

Lorsqu’elles mettent en jeu un grand nombre d’entités, les applications doivent parfois rassem-bler des informations de contexte captées par ces entités et effectuer des calculs pour accomplir un but particulier. Le calcul d’information peut être explicité en établissant une relation entre les informations des entités et leur calcul, par exemple via les paramètres d’une méthode effec-tuant cette opération. Nous appelons composants de calcul les entités chargées d’effectuer de tels calculs.

Considérons des applications de gestion d’énergie qui contrôlent la consommation d’énergie en manipulant des données telles que la chaleur ou la luminosité ambiantes. La chaleur moyenne que doit produire un appareil de climatisation dans une pièce peut dépendre de la présence ou non de personnes dans la pièce et de l’heure de la journée (par exemple, il n’est pas nécessaire de faire fonctionner la climatisation à pleine puissance la nuit). Pour calculer cette chaleur, on peut imaginer une classe d’entités ComposantTemperature, utilisée comme un composant de calcul qui collecte ces informations et ajuste périodiquement le réglage de l’appareil. La chaleur moyenne est alors représentée par un attribut write nommé chaleurMoyenne sur ce composant, et son calcul est effectué par une méthode dont la signature est calculerTemperature(Heure h, Booleen occupé), et déclarant un effet sur chaleurMoyenne. De même, une classe d’entités Compteur, calculant le nombre de personnes dans une pièce (par exemple, qui se sont identifiées en utilisant un badge), peut être vue comme un composant de calcul dont l’effet est une variable nombre incrémentée à chaque fois qu’une personne entre (ou décrémentée dans le cas contraire). La déclaration des paramètres rend explicite les données requises pour la modification de l’effet calculé. La méthode peut ainsi être invoquée dans un programme Pantagruel selon le changement de contexte capturé par des entités de type capteur.

Résumé et limitations L’analyse des champs d’applications que nous avons faite nous a permis d’identifier trois catégories d’entités pouvant les caractériser. Nous avons montré que ces entités peuvent être spécifiées à l’aide des concepts du langage de taxonomie, et que ces concepts permettent d’expliciter certaines informations par le choix appropriés d’attributs, de méthodes, d’effets et de paramètres d’entrée.

Néanmoins, l’expressivité de Pantagruel est mise en défaut lorsqu’il s’agit de spécifier

com-ment l’information de contexte applicative (les attributs write) doit être calculée. Cette

infor-mation peut notamment être utile pour raffiner le processus de vérification des programmes, car elle pourrait fournir ou permettre de déduire des espaces de valeurs possibles pour les effets. Le cadre conceptuel ContextToolkit proposé par Dey et al. [DAS01] et que nous avons évoqué dans la sous-section 8.1.3 propose des abstractions de contexte pour spécifier certaines de ces informations. En particulier, l’utilisation de deux de ces abstractions pourraient bénéficier à Pantagruel : les interprètes, qui transforment des données en données de plus haut niveau, et les aggrégateurs, qui rassemblent des données propres à un élément particulier de l’environne-ment (par exemple, un “aggrégateur” de pièces, permettant de stocker le nombre de personnes entrant dans une pièce). Combiner ces abstractions avec notre langage de taxonomie

permet-8 Evaluation globale

trait d’enrichir significativement le rôle des classes d’entités, et de raffiner ainsi la vérification de programmes.