Adaptation d applications pervasives dans des environnements multi-contextes

Transcription

1 N d ordre 07 ISAL 0058 Année 2007 Thèse Adaptation d applications pervasives dans des environnements multi-contextes Présentée devant L institut national des sciences appliquées de Lyon Pour obtenir Le grade de docteur en informatique École doctorale École doctorale Informatique, Information et société Spécialité Informatique Par Tarak CHAARI Soutenance prévue le 28/09/2007 devant la commission d examen Jury Paul RUBEL Professeur (INSA de Lyon), Président du jury Florence SÈDES Professeur (INP Toulouse), Rapporteur Philippe ANIORTÉ Professeur (Université de Pau), Rapporteur Augusto CELENTANO Professeur (Université de Venise), Examinateur André FLORY Professeur (INSA de Lyon), Directeur de thèse Frédérique LAFOREST Maître de conférences (INSA de Lyon), Co-directrice de thèse Laboratoire d Informatique en Image et Systèmes d information (LIRIS)

2

3 Titre Adaptation d applications pervasives dans des environnements multi-contextes Mot clés Système d information pervasifs, Sensibilité au contexte, Adaptation de services, Adaptation de contenu, Adaptation d interfaces utilisateurs Résumé Les systèmes pervasifs ont pour objectif de rendre l information disponible partout et à tout moment. Ces systèmes doivent pouvoir être utilisés dans différents contextes selon l environnement de l utilisateur, son profil et le terminal qu il utilise. L un des problèmes majeurs de ce type de systèmes concerne donc l adaptation au contexte d utilisation. Dans ce travail de thèse, nous proposons une stratégie complète, générique et évolutive d adaptation d applications au contexte d utilisation sur trois volets: (i) les services offerts à l utilisateur, (ii) les données renvoyées par ces services et (iii) leur présentation à l utilisateur. L adaptation des services consiste à intercepter les appels vers les services originaux de l application et à modifier leur comportement à l aide d un ensemble d opérateurs d adaptation fonctionnelle. L adaptation des données consiste à transformer ou à remplacer chaque objet multimédia renvoyé par les services de l application qui n est pas utilisable dans la situation contextuelle en question. L adaptation de la présentation se base sur un processus de génération automatique du code de l interface utilisateur qui garantit l interaction avec les données et les services adaptées. La stratégie que nous avons élaborée atteint deux objectifs : (i) intégrer la sensibilité au contexte dans l application de façon incrémentale et (ii) garantir l adaptation à partir d une description simple des services offerts à l utilisateur. Nous avons mis en œuvre cette stratégie en développant une plateforme d adaptation d applications au contexte d utilisation. Nous avons utilisé les technologies Java, OSGi et les services Web pour réaliser cette plateforme. Nous avons également validé nos modèles et notre approche d adaptation sur une application médicale de suivi de patients dialysés à domicile.

4 Title Adaptating pervasive applications in multi-contextual environments Keywords Pervasive information systems, Context-awareness, Service adaptation, Content adaptation, User interface adaptation Summary Pervasive systems aim to make information available anywhere and at anytime. These systems should be used in different contexts depending on the environment of the user, her/his profile and her/his device. Consequently, one of the main problems of this type of information systems is the adaptation to context. In this PHD thesis, we propose a complete, generic, and evolutionary strategy that guarantees the adaptation of applications to context on three facets: (i) the services offered to the user, (ii) the data returned by these services and (iii) their presentation to the user. Service adaptation consists of modules that intercept the application s service calls and modifying their behaviour using a list of functional adaptation operators. Data adaptation consists in transforming or replacing the non-usable multimedia service outputs in the considered context situation. Presentation adaptation consists in automatically generating the complete code of the user interface that guarantees the interaction with the adapted data and services. Our adaptation strategy has achieved two goals: (i) integrate context incremental awareness in the application and (ii) guarantee the adaptation starting from a simple description of the services offered to the user. We have validated this strategy by developing a platform that guarantees the adaptation of applications to context. We have used Java, OSGi and Web service technologies to implement this platform. We have also successfully tested our adaptation approach on a home health care application of dialysed persons. In essence, we believe that this work is a step ahead towards building adaptive and evolutionary pervasive information systems.

5 SOMMAIRE INTRODUCTION GENERALE 15 I. Les systèmes d information pervasifs 17 II. La sensibilité au contexte dans les systemes d information pervasifs 18 III. Problématique 18 IV. Cas d étude 19 V. Organisation du document 20 CHAPITRE I - ETAT DE L ART : LES SYSTEMES SENSIBLES AU CONTEXTE 23 I. Introduction 25 II. Notion de contexte Que disent les dictionnaires? Contexte et informatique pervasive Catégories de contexte 27 III. Notion de sensibilité au contexte (Context-Awareness) 29 IV. Architecture d un système sensible au contexte Couche de capture du contexte Couche d Interprétation et d agrégation du contexte Couche de stockage et historique du contexte Couche dissémination du contexte Couche application 37 V. Principales plateformes existantes de sensibilité au contexte Context Toolkit Context Broker Architecture (CoBrA) Context Management Framework (CMF) Service oriented context-aware middleware (SOCAM) Synthèse 44 VI. Conclusion 46

6 CHAPITRE II ETAT DE L ART : LES TRAVAUX D ADAPTATION EXISTANTS 47 I. Introduction 49 II. Définition, utilité et caractérisation de l adaptation Définition Utilité Caractérisation 50 III. L adaptation dans les architectures à base de composants Concepts de la programmation à base de composants Mécanismes d adaptation existants Techniques d'adaptation de composants Quelques architectures existantes d adaptation de composants Synthèse sur l'adaptation des architectures à base de composants 61 IV. Adaptation de contenu multimédia Adaptation coté serveur Adaptation coté client Adaptation intermédiaire Synthèse sur les approches d'adaptation de contenu 63 V. Adaptation des interfaces utilisateur Modélisation des interfaces utilisateurs Adaptation des interfaces homme-machine Synthèse sur l'existant dans l'adaptation de présentation 66 VI. Conclusion 67 CHAPITRE III - CONTRIBUTIONS : DEFINITIONS, OBJECTIFS ET ARCHITECTURE _69 I. Introduction 71 II. Notre vision du contexte Définition du contexte Notion de situation contextuelle Modélisation d une situation contextuelle 75 III. Modélisation fonctionnelle d une application Notion d entité logicielle Notion de service Notion de dépendance d exécution de services Notion de modèle fonctionnel 81 IV. Objectifs de notre travail 85

7 V. SECAS : Plateforme pour l adaptation d applications à de nouveaux contextes d utilisation Présentation de la plateforme SECAS Couche de gestion du contexte Couche d adaptation Couche de déploiement d applications 93 VI. Conclusion 94 CHAPITRE IV - CONTRIBUTIONS : STRATEGIE D ADAPTATION AU CONTEXTE 95 I. Présentation de notre stratégie d adaptation 97 II. Adaptation fonctionnelle Principe de l adaptation fonctionnelle Règles d adaptation fonctionnelle Opérateurs d adaptation fonctionnelle Processus d adaptation fonctionnelle dans SECAS Synthèse sur l adaptation fonctionnelle dans SECAS 120 III. Adaptation de contenu Principe de l adaptation de contenu Module d adaptation de contenu Planification de l adaptation de contenu [Berhe05] Synthèse sur l adaptation de contenu dans SECAS 129 IV. Adaptation de présentation Principe de l adaptation de présentation Modélisation d une interface utilisateur dans SECAS Processus de génération automatique d interfaces adaptées Synthèse sur l adaptation de présentation dans SECAS 137 V. Conclusion 138 CHAPITRE V - CONTRIBUTIONS : IMPLANTATION ET UTILISATION DE NOTRE PLATEFORME D ADAPTATION 139 I. Introduction 141 II. Conception de l architecture SECAS Modélisation fonctionnelle Modélisation dynamique Modélisation statique 149

8 4. Déploiement de la plateforme Scénario générique d utilisation de SECAS 157 III. Développement de la plateforme SECAS Implantation de la couche d adaptation fonctionnelle Implantation de la couche d adaptation de contenu Implantation de la couche d adaptation de présentation Statistiques 161 IV. Utilisation de SECAS dans le projet SICOM Déploiement de SICOM avec l interface d administration de SECAS Adaptation de l application «SICOM» 163 V. Utilisation d un nouveau modèle de contexte DANS SECAS 168 VI. Conclusion 170 CONCLUSIONS ET PERSPECTIVES 171 I. Bilan 173 II. Perspectives 174 BIBLIOGRAPHIE 177 ANNEXES 197

9 LISTE DES FIGURES Figure 1 - Architecture générale d'un système sensible au contexte 31 Figure 2 - Modélisation de la localisation de l'utilisateur en utilisant CC/PP 34 Figure 3 - Exemple de représentation XML du contexte en utilisant l'ontologie CoOL 35 Figure 4 - L'architecture du context Toolkit de Anind K. Dey 38 Figure 5 - Architecture globale du système CoBrA 40 Figure 6 - Représentation OWL du contexte dans l'architecture CoBrA 41 Figure 7 - L'architecture générale du Context Management Framework (CMF) 42 Figure 8 - L'architecture globale de la plateforme SOCAM 43 Figure 9 - Vue extérieur d'un composant logiciel 53 Figure 10 Architecture d adaptation dans K-Component 59 Figure 11 Modèle de composants auto-adaptatifs de l architecture ACEEL 60 Figure 12 Stratégie d adaptation dans l architecture SAFRAN 61 Figure 13 - Représentation tridimensionnelle du contexte 74 Figure 14 - Le modèle général du contexte 76 Figure 15 - Exemple d une situation contextuelle 77 Figure 16 - Un exemple d'une entité logicielle 78 Figure 17 - Modélisation d'un service d'une entité logicielle 79 Figure 18 Dépendance en «et» entre services 80 Figure 19 Dépendance en «ou» entre services 80 Figure 20 - Le modèle fonctionnel d'une application médicale 82 Figure 21 - Diagramme de classes d'un modèle fonctionnel 83 Figure 22 - Extrait de la représentation XML du modèle fonctionnel d une application médicale 84 Figure 23 - Modélisation d'un fournisseur de contexte 88 Figure 24 - Modélisation d'un registre de contexte 88 Figure 25 - Modélisation d'un courtier de contexte 89 Figure 26 - Interaction entre l'interface de consommation du contexte et le broker 90 Figure 27 Architecture générale du module d'adaptation de services 91 Figure 28 Architecture générale du module d'adaptation de données 91 Figure 29 - Architecture générale du module d'adaptation de présentation 92 Figure 30 - Orchestration du processus d'adaptation par le gestionnaire d'applications 92 Figure 31 - Architecture générale de SECAS 93 Figure 32 - Principe général de l'adaptation dans SECAS 97 Figure 33 - Exemple d'une règle d'adaptation 99 Figure 34 - Modélisation d'un opérateur d'adaptation fonctionnelle 102 Figure 35 - Entité d'adaptation d'un service initial f 103 Figure 36 - Exemple d utilisation de l'opérateur de projection 104 Figure 37 - Exemple d utilisation de l opérateur de sélection 105 Figure 38 - Exemple d'utilisation de l'opérateur «produit» 106

10 Figure 39 - Exemple d'utilisation de l'opérateur «union» 107 Figure 40 - Exemple d application de l opérateur replaceservice en mode simple 110 Figure 41 - Résultat de l application de l opérateur replaceservice en mode récursif 111 Figure 42 - Algorithme de l'opérateur de remplacement de services 112 Figure 43 - Algorithme de connexion en entrée d'un service isolé 113 Figure 44 - Algorithme de connexion en sortie d'un service isolé 113 Figure 45 - Résultat de l application de l opérateur InsertServiceAfter 114 Figure 46 - Algorithme de l'opérateur insertserviceafter 115 Figure 47 - Résultat de l'application de l'opérateur insertalternativeservice 116 Figure 48 - Algorithme de l'opérateur insertserviceafter 117 Figure 49 - Algorithme de l'opérateur LockService 118 Figure 50 - Algorithme de l'opérateur UnlockService 118 Figure 51 - Algorithme de déploiement d un modèle fonctionnel 119 Figure 52 - Algorithme d'application de règles d'adaptation 119 Figure 53 - Algorithme général de la fonction de préparation de l'adaptation de contenu 123 Figure 54 - Algorithme général d'instanciation des adaptateurs de contenu 124 Figure 55 - Algorithme général de calcul du plan d'adaptation de contenu 124 Figure 56 - Structure générale de l'interface d'interaction avec un service 133 Figure 57 - Fonction de génération de l'interface d'interaction avec les services de l'application 133 Figure 58 - Algorithme de la fonction de génération d'une fenêtre d'interaction avec un service 134 Figure 59 - Algorithme de la fonction de génération de la vue d'une fenêtre 134 Figure 60 - Algorithme de la fonction de génération du panneau d entrée d un service 135 Figure 61 - Algorithme de la fonction de génération du panneau de sortie d un service 135 Figure 62 - Algorithme de la fonction de génération du modèle d'exécution d'un service 136 Figure 63 - Algorithmes des fonctions de navigation dans le modèle fonctionnel à partir d'un service f 136 Figure 64 - Algorithme de la fonction de génération du modèle d'exécution d'un service 137 Figure 65 - Diagramme de cas d utilisation : déploiement d une application 142 Figure 66 - Diagramme de cas d utilisation : utilisation d une application adaptée 143 Figure 67 - Diagramme de cas d utilisation : gestion des comptes des utilisateurs de SECAS 143 Figure 68 - Diagramme de cas d utilisation : gestion des modules de SECAS 144 Figure 69 - Descripteur d'un paramètre d'adaptation de type "serviceoutput" 144 Figure 70 - Descripteur de l opérateur d'adaptation fonctionnelle "projection" 144 Figure 71 - Diagramme d état transition : gestionnaire de déploiement d applications 145 Figure 72 - Diagramme d activités du gestionnaire d adaptation de services 146 Figure 73 - Diagramme d activités du gestionnaire d adaptation de contenu 147 Figure 74 - Diagramme d activités de l adaptateur de services 147 Figure 75 - Diagramme d activités de l adaptateur de contenu 148 Figure 76 - Diagramme d activités du gestionnaire d adaptation de présentation 148 Figure 77 - Diagramme des paquetages de SECAS 149 Figure 78 - Diagramme de classes du paquetage "secas.application" 150

11 Figure 79 - Diagramme de classes du paquetage "secas.application.services" 150 Figure 80 - Diagramme de classes du paquetage "secas.application.data" 151 Figure 81 - Diagramme de classes du paquetage "secas.application.ui" 152 Figure 82 - Diagramme de classes du paquetage "secas.administration" 152 Figure 83 - Diagramme de classes du paquetage "util" 153 Figure 84 - Diagramme de classes du paquetage "context" 153 Figure 85 - Diagramme de classes du paquetage d adaptation de services 154 Figure 86 - Diagramme de classes du paquetage d adaptation de contenu 155 Figure 87 - Diagramme de classes du paquetage d adaptation de présentation 156 Figure 88 - Diagramme de composants de SECAS 157 Figure 89 - Diagramme de déploiement de SECAS 157 Figure 90 - Extrait de la description d un service avant son adaptation 159 Figure 91. Extrait de la description d un adaptateur de service 159 Figure 92 - Interface d administration de la plate-forme SECAS 163 Figure 93 - Visualisation d un dossier de dialyse péritonéale sur un PC standard 164 Figure 94 - Le modèle fonctionnel de l application SICOM avant son adaptation avec SECAS 165 Figure 95 - Première règle d'adaptation de l'application SICOM 165 Figure 96 - Deuxième règle d'adaptation de l'application SICOM 166 Figure 97 - Troisième règle d'adaptation de l'application SICOM 166 Figure 98 - modèle fonctionnel adapté de l'application SICOM 167 Figure 99 - Visualisation du même dossier médical que la figure 93 sur un terminal mobile 168 Figure Exemple de modélisation du contexte par une ontologie 169 LISTE DES TABLEAUX Tableau 1 - Exemples de capteurs de contexte Tableau 2 - Vue de synthèse des approches existantes de modélisation du contexte Tableau 3 - Comparatif des quatres plateformes : Context Toolkit, CoBrA, CMF et SOCAM Tableau 4 Exemples d opérateurs d'adaptation inter-services Tableau 5 - Nombre de classes et de lignes de code dans le prototype SECAS

12 DEDICACE A la mémoire de mes deux grands-pères Mahmoud et Habib

13 REMERCIEMENTS Je tiens à remercier, tout d abord, mes directeurs de thèse, André FLORY et Frédérique LAFOREST, pour leur encadrement ainsi que leur soutien tout au long de la thèse. Je remercie tout particulièrement Mme Florence SÈDES et M. Philippe ANIORTÉ d avoir acceptés d être rapporteurs de mon manuscrit. Je remercie également M. Paul RUBEL d avoir bien voulu présider le jury lors de ma soutenance de thèse ainsi que M. Augusto CELENTANO d avoir accepté d être examinateur de ce travail. Un grand merci à ma femme Kaouthar pour sa présence précieuse et pour ses encouragements durant toutes les périodes et étapes de cette thèse. J adresse aussi un merci spécial à ma famille pour son soutien moral et à tous les collègues et amis qui m ont aidé de près ou de loin à finaliser mon travail de thèse.

14

15 L IINTRODUCTIION GENERALE The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it (Mark Weiser)

16 Introduction générale PLAN I. LES SYSTEMES D INFORMATION PERVASIFS 17 II. LA SENSIBILITE AU CONTEXTE DANS LES SYSTEMES D INFORMATION PERVASIFS 18 III. PROBLEMATIQUE 18 IV. CAS D ETUDE 19 V. ORGANISATION DU DOCUMENT 20 Tarak CHAARI Thèse de doctorat

17 Introduction générale I. LES SYSTEMES D INFORMATION PERVASIFS De nos jours, l évolution technologique des systèmes embarqués et des moyens de communication informatique a incité les développeurs à intégrer les terminaux mobiles dans leurs applications, donnant ainsi naissance à de nouveaux systèmes d information dits pervasifs ou ubiquitaires [Birnbaum97]. Mark Weiser a introduit l informatique pervasive en décrivant l ordinateur du 21 ième siècle [Weiser95] comme un terminal intime ou compagnon actif plus intelligent qu un assistant de bureau comme les ordinateurs standard [Weiser99]. Les travaux de [Agoston00] ont repris les idées initiées par M. Weiser et ont donné la définition des systèmes pervasifs, qui est maintenant la plus reconnue et répandue dans ce nouveau domaine : «l informatique pervasive rend l information disponible partout et à tout moment». A la différence des systèmes d information classiques, ces nouvelles applications intègrent des terminaux mobiles de différentes capacités matérielles et logicielles. Ainsi, avec ces systèmes, le téléphone mobile ne sert plus uniquement à de simples communications vocales ou textuelles. Les assistants personnels ne sont plus de simples gadgets de planning et d organisation. Les ordinateurs de poche ne sont plus isolés de l Internet. Ces appareils interagissent maintenant avec des services implantés sur des serveurs d applications divers. En conséquence, les administrateurs de parcs de machines veulent consulter l état de leur parc depuis leur domicile ou même en voyage avec leur téléphone mobile ; les enseignants veulent consulter leur emploi de temps depuis leur téléphone; le directeur de l entreprise veut accéder aux différents tableaux de bord de son entreprise partout et même en déplacement; l infirmière veut consulter depuis son PDA le dossier d un patient et les recommandations prescrites par le médecin avant de se rendre à son domicile L intégration des terminaux mobiles dans les nouveaux systèmes d information n est pas une tâche aisée. En effet, les applications déjà développées n ont pas été conçues pour être utilisées sur des terminaux qui ont des performances très réduites par rapport à celles des PC standards. La plupart d entre eux ne dépassent pas 30 Mo de mémoire vive et morte réunies. De plus, la bande passante de transmission est faible, ce qui rend les transferts de données plus lents et plus coûteux. En outre, la taille de l écran est considérablement réduite. Enfin, un autre problème majeur est la diversité des API (Application Programming Interface) de développement implantées sur ces terminaux. Tarak CHAARI Thèse de doctorat

18 Introduction générale II. LA SENSIBILITE AU CONTEXTE DANS LES SYSTEMES D INFORMATION PERVASIFS Dans les systèmes d information pervasifs, on doit assurer une adaptation au type de terminal et au type d utilisateur connecté pour garantir une utilisation confortable des applications dans ces nouveaux environnements. Dans la littérature, cette adaptation est aussi appelée plasticité [Calvary02], elle définit le degré d adaptation des applications à de nouvelles situations et à de nouveaux besoins. Pour réaliser cette adaptation, beaucoup de nouveaux paramètres entrent en jeu : - paramètres réseau : dans les réseaux sans fil la bande passante est limitée, les connexions sont intermittentes, la qualité de service n est pas évaluée de la même façon - paramètres de l utilisateur : l utilisateur est devenu le point central de la conception des systèmes d information pervasifs. En effet, des contraintes d utilisabilité et d ergonomie se présentent aux concepteurs de ce genre d application. Ainsi, on doit prendre en considération ses préférences, son emplacement géographique, son profil - paramètres du terminal : la diversité des terminaux mobiles influe sur la conception de ces systèmes d information. Le comportement de ces systèmes doit s adapter aux capacités matérielles et logicielles de ces appareils. Tous ces paramètres forment des contextes d utilisation différents [Shanon90]. Dans la plupart des cas, ces paramètres n ont pas été pris en compte lorsque l application a été développée. Ceci conduit généralement les informaticiens à reprendre leur cycle de vie dès son début pour prendre en compte ces nouveaux paramètres. La prise en compte du contexte d utilisation dans les applications est un domaine de recherche d actualité connu sous le nom de «sensibilité au contexte» (ou context-awareness en anglais) [Abowd99] : une application sensible au contexte doit percevoir la situation de l utilisateur dans son environnement et adapter par conséquent son comportement à la situation en question. III. PROBLEMATIQUE Dey [Dey01a], l un des premiers chercheurs dans le domaine de la sensibilité au contexte, a spécifié trois étapes nécessaires pour qu une application soit sensible au contexte. En premier lieu, on doit capturer le contexte, et ce de manière transparente à l utilisateur. Ensuite, on doit effectuer une interprétation du contexte pour passer à une représentation de haut niveau plus exploitable par l application. Finalement, on doit fournir cette information Tarak CHAARI Thèse de doctorat

19 Introduction générale interprétée à l application. A l image des travaux de Dey, la grande majorité des contributions existantes dans le domaine de la sensibilité au contexte s intéressent à comment capturer, interpréter et apporter les informations contextuelles à l application sans étudier comment l adapter à ces nouveaux contextes d utilisation. De plus, les travaux existants se focalisent sur la création incrémentale ou sur le prototypage d applications sensibles au contexte en incorporant le code d adaptation dans le code métier de l application. Ceci limite les capacités à prendre en compte de nouveaux contextes qui n auraient pas été prévus lors de son développement. La majorité des solutions existantes proposent des approches ad hoc pour des domaines spécifiques (surtout dans le domaine du tourisme). Pour que ces applications puissent supporter d autres environnements et besoins, les informaticiens se trouvent généralement obligés de reprendre tout le cycle de vie de l application afin de fournir une nouvelle version qui supporte les nouveaux contextes d utilisation. Dans ce travail de thèse, nous nous intéressons à une stratégie complète et générique pour garantir l adaptation des applications existantes à différents contextes d utilisation. Cette adaptation se fait en aval du développement de ces applications, en leur ajoutant une surcouche logicielle. Notre stratégie s appuie sur trois volets d adaptation : les services, les données et l interface utilisateur de ces applications. L adaptation des services consiste à modifier leurs comportements pour qu ils soient compatibles avec le contexte d utilisation de l application. L adaptation des données se base sur un ensemble de transformations sur le type, le format et les propriétés des données renvoyées par les services. Enfin, l adaptation des interfaces utilisateur consiste à générer automatiquement une interface homme-machine fonctionnelle dans le contexte de son utilisation. Dans ce mémoire nous présentons notre stratégie d adaptation d applications pervasives dans une approche multi-contextes en se focalisant particulièrement sur l adaptation d applications existantes à de nouveaux contextes d utilisation. Notre approche reste aussi valable et applicable pour la création incrémentale d applications sensibles au contexte. IV. CAS D ETUDE Pour mieux illustrer l objectif de ce travail de thèse, nous utilisons tout le long de ce mémoire, un exemple d application, conçue et développée pour un PC standard, qui doit être utilisée dans un environnement différent comme un PDA ou un téléphone mobile évolué (Smartphone). Nous avons choisi cet exemple car il exprime un besoin d actualité dans les systèmes d information pervasifs. Nous nous appuyons sur une application médicale qui permet la consultation des dossiers de patients suivant un traitement de dialyse péritonéale Tarak CHAARI Thèse de doctorat

20 Introduction générale (traitement pour les patients atteints d insuffisance rénale). Cette application, développée dans le cadre de l hospitalisation de patients à domicile (HAD), offre un ensemble de services aux professionnels de santé qui assurent la recherche et la visualisation des dossiers médicaux de leurs patients. Les utilisateurs de cette application ont exprimé le besoin d accéder à ces mêmes services via des dispositifs mobiles comme les téléphones mobiles ou les PDA. Nous constatons que dans la plupart des cas, il ne suffit pas seulement de développer une autre version (ou un autre client) de ces applications pour les terminaux mobiles. En effet, les résultats obtenus ne sont pas toujours satisfaisants puisque les services offerts par ces systèmes d information peuvent être incompatibles avec les capacités matérielles et logicielles des terminaux mobiles. Dans notre exemple, il existe un service de recherche de dossiers patients. Ce service peut renvoyer un grand nombre de lignes de la base de données médicale. Ces données sont très volumineuses puisqu elles peuvent contenir des images, des vidéos, des rapports médicaux et des résultats d analyse. Ce gros volume de données dépasse les capacités matérielles du terminal utilisé (un téléphone mobile NOKIA 6230) et cause une saturation mémoire au niveau de l application cliente. Les développeurs se trouvent ainsi obligés de recoder l application allant jusqu à ses services de base. Cet exemple montre la nécessité et l intérêt d avoir des systèmes d adaptation automatiques (ou semi-automatiques) des applications existantes à de nouveaux contextes d utilisation. Ceci aide les développeurs à ne pas reprendre tout le cycle de développement des applications et permet ainsi de gagner un temps considérable de conception et de réalisation. Ces nouvelles situations ne se limitent pas au changement du type du terminal mais à tout changement de l environnement de l utilisateur ou de l application qui peut influer sur son comportement en définissant de nouvelles vues sur ses données et ses services. V. ORGANISATION DU DOCUMENT Après cette introduction générale, ce mémoire de thèse comporte trois parties principales : un état de l art, les propositions de notre travail et l implémentation de notre approche. la partie état de l art est composée de deux chapitres : «chapitre 1 : Les systèmes sensibles au contexte» et «chapitre 2 : les travaux d adaptation existants». Le premier chapitre présente le contexte scientifique de notre travail de thèse. Nous y détaillons la notion du contexte, la notion de la sensibilité au contexte et quelques architectures. Le deuxième chapitre est dédié aux différents travaux d adaptation que nous avons considérés comme intéressants pour l adaptation au contexte. Ce chapitre fait un tour d horizon sur les travaux d adaptation existants dans les architectures à base de composants, dans la gestion de contenu Tarak CHAARI Thèse de doctorat

21 Introduction générale multimédia et dans le domaine de l interaction-homme machine. La deuxième partie, qui regroupe l'ensemble de nos contributions, comporte deux chapitres : «chapitre 3 : définitions, modèles et architecture» et «chapitre 4 : stratégie d adaptation au contexte». Le chapitre 3 présente les définitions, les modèles et l architecture que nous avons élaborés pour notre stratégie d adaptation. Cette stratégie est présentée dans le chapitre 4 où nous explicitons le principe de notre approche d adaptation sur ses trois volets : les services, les données et les interfaces utilisateur. La troisième partie «chapitre 5 : implantation et utilisation de notre plateforme d adaptation» présente la conception et l implémentation de notre architecture d adaptation. Nous y présentons aussi l adaptation du cas d étude présenté dans la section IV de cette introduction générale. Le document se termine par une conclusion générale qui présente une synthèse de nos contributions ainsi que les perspectives que nous avons tracées pour la suite de ce travail. Tarak CHAARI Thèse de doctorat

22

23 CHAPIITRE II - ETAT DE L ART : LES SYSTEMES SENSIIBLES AU CONTEXTE Context is a poorly used source of information in our computing environments (Anind K. Dey)

24 Chapitre I Etat de l art : les systèmes sensibles au contexte TABLE DES MATIERES I. INTRODUCTION 25 II. NOTION DE CONTEXTE Que disent les dictionnaires? Contexte et informatique pervasive Catégories de contexte 27 III. NOTION DE SENSIBILITE AU CONTEXTE (CONTEXT-AWARENESS) 29 IV. ARCHITECTURE D UN SYSTEME SENSIBLE AU CONTEXTE Couche de capture du contexte Couche d Interprétation et d agrégation du contexte Couche de stockage et historique du contexte Couche dissémination du contexte Couche application 37 V. PRINCIPALES PLATEFORMES EXISTANTES DE SENSIBILITE AU CONTEXTE Context Toolkit Context Broker Architecture (CoBrA) Context Management Framework (CMF) Service oriented context-aware middleware (SOCAM) Synthèse 44 VI. CONCLUSION 46 Tarak CHAARI Thèse de doctorat

25 Chapitre I Etat de l art : les systèmes sensibles au contexte I. INTRODUCTION Dans ce chapitre, nous nous intéressons aux travaux existants dans les systèmes sensibles au contexte. Nous commençons par présenter les différentes définitions de la notion de contexte et les principes de la sensibilité au contexte (ou context-awareness). Nous présentons ensuite l'architecture générale d'un système sensible au contexte tirée d'une synthèse des travaux existants. Dans le section V, nous analysons quelques plateformes existantes qui aident au développement et au déploiement de ce genre de systèmes. Dans la conclusion de ce chapitre, nous présentons l importance de l étape d adaptation dans les applications sensibles au contexte. Nos constatations tirés de la synthèse des travaux existants dans ce domaine montrent que cette étape mérite plus d intérêt et plus d études. II. NOTION DE CONTEXTE 1. Que disent les dictionnaires? Parmi les dictionnaires de référence nous citons les définitions suivantes de la notion de contexte : Le Petit Robert : "ensemble des circonstances dans lesquelles s'insère un fait". L'encyclopédie Larousse : "ensemble des conditions naturelles, sociales, culturelles dans lesquelles se situe un énoncé, un discours"; ou encore : "ensemble des circonstances dans lesquelles se produit un événement, se situe une action". Hachette Multimédia : "ensemble des éléments qui entourent un fait et permettent de le comprendre". Le Grand dictionnaire numérique en ligne [Granddictionnaire]: "Énoncé dans lequel figure le terme étudié". Si l'on parle d'informatique, "Le contexte est un ensemble d'informations concernant l'action du stylet, en rapport principalement avec sa localisation à l'écran, qui permet au système d'exploitation de l'ordinateur à stylet de différencier les commandes et l'entrée des données, et de fonctionner en conséquence." Ces définitions partagent l'idée d'ensemble d'informations associé à quelque chose : "ensemble [ ] qui entoure", "ensemble dans lequel se situe ". La nature du "quelque chose" (fait, discours, événement, action, etc.), dépend précisément de l'utilité du contexte. Cette utilité permet de "comprendre", de "fonctionner en conséquence", ou de donner un "sens, [une] valeur ", ou de manière générique de "servir l'interprétation". Nous abordons maintenant la notion de contexte dans le domaine de l'informatique pervasive. Tarak CHAARI Thèse de doctorat

26 Chapitre I Etat de l art : les systèmes sensibles au contexte 2. Contexte et informatique pervasive Dans le domaine de l'informatique pervasive ou ambiante, la notion de contexte prend beaucoup d'ampleur et attire l'attention de plusieurs chercheurs. Schilit et Theimer [Schilit94a] étaient les premiers à proposer une définition du contexte comme étant la localisation de l'utilisateur, les identités et les états des personnes et objets qui l'entourent. Dans une définition semblable, Brown, Bovey et Chen [Brown97] proposent : "le contexte est l'identité de l'utilisateur, des personnes et objets qui l'entourent, sa localisation géographique, son orientation, la saison, la température où il évolue...". Ryan, Pascoe, et Morse [Ryan98] définissent le contexte en tant que la localisation, l'environnement, l'identité, et le temps de l'utilisateur. Dey [Dey00] présente le contexte comme l'état émotionnel de l'utilisateur, son centre d'attention, sa localisation, son orientation, la date et le temps où il évolue, les objets et les gens qui existent dans son environnement. Il est difficile d'appliquer ces définitions dans tous les cas. En effet, si on considère un nouveau type potentiel d'information de contexte, il n'est pas évident de le classer en tant que contexte ou non. Le contexte, selon Schilit, inclut la localisation et l'identité des personnes et des objets à proximité ainsi que les modifications pouvant intervenir sur ces objets [Schilit94a], [Schilit94b]. Étudier le contexte, c'est répondre aux questions "On est où? ", "Avec qui?", "Quelles sont les ressources qu'on utilise?" Il définit donc le contexte comme les changements de l'environnement physique, de l'utilisateur et des ressources de calcul. Brown [Brown96] restreint le contexte aux éléments de l'environnement de l'utilisateur, puis il introduit l'heure, la saison, la température, l'identité et la localisation de l'utilisateur [Brown97]. Parallèlement aux travaux de Brown, des définitions émergent avec l'introduction explicite du temps et la notion d'état. Ryan assimile le contexte à l'environnement, l'identité et la localisation de l'utilisateur ainsi que le temps [Ryan97]. Ward voit le contexte comme les états des environnements possibles de l'application [Ward97]. En 1998, Pascoe définit le contexte comme un sous-ensemble d'états physiques et conceptuels ayant un intérêt pour une entité particulière [Pascoe98]. Nous relevons ici la référence à la notion de pertinence. Puis Dey [Anind99] insiste sur cette notion de pertinence de l'information en proposant une définition où il essaie de préciser la nature des entités relatives au contexte : Tarak CHAARI Thèse de doctorat

27 Chapitre I Etat de l art : les systèmes sensibles au contexte Le contexte couvre toutes les informations pouvant être utilisées pour caractériser la situation d'une entité. Une entité est une personne, un lieu, ou un objet qui peut être pertinent pour l'interaction entre l'utilisateur et l'application, y compris l'utilisateur et l'application. Cette définition encapsule toute les autres définitions précédentes puisqu'elle est d'ordre très générique. Dey explique cette généricité du fait que les paramètres du contexte peuvent être implicites ou explicites. En effet, les paramètres du contexte peuvent être fournis directement par l'utilisateur ou par des capteurs situés dans l'environnement de l'utilisateur et de l'application comme ils peuvent parvenir d'une interprétation plus ou moins complexe de ces paramètres. Dey a veillé à ce que sa définition englobe toute donnée implicite ou explicite qui peut être utile à l'application. En 2001, Winograd [Winograd01] approuve la définition donnée par Dey et affirme qu'elle couvre tous les travaux existants sur le contexte. Cependant, il considère que l'utilisation d'expressions comme "toute information" et "caractériser une entité" reste d'ordre très général et ne trace aucune limite à la notion de contexte (tout peut être contexte). Pour apporter plus de précision par rapport à la définition de Dey, Winograd propose : le contexte est un ensemble d'informations. Cet ensemble est structuré et partagé ; il évolue et sert l'interprétation. Il détaille cette définition en disant : "La considération d'une information comme contexte est due à la manière dont elle est utilisée et non à ses propriétés inhérentes". Il appuie cette idée par l'exemple : "le voltage des lignes d'électricité fait partie du contexte si le système en dépend; sinon, il ne peut être qu'un paramètre quelconque de l'environnement". Nous considérons que cette définition de Winograd est plus utile pour l'exploitation du contexte dans les applications. Nous avons repris les principes de cette définition et nous avons apporté encore plus de précisions pour tracer des limites entre les données propres à l'application et son contexte d'utilisation. Nous détaillons notre vision de la notion de contexte dans le chapitre III. 3. Catégories de contexte Etant donnée la diversité des informations composant le contexte, il est utile d'essayer de les classer par catégorie pour faciliter leur utilisation. Dans cette section, nous présentons une classification qui synthétise les informations contextuelles utilisées dans les solutions existantes. Les entités principales concernées par la notion de contexte sont des lieux, des personnes ou des objets. Les lieux sont des régions d'espaces géographiques comme des Tarak CHAARI Thèse de doctorat

28 Chapitre I Etat de l art : les systèmes sensibles au contexte chambres, des bureaux, des bâtiments, des rues ou des zones bien définies. Les personnes peuvent êtres des individus ou des groupes d'individus rassemblés ou répartis. Les objets peuvent êtres des entités physiques, des composants logiciels ou des artefacts (applications, fichiers, ressources ). Nous classons les informations contextuelles utilisées dans la majorité des travaux existants en quatre catégories principales : identité, localisation, état (ou activité) et temps. L'identité se réfère à la capacité d'assigner un unique identifiant à une entité. Cet identifiant doit être unique dans l'espace de nommage utilisé par les applications. La localisation ne se limite pas à la position 2D des objets et des personnes. En effet, elle peut concerner l'orientation, l'altitude et les relations spatiale entre les entités (comme les relations de proximité, de co-existance et de contenance). Par exemple, le fait qu'un objet A est orienté vers un objet B ou un autre objet C est une information qui peut être classé dans la catégorie localisation. La localisation peut aussi référencer des lieux. Ces lieux peuvent être identifiés par leurs emplacements géographiques absolus ou relatifs par rapport à des objets de référence. La catégorie état ou activité encapsule les caractéristiques intrinsèques des entités qui interviennent dans le système. Par exemple, pour un lieu, l'état peut caractériser la température ambiante, la quantité de lumière existante ou le niveau de bruit courant. Pour une personne, l'état peut se référer à ses signes vitaux, sa fatigue ou son activité (par exemple, il est en train de conduire, lire, marcher, courir ). Pour les composants logiciels, l'état est tout attribut ou caractéristique qui peut être obtenue suite à une requête. Des exemples typiques de ces caractéristiques sont le temps de réponse d'un service, son taux d'utilisation, son état (disponible, activé, désactivé ). Finalement, le temps peut aussi être une information contextuelle car il peut caractériser une entité. Le temps permet aussi d'établir un historique de valeurs permettant d'enrichir le contexte. En effet, l'enchaînement et l'ordonnancement d'actions ou d'évènements dans le temps peuvent aussi être importants pour la décision prise par l'application. Les données encapsulées par ces quatre catégories peuvent être interprétées ou corrélées pour obtenir des informations contextuelles supplémentaires afin de garantir une évaluation plus étendue d'une situation. Par exemple, en connaissant dans une salle, le nombre de personnes, leurs positions relatives et la quantité de bruit, on peut déterminer s'ils sont en conférence ou non. Les différentes catégories que nous avons identifiées dans les travaux existants peuvent être utilisées de différentes manières pour assurer la sensibilité au contexte dans une Tarak CHAARI Thèse de doctorat

29 Chapitre I Etat de l art : les systèmes sensibles au contexte application. Nous détaillons dans le paragraphe suivant cette notion de "sensibilité de contexte". III. NOTION DE SENSIBILITE AU CONTEXTE (CONTEXT- AWARENESS) La notion de sensibilité au contexte concerne l'utilisation du contexte dans les applications. Cette notion est une traduction de l'expression anglaise "context-awareness". Elle caractérise la capacité d'un système à s'adapter aux changements du contexte. Selon Dey et Abowd, un système est sensible au contexte s'il utilise le contexte pour fournir des informations et des services pertinents pour l'utilisateur, où la pertinence dépend de la tâche demandée par l'utilisateur [Dey00]. Cette définition d'un système sensible au contexte a été adoptée par tous les chercheurs dans ce domaine. Elle a mis en évidence trois catégories de fonctions liées à la présentation d'information, à l exécution de services et au stockage d'informations selon le contexte. La première catégorie, présentation d'information et services, se rapporte aux applications qui présentent des informations du contexte. Ces applications peuvent proposer des choix d'actions appropriées à l'utilisateur. Il y a plusieurs exemples de ce type de travaux dans la littérature et dans quelques systèmes commercialisés. Par exemple, nous pouvons trouver des applications pour montrer la localisation de l'utilisateur ou de son véhicule sur une carte. Elles peuvent aussi proposer des icones (ou des alertes) des centres d'intérêts voisins de l'utilisateur [Abowd97], [Bederson95], [Davies98], [Feiner97], [Fels98], [McCarthy99], [McCarthy00]). Nous pouvons aussi citer les travaux de [Schilit94] qui présentent la liste des imprimantes proches de l'utilisateur. Nous pouvons aussi trouver d'autres études sur la présentation d'informations dans des systèmes ambiants [Heiner99], [Ishii97], [Mynatt98], [Weiser97]. La deuxième catégorie, exécution automatique de services, décrit les applications qui déclenchent une commande, ou reconfigurent le système à la place de l'utilisateur selon les changements de contexte. Dans cette catégorie nous pouvons citer : le système Teleport qui assure le transport automatique de profil utilisateur lorsqu'il passe d'une machine à une autre [Bennett94], un système d'enregistrement automatique de son quand une réunion ou un rassemblement non planifié se passe dans un certain lieu [Brotherton99], des téléphones mobiles qui changent leurs comportement et leurs configurations (vibreur/sonnerie) selon l'environnement de l'utilisateur [Harrison98], un système de sécurité portable qui détecte si l'utilisateur est effrayé en utilisant des capteurs biométriques [Healey98], et des dispositifs qui Tarak CHAARI Thèse de doctorat

30 Chapitre I Etat de l art : les systèmes sensibles au contexte fournissent des signaux de rappel quand les utilisateurs sont à un lieu précis ([Beigl00] et [Marmasse00]). Dans la troisième catégorie s intéressant au stockage d'information selon le contexte, les applications associent des données au contexte de leur utilisation. Par exemple, dans une conférence, une application étiquette des notes prises par l'utilisateur avec le lieu et le temps de l'observation [Pascoe98]. Dans des domaines similaires, Time-Machine Computing [Rekimoto99] et Placeless Documents [Dourish00] sont deux systèmes qui attachent l'identité des utilisateurs, leurs lieux et le temps de création et d'utilisation de ressources logicielles afin de pouvoir les utiliser d'une façon plus facile et rapide ultérieurement. D'autres exemples plus complexes dans cette catégorie sont des applications d'aide-mémoire telles que Forget-Me- Not [Lamming94] et Rememberance Agent [Rhodes97]. Malgré tous ces travaux, le domaine de la sensibilité de contexte est loin d'être au point. En effet, plusieurs éléments sont encore à approfondir et à étudier. Winograd a déjà énuméré trois lacunes dans ce domaine : (i) la notion de contexte n'est pas encore bien définie; (ii) les travaux existants manquent de modèles et de méthodes conceptuelles; (iii) il n'y a pas d'outils disponibles pour le développement et l'hébergement d'applications sensibles au contexte. Dans le paragraphe suivant, nous détaillons l'architecture générale et les fonctions qu'un système doit accomplir pour qu'il puisse être sensible au contexte. IV. ARCHITECTURE D UN SYSTEME SENSIBLE AU CONTEXTE La conception des applications sensibles au contexte soulève de nouveaux défis. En effet, la manipulation du contexte est difficile pour différentes raisons : (1) les méthodes classiques de développement des logiciels sont difficiles à appliquer sur les applications sensibles au contexte; (2) les solutions proposées pour ce genre d'applications sont soit spécifiques à un besoin précis soit elles manquent d'abstraction lors de leur conception (3) la capture du contexte est souvent distribuée et mène à des conceptions complexes. Dey [Dey99] a été le premier à proposer une séparation entre l'acquisition de contexte et son utilisation dans les applications. Il s'appuie sur une étude de nouvelles méthodes de conception des systèmes interactifs mobiles où la séparation entre l'application d'une part et le nouveau monde d'interfaces, d'icones, de menus, de pointeurs et de moyens d'interaction sur les terminaux mobiles d'autre part. Dans les applications sensibles au contexte, on est confronté à des problèmes similaires à ceux rencontrés lors du développement des systèmes interactifs mobiles. Pour cette raison, Dey pense qu'il est utile de séparer la gestion du contexte de l'application, afin de pouvoir Tarak CHAARI Thèse de doctorat

31 Chapitre I Etat de l art : les systèmes sensibles au contexte développer une plateforme générique de développement et déploiement d'applications sensibles au contexte. La seule chose qui différencie, selon Dey, une application sensible au contexte d'un système interactif mobile est que ce dernier manipule des données explicites qui sont soit des variables internes de l'application soit des entrées explicites de l'utilisateur. Dey a proposé une plateforme semblable aux systèmes interactifs tout en généralisant les types d'entrées pour prendre en compte des données implicites déduites de l'environnement de l'utilisateur (données du contexte). Inspiré par des concepts utilisés dans des outils d'interaction, Dey a défini quelques abstractions [Dey99] qui aident à inférer une interprétation de haut niveau du contexte, et qui supporte la séparation entre la gestion du contexte et l'application. Cette idée a été reprise par la majorité des travaux actuels [Matthias07] dans le domaine de la sensibilité au contexte, proposant ainsi des architectures à plusieurs couches. Ces architectures diffèrent dans les fonctions, les noms et l'emplacement de leurs couches. Cependant, nous remarquons que toutes ces propositions se basent sur cinq couches principales : capture du contexte, interprétation/agrégation du contexte, stockage/historique du contexte, dissémination du contexte et application (figure 1). Dans les paragraphes suivants, nous détaillons les fonctions de ces cinq couches et leurs différents éléments. Application Dissémination Stockage/Historique Interprétation / Agrégation Capture Figure 1 - Architecture générale d'un système sensible au contexte 1. Couche de capture du contexte La première couche d'une architecture sensible au contexte est composée d'une collection de capteurs. Un capteur est une source matérielle ou logicielle qui peut générer une information contextuelle. Nous distinguons trois types de capteurs : physiques, virtuels et logiques [Indulska03]. 1.1 CAPTEURS PHYSIQUES Les capteurs physiques sont des dispositifs matériels qui sont capables de fournir des Tarak CHAARI Thèse de doctorat