Adaptation d applications pervasives dans des environnements multi-contextes

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)

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.

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.

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 25 1. Que disent les dictionnaires? 25 2. Contexte et informatique pervasive 26 3. Catégories de contexte 27 III. Notion de sensibilité au contexte (Context-Awareness) 29 IV. Architecture d un système sensible au contexte 30 1. Couche de capture du contexte 31 2. Couche d Interprétation et d agrégation du contexte 33 3. Couche de stockage et historique du contexte 33 4. Couche dissémination du contexte 36 5. Couche application 37 V. Principales plateformes existantes de sensibilité au contexte 37 1. Context Toolkit 38 2. Context Broker Architecture (CoBrA) 39 3. Context Management Framework (CMF) 42 4. Service oriented context-aware middleware (SOCAM) 43 5. Synthèse 44 VI. Conclusion 46

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 49 1. Définition 49 2. Utilité 50 3. Caractérisation 50 III. L adaptation dans les architectures à base de composants 53 1. Concepts de la programmation à base de composants 53 2. Mécanismes d adaptation existants 54 3. Techniques d'adaptation de composants 56 4. Quelques architectures existantes d adaptation de composants 58 5. Synthèse sur l'adaptation des architectures à base de composants 61 IV. Adaptation de contenu multimédia 61 1. Adaptation coté serveur 62 2. Adaptation coté client 62 3. Adaptation intermédiaire 62 4. Synthèse sur les approches d'adaptation de contenu 63 V. Adaptation des interfaces utilisateur 64 1. Modélisation des interfaces utilisateurs 64 2. Adaptation des interfaces homme-machine 66 3. 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 71 1. Définition du contexte 71 2. Notion de situation contextuelle 73 3. Modélisation d une situation contextuelle 75 III. Modélisation fonctionnelle d une application 78 1. Notion d entité logicielle 78 2. Notion de service 79 3. Notion de dépendance d exécution de services 80 4. Notion de modèle fonctionnel 81 IV. Objectifs de notre travail 85

V. SECAS : Plateforme pour l adaptation d applications à de nouveaux contextes d utilisation 87 1. Présentation de la plateforme SECAS 87 2. Couche de gestion du contexte 87 3. Couche d adaptation 89 4. 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 98 1. Principe de l adaptation fonctionnelle 98 2. Règles d adaptation fonctionnelle 99 3. Opérateurs d adaptation fonctionnelle 101 4. Processus d adaptation fonctionnelle dans SECAS 118 5. Synthèse sur l adaptation fonctionnelle dans SECAS 120 III. Adaptation de contenu 120 1. Principe de l adaptation de contenu 120 2. Module d adaptation de contenu 122 3. Planification de l adaptation de contenu [Berhe05] 124 4. Synthèse sur l adaptation de contenu dans SECAS 129 IV. Adaptation de présentation 129 1. Principe de l adaptation de présentation 129 2. Modélisation d une interface utilisateur dans SECAS 130 3. Processus de génération automatique d interfaces adaptées 133 4. 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 141 1. Modélisation fonctionnelle 141 2. Modélisation dynamique 145 3. Modélisation statique 149

4. Déploiement de la plateforme 156 5. Scénario générique d utilisation de SECAS 157 III. Développement de la plateforme SECAS 159 1. Implantation de la couche d adaptation fonctionnelle 159 2. Implantation de la couche d adaptation de contenu 160 3. Implantation de la couche d adaptation de présentation 161 4. Statistiques 161 IV. Utilisation de SECAS dans le projet SICOM 161 1. Déploiement de SICOM avec l interface d administration de SECAS 162 2. 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

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

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

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 100 - Exemple de modélisation du contexte par une ontologie 169 LISTE DES TABLEAUX Tableau 1 - Exemples de capteurs de contexte... 32 Tableau 2 - Vue de synthèse des approches existantes de modélisation du contexte... 36 Tableau 3 - Comparatif des quatres plateformes : Context Toolkit, CoBrA, CMF et SOCAM... 45 Tableau 4 Exemples d opérateurs d'adaptation inter-services... 109 Tableau 5 - Nombre de classes et de lignes de code dans le prototype SECAS... 161

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

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.

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)

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 - 16 - Thèse de doctorat

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 - 17 - Thèse de doctorat

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 - 18 - Thèse de doctorat

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 - 19 - Thèse de doctorat

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 - 20 - Thèse de doctorat

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 - 21 - Thèse de doctorat

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)

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

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 - 25 - Thèse de doctorat

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 - 26 - Thèse de doctorat

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 - 27 - Thèse de doctorat

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 - 28 - Thèse de doctorat

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 - 29 - Thèse de doctorat

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 - 30 - Thèse de doctorat

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 - 31 - Thèse de doctorat

Chapitre I Etat de l art : les systèmes sensibles au contexte données de contexte. Le tableau 1 donne quelques exemples de capteurs physiques selon le type d'information qu'ils fournissent. Type d'information fournie Capteurs disponibles Lumière Photodiodes, capteurs de couleurs, capteurs d'infrarouge et d'ultra violet Contexte visuel Caméras numériques Audio Microphones GPS (Global Positionning System), GSM (Global Localisation System for Mobile Communications), Active Badge System [Want92] Mouvements et accélérations capteurs d'angles, accéléromètres, détecteurs de mouvement, champs magnétiques Température Thermomètres numériques Caractéristiques biologiques Capteurs Biométriques (Tension, résistance de peau ) Tableau 1 - Exemples de capteurs de contexte 1.2 CAPTEURS VIRTUELS Les capteurs virtuels fournissent des informations contextuelles à partir d'applications ou services logiciels. Par exemple, il est possible de détecter l'emplacement d'un livreur de marchandise en consultant son carnet électronique de rendez-vous sans avoir recours à des capteurs physiques. Nous pouvons aussi détecter l'activité de l'utilisateur sur un microordinateur en analysant les évènements de la souris ou les saisies à partir du clavier. Les capteurs virtuels sont beaucoup moins couteux que les capteurs physiques puisqu'ils sont basés sur des composants logiciels qui sont généralement moins chers que des appareils électroniques. 1.3 CAPTEURS LOGIQUES Ce type de capteurs utilise généralement plusieurs sources d'information contextuelles pour fournir une autre information de synthèse plus précise. Ces capteurs peuvent réutiliser des capteurs physiques et virtuels pour fournir un contexte de plus haut niveau. Par exemple, un capteur logique peut fournir l'emplacement d'un caissier dans un grand magasin en analysant les différentes sessions ouvertes sur les caisses du magasin. Dans certain travaux, les capteurs logiques sont considérés comme des interpréteurs de contexte (voir section IV.2). Chaque type de capteur doit être attaché à un composant logiciel permettant l'accès aux informations capturées. Ces composants sont généralement fournis avec des pilotes logiciels (drivers) et une API de communication avec les capteurs. Des interfaces génériques de communication permettent de garantir un accès transparent aux informations capturées [Bauer98]. Par exemple, une interface getposition(), qui retourne la position d'un capteur en mouvement peut être implémentée en utilisant un système GPS ou un système de localisation Tarak CHAARI - 32 - Thèse de doctorat

Chapitre I Etat de l art : les systèmes sensibles au contexte GSM. 2. Couche d Interprétation et d agrégation du contexte Cette couche offre des moyens d'interprétation des données contextuelles fournies par les capteurs du contexte. Elle sert à l'analyse et à la transformation des données brutes fournies par la couche de capture du contexte dans d'autres formats de haut niveau qui sont plus faciles à manipuler et à utiliser. En effet, les capteurs fournissent généralement des données techniques qui ne sont pas appropriées pour une utilisation directe par l'application. Les transformations effectuées sur les données brutes fournies par les capteurs peuvent être réalisées par plusieurs opérations : extraction, quantification, raisonnement, agrégation... Par exemple, les coordonnées GPS d'une personne peuvent être moins significatives qu'une adresse physique sous forme de numéro de rue et de ville. La complexité des interprétations de contexte peut varier d'une simple agrégation de valeurs qui proviennent de plusieurs capteurs à des raisonnements ou analyses statistiques complexes. Par exemple, la localisation de plusieurs personnes dans une seule salle peut inférer le fait qu'ils sont en réunion. Dans ce cas, le niveau de bruit peut aussi être une information importante pour savoir s'ils sont en réunion de travail ou de loisir. Cette couche doit aussi assurer la résolution de conflits causés par l'utilisation de plusieurs sources de contexte. En effet, ces sources peuvent donner des résultats contradictoires ou peuvent aboutir à des situations imprécises. Cette couche doit donc avoir une certaine intelligence d'interprétation pour résoudre ces conflits [Dey98], [Kiciman00]. 3. Couche de stockage et historique du contexte La troisième couche "stockage et historique du contexte" organise les données capturées et interprétées et les stocke pour une utilisation ultérieure. Ce stockage peut être centralisé ou distribué. La solution centralisée est l'option la plus répandue et la plus utilisée puisqu'elle facilite la gestion des mises à jours et des variations des valeurs du contexte. La gestion distribuée du contexte est beaucoup plus complexe puisqu'elle inflige des fonctions additionnelles de découvertes de ressources et d'actualisation des valeurs du contexte. De plus, cette gestion distribuée alourdit la tâche de l'application qui doit gérer la collecte des différentes informations contextuelles d'une façon interne. Pour stocker une information, nous avons besoin de définir un modèle pour la décrire. Ainsi, un modèle de contexte est requis pour pouvoir l'utiliser dans l'application. Strang et Linnhoff-Popien [Linnhoff04] ont résumé les approches de modélisation de contexte les plus Tarak CHAARI - 33 - Thèse de doctorat

Chapitre I Etat de l art : les systèmes sensibles au contexte intéressantes de la littérature. Ils ont proposé une classification des approches de modélisation basée sur la structure de données utilisée pour la description et l'échange du contexte. Nous présentons ces approches en trois catégories par degré de complexité de leur structure de données : les modèles Attribut/Valeur, les modèles basés sur XML et les modèles basés sur les ontologies. 3.1 MODELES ATTRIBUT-VALEUR Plusieurs architectures présentent le contexte sous forme de paires (attribut, valeur). L'attribut représente un nom d'une information contextuelle. La valeur représente la valeur actuelle de cette information. Par exemple, (Name="context1", User="doctorEH102", Localisation="Edouard Herriot Hospital", Time="Mon Jul 09 16:51:20 CEST 2007"). Le contexte context1 est défini par "l utilisateur x est localisé dans un emplacement y à un temps t". Cette méthode présente l avantage de la facilité d implantation. En effet, la gestion du contexte revient à parcourir la liste des contextes disponibles. Cependant, ce modèle manque d expression et de complétude. En effet, sa structure trop «plate» ne permet pas de définir tous les aspects contextuels de l application. Ce genre de modèle est aussi une source de conflits. Par exemple, si nous définissons un nouveau contexte (Name="context2", User="x", Localisation="z", Time="t") avec l emplacement z est dans y (par exemple z="chambre 220" et y="hôpital Edouard Herriot"), on ne peut pas dire que context2 est un sous contexte de context1 et que toutes les fonctionnalités offertes par l application dans context1 doivent aussi exister dans context2. 3.2 MODELES BASES SUR XML Les modèles basés sur XML utilisent une structure de données hiérarchique. La profondeur de cette structure dépend du contexte décrit. Les langages à base de profils sont largement utilisés dans cette catégorie de modèles. Par exemple, nous pouvons citer le profil CC/PP (Composite Capabilities / Preference Profile) [W3C04] et le profil UAProf (User Agent Profile) [Wapforum]. La figure 2 montre un exemple CC/PP utilisé pour la modélisation de la localisation de l utilisateur [Indulska03] : [LocationProfile [PhysicalLocation [Country, State, City, Suburb]] [LogicalLocation [IPAddress]] [GeodeticLocation [Longitude, Latitude, Altitude]] [Orientation [Heading, Pitch]] ] Figure 2 - Modélisation de la localisation de l'utilisateur en utilisant CC/PP Plusieurs autres exemples basés sur le langage XML avec un encodage RDF [Lassila99] Tarak CHAARI - 34 - Thèse de doctorat

Chapitre I Etat de l art : les systèmes sensibles au contexte peuvent être trouvés dans l'article [Linnhoff04]. 3.3 MODELES BASES SUR LES ONTOLOGIES Les ontologies représentent une autre solution pour modéliser le contexte [Chen03]. [Costa03] justifie l utilisation des ontologies par trois arguments: - Une ontologie permet de partager les connaissances dans un système distribué - Une ontologie comprend des sémantiques déclaratives permettant d élaborer des raisonnements sur les informations contextuelles - Avec une représentation explicite d une ontologie commune, l interopérabilité des applications et des terminaux est assurée. En utilisant les ontologies, le mapping utilisateur/services pertinents pour un contexte donné (comme la localisation, activités ) est réalisé d une manière (semi-)automatique. Le filtrage automatique de messages selon les contextes est un exemple d application intéressante dans cette vision. CoOL [Strang03] est un exemple de langage de description de contexte utilisant les ontologies. Il considère qu une information du contexte a un certain aspect (ou représentation) et représente une certaine entité. La figure 3 décrit la position géographique (information du contexte) représentée par les coordonnées de Gauss-Krueger (aspect ou représentation) relative à un téléphone mobile (entité). <instance xmlns=http://demo.heywow.com/schema/cool xmlns:a=http://demo.heywow.com/schema/aspects xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"> <contextinformation> <entity system="urn:phonenumber">+49-179-1234567</entity> <characterizedby> <aspect name="gausskruegercoordinate"> <observedstate xsi:type="a:o2gausskruegertype">367032533074</observedstate> <units>10m</units> </aspect> <certaintyofobserver>90</certaintyofobserver> </characterizedby> </contextinformation> </instance> Figure 3 - Exemple de représentation XML du contexte en utilisant l'ontologie CoOL 3.4 SYNTHESE SUR LES MODELES DE CONTEXTE Les trois approches de modélisation du contexte citées dans cette section présentent chacune des avantages et des inconvénients. La première approche utilise un modèle très simple à implémenter mais sa structure trop «plate» ne permet pas de définir tous les aspects contextuels de l application. Ce genre de modèles peut aussi être une source de conflits. La Tarak CHAARI - 35 - Thèse de doctorat

Chapitre I Etat de l art : les systèmes sensibles au contexte deuxième approche présente un modèle plus structuré et plus organisé. Il reste aussi facile à implémenter mais n'atteint pas la richesse et le degré d'expressivité des ontologies. Cependant la troisième approche basée sur les ontologies reste complexe à implanter dans des cas réels. De notre point de vue, une ontologie est le résultat d'un consensus général. Le domaine de la sensibilité au contexte est encore très effervescent où les points de vue divergent encore. Ainsi, nous considérons que l'utilisation d'une ontologie pour modéliser le contexte est un objectif très ambitieux dans l'état actuel du domaine de la sensibilité au contexte. Le tableau 2 présente une vue de synthèse sur les approches de modélisation du contexte en présentant leurs avantages et leurs inconvénients sur trois critères : (1) le degré d'expression et la richesse sémantique, (2) la facilité d'implantation technique et (3) la résistance du modèle aux conflits. degré d expression et Facilité Modèle\caractéristique Résistance aux conflits richesse sémantique d implantation Paires d Attribut/valeur - + - Extension de CC/PP + + - Ontologies + - + Tableau 2 - Vue de synthèse des approches existantes de modélisation du contexte 4. Couche dissémination du contexte Cette couche assure la transmission des différentes informations contextuelles à l'application. Ces informations sont distribuées sur différents lieux géographiques et proviennent de plusieurs types de dispositifs, comme présenté dans le paragraphe 1 de cette section. Ceci a poussé les chercheurs à dédier une couche à la transmission des données à l'application. Cette couche assure une transparence totale de la communication avec l'application. En conséquence, le développement de l'application devient plus simple. Sans cette couche, on serait amené à développer des protocoles de communications avec les différentes sources de contexte. La couche de dissémination du contexte offre des moyens de communication standards pour notifier l'application des changements de contextes et leur transmission à l'application. Plusieurs systèmes offrent des mécanismes de gestion d'évènements qui se basent essentiellement sur les fonctions de gestion de requêtes directes ou de notification [Bauer98]. L'application peut demander un accès direct à une information contextuelle précise (pull) mais elle peut aussi s'abonner pour recevoir tous les changements des valeurs de cette information (publish/subscribe). Ces deux fonctions principales assurent un moyen de communication transparent et efficace pour la dissémination des valeurs de contexte à l'application [Rodden98]. L'implantation de ces types de communication est Tarak CHAARI - 36 - Thèse de doctorat

Chapitre I Etat de l art : les systèmes sensibles au contexte nécessaire pour garantir la sensibilité au contexte dans une application. 5. Couche application La couche application dans les systèmes sensibles au contexte existants [Chen03] est représentée par l'application qui offre ses services aux différents clients concernés. Cette couche est responsable de l'extraction des informations des différents sources de données attachées à l'application. Elle doit aussi implémenter les réactions nécessaires aux changements du contexte. Chaque application s'abonne à la couche de dissémination du contexte pour accéder aux différentes informations contextuelles et être informée de leurs changements. Une application peut accéder à ces informations de deux façons différentes : synchrone et asynchrone. Dans le cas d'un accès synchrone, l'application demande à la couche de dissémination de lui fournir une information contextuelle précise. Ceci est réalisé généralement par des appels directs de fonctions au niveau de la couche dissémination. Dans le cas de la communication asynchrone, l'application s'abonne à des évènements spécifiques qui correspondent à des changements de valeurs de contexte. Dès qu'un événement est déclenché, l'application est simplement notifiée ou bien l'un de ses services est directement invoqué en utilisant des fonctions de callback implémentées dans la couche dissémination (par exemple, la technique de callback dans CORBA [CORBA02]). Les architectures existantes ne détaillent pas cette couche et insistent sur le fait que la réalisation de cette couche dépend du domaine de l'application et que les services implémentés dépendent fortement de la nature et du besoin des utilisateurs de l'application. Cependant, aucune des architectures proposées ne présente une stratégie complète précisant comment l'application peut s'adapter aux différentes variations du contexte. L'adaptation de l'application au contexte capturé n'est pas une priorité dans ces études. Avant de présenter les travaux d adaptation existants dans d autres domaines, nous présentons, dans la section V de ce chapitre, notre étude des quatre architectures de référence dans le domaine de la sensibilité au contexte. V. PRINCIPALES PLATEFORMES EXISTANTES DE SENSIBILITE AU CONTEXTE Dans cette section, nous présentons quatre implémentations de référence de plateformes sensibles au contexte. Nous analysons les approches abordées par chaque plateforme pour implémenter les couches principales d'un système sensible au contexte. Nous nous intéressons spécifiquement aux plateformes suivantes: - Context Toolkit [Dey01b] qui est un outil pour le développement et le déploiement Tarak CHAARI - 37 - Thèse de doctorat

Chapitre I Etat de l art : les systèmes sensibles au contexte d'applications sensibles au contexte. - Context Broker Architecture CoBrA [Chen04] qui est une architecture pour le développement d'applications sensibles au contexte dans des systèmes ambiants intelligents. - Context Management Framework CMF [Korpipaa04] qui définit une API pour la gestion du contexte - Service Oriented Context-Aware Middleware SOCAM [Gu04] qui est une plateforme d'aide à la création de services sensibles au contexte. 1. Context Toolkit Application Server Interpreter Interpreter Widget Sensor Widget Sensor Context Architecture Figure 4 - L'architecture du context Toolkit de Anind K. Dey Le context Toolkit offre une boite à outils et composants logiciels permettant le développement et le déploiement d'applications sensibles au contexte. Le nom de cet outil, Context-toolkit, vient de l analogie avec les bibliothèques graphiques de widgets (composants graphiques). Comme pour les «toolkits» graphiques qui offrent un modèle computationnel et des widgets d utilité publique (menu, formulaire, bouton), l objectif du Context-Toolkit est d offrir un modèle d exécution et des composants de base réutilisables pour les applications sensibles au contexte. Comme le montre la figure 4, le constituant de base de l architecture est un «context widget». Deux autres types de composants complètent l architecture : les «interpréteurs» et les «serveurs». Un «context widget», ou widget de contexte, est un composant autonome qui encapsule un capteur physique. Son rôle est de communiquer les informations perçues à un (ou plusieurs) serveur(s) ou interpréteur(s) en fonction des données reçues par le capteur. Il a aussi pour rôle de constituer un historique qui lui est propre. Ce stockage peut être désactivé pour des fonctions qui n en présentent pas l intérêt. Tarak CHAARI - 38 - Thèse de doctorat

Chapitre I Etat de l art : les systèmes sensibles au contexte Les interpréteurs ont pour objectif de donner une sémantique aux signaux qui leur sont transmis par les «contexts widgets», et ceci au bon niveau de précision. Par exemple, un interpréteur de localisation de personnes peut fournir comme informations : o Personne A dans la salle 501.330 o Personne A dans le Bâtiment 501 de l INSA de Lyon o Personne A dans le Campus de La Doua Les serveurs ont pour objectif principal de collecter l ensemble des signaux émis par les autres composants et de faire le lien entre les applications et les «contexts-widgets». Les serveurs ont également la charge de synthétiser les informations contextuelles dans un niveau d abstraction supérieur. Cependant le mécanisme de synthèse n est pas décrit et revient au programmeur. Dans le Context Toolkit nous retrouvons les différentes couches du modèle générique présenté dans la figure 4 : Les context widgets permettent un accès simple au capteur (couche capture de contexte). Les interpréteurs donnent un sens au contexte capturé (couche interprétation du contexte), et les serveurs (couche stockage et historique de contexte et aussi couche dissémination) font le lien entre les context widgets et les applications sensibles au contexte. Cependant, les context widgets ne sont que de simples pilotes logiciels pour les capteurs auxquels ils sont liés. Ils ne fournissent pas de sens aux informations qu ils transmettent et ont besoin pour cela des interpréteurs. Les serveurs, quant à eux, regroupent le gros du travail. Ils doivent synthétiser de nouvelles informations avec celles que leur fournissent les context widgets et faire le lien entre les applications et les context widgets. 2. Context Broker Architecture (CoBrA) Context Broker Architecture (CoBrA) est une architecture orientée agents pour les systèmes sensibles au contexte dans des environnements intelligents (par exemple, salles de réunion intelligentes, maisons intelligentes, et véhicules intelligents). L'élément central de cette architecture est un agent intelligent appelé le context broker (courtier de contexte) qui maintient un modèle partagé de contexte pour une communauté d'agents, de services et de capteurs. Le broker assure aussi la protection et la confidentialité des données échangées avec les utilisateurs en se basant sur des politiques de sécurité définies par chaque utilisateur. Les agents intelligents s'appuient sur des inférences basées sur des règles logiques pour la gestion du contexte et son interprétation. Tarak CHAARI - 39 - Thèse de doctorat

Chapitre I Etat de l art : les systèmes sensibles au contexte Figure 5 - Architecture globale du système CoBrA Dans CoBrA (figure 5), le courtier de contexte a les responsabilités suivantes : (i) fournir un modèle centralisé de contexte qui peut être partagé par tous les dispositifs, services, et agents dans l'environnement, (ii) acquérir les informations contextuelles provenant de sources inaccessibles par des terminaux à faibles capacités, (iii) assurer l'interprétation de l'information contextuelle qui ne peut pas être directement acquise des capteurs (par exemple, des intentions, des rôles, des relations temporelles et spatiales ), (iv) détecter et résoudre les conflits d'interprétation du contexte stocké dans le modèle partagé et (v) protéger la confidentialité des utilisateurs en appliquant leurs politiques de sécurité pour le partage et la communication de données. La figure 6 illustre un fragment de la représentation OWL d'un contexte d'une réunion dans une salle intelligente. Dans cet exemple nous trouvons la description des personnes (Classe OWL Person) qui assistent à la réunion et les dispositifs matériels (Classe OWL Device) qu'ils utilisent. Cette représentation définit aussi la relation "possède" (owns) pour identifier les dispositifs matériels utilisés par chaque personne qui participe à la réunion. Tarak CHAARI - 40 - Thèse de doctorat

Chapitre I Etat de l art : les systèmes sensibles au contexte <rdf :RDF xmlns = " http://example.org/devices# " xmlns:exd = " http://example.org/devices# xmlns :owl = http://www.w3.org/2002/07/owl# " xmlns:rdfs = " http://www.w3.org/2000/01/rdf-schema# " xmlns:rdf = " http://www.w3.org/1999/02/22-rdf-syntax-ns# " xmlns:xsd = " http://www.w3.org/2001/xmlschema# " > <owl :Ontology rdf :about = " http :example.org/devie" > <rdfs:comment>an ontology about people and devices</rdfs:comment> <rdfs:label>an Example Ontology</rdfs:label> </owl:ontology> <owl:class rdf:id = "Person" /> < owl:class rdf:id = "Device" /> <owl:class rdf:id = "Cellphone" /> <rdfs:subclassof rdf:resource = " #Device" /> </owl:class> <owl:class rdf:id = "PDA" /> <rdfs:subclassof rdf:resource = "#Device" /> </owl :Class> <owl:datatypeproperty rdf:id = "name" > <rdfs:domain = " http://www.w3.org/2002/07/owl#things" /> </owl:datatypeproperty> <owl:objectproperty rdf:id = "ownedby" > <rdfs:domain rdf:resource = "#Device" /> <rdfs:range rdf :ressource= "#Person / "> </owl:objectproperty > <owl:objectproperty rdf:id = "owns"> <owl:inverseof rdf:resource = "#ownedby"/> </owl:objectproperty> <Person rdf:id = "P1"> <name rdf:datatype = "&xsd;string">harry Chen</name> <owns rdf:resource = "#D1" /> </Person> <Person rdf:id = "P2"> <name rdf:datatype = "&xsd;string">joe Smith</name> </Person> <Cellphone rdf:id = "D1"> <name rdf:datatype = "xsd;string">harry s Blue Phone</name> </Cellphone> <PDA rdf:id = "D2"> <name rdf:datatype = "&xsd;string">blue Knight</name> <ownedby rdf:resource = "P2"/> </PDA> <rdf:rdf> Figure 6 - Représentation OWL du contexte dans l'architecture CoBrA Tarak CHAARI - 41 - Thèse de doctorat

Chapitre I Etat de l art : les systèmes sensibles au contexte 3. Context Management Framework (CMF) Figure 7 - L'architecture générale du Context Management Framework (CMF) Le context management framework (CMF) est une plateforme analogue au context toolkit de Dey. Elle est composée de quatre entités principales : resource server (capture de contexte), context recognition service (interprétation du contexte), context manager (dissémination du contexte) et application. Comme la plateforme CoBrA, le context management framework se base sur un gestionnaire de contexte centralisé qui communique avec tous les autres modules de la plateforme. En effet, dans CMF, le gestionnaire de contexte récupère les informations contextuelles à l'aide du module resource server. Ensuite, il les interprète en utilisant le module context recognition service. Enfin, il les diffuse à l'application. Cette dernière peut communiquer avec le "context manager" (gestionnaire de contexte) de trois manières différentes: - elle envoie des requêtes directes au "context manager". Dans ce cas, le context manager délègue cette requête au "resource server". - elle s'abonne aux changements des valeurs de contexte. Dans ce cas, le "context manager" utilise le service de détection des changements de contexte "change detection service". - elle demande un contexte de haut niveau (composé) en utilisant le service d'interprétation du contexte "context recognition service". Dans CMF, nous remarquons l'absence d'un stockage centralisé du contexte. Ceci constitue Tarak CHAARI - 42 - Thèse de doctorat

Chapitre I Etat de l art : les systèmes sensibles au contexte une différence majeure par rapport aux autres plateformes présentées. Une autre caractéristique intéressante de CMF, par rapport aux autres plateformes, consiste en l'utilisation de la logique floue pour atteindre des informations contextuelles de haut niveau. Les autres plateformes assument que le contexte (même de haut niveau) est bien spécifié et représenté alors que CMF considère que l'obtention du contexte de haut niveau n est ni simple ni directe. Les auteurs de CMF proposent donc d'utiliser la logique floue pour obtenir des informations de haut niveau et ainsi enrichir le contexte et la description de l'environnement de l'utilisateur. 4. Service oriented context-aware middleware (SOCAM) Figure 8 - L'architecture globale de la plateforme SOCAM SOCAM est un projet qui vise à assurer le développement et le prototypage rapide de services sensibles au contexte dans des environnements intelligents. Ce projet propose un middleware distribué qui convertit les divers espaces physiques d'où le contexte est capturé en un espace sémantique où le contexte peut être partagé et fourni à des services sensibles au contexte. Ce middleware se base sur des ontologies pour modéliser le contexte. En première étape, SOCAM utilise une première ontologie "pervasive" de haut niveau qui décrit les Tarak CHAARI - 43 - Thèse de doctorat

Chapitre I Etat de l art : les systèmes sensibles au contexte informations caractérisant l'environnement d'exécution de l'application d'une façon générale. Ensuite, une ontologie spécifique au domaine de l'application doit être définie (par exemple ontologie décrivant un utilisateur dans une maison intelligente). L'architecture de SOCAM, présentée dans la figure 8, comprend les composants suivants (qui évoluent en tant que services indépendants les uns des autres) : - context providers (fournisseurs de contexte) : Ils capturent des informations contextuelles utiles de sources hétérogènes de l'environnement de l'utilisateur et de l'application. Ensuite, ils les convertissent en des représentations OWL pour que le contexte puisse être partagé et réutilisé par d'autres composants de l'architecture. - context interpreter (interprète de contexte) : Il fournit des services de raisonnement logique sur les représentations OWL du contexte en appliquant des enchaînements de règles d'interprétation. Il fournit aussi un service d'interrogation intelligent qui permet de résoudre les conflits d'interprétation du contexte. - context database (base de données de contexte) : Elle stocke les différents éléments de l'ontologie "pervasive" décrivant l'environnement de l'application et les instances des ontologies spécifiques au domaine de l'application décrivant l'environnement de l'utilisateur. - context-aware services (services sensibles au contexte) : Ces services utilisent les différentes informations stockées dans la base de données de contexte (context database) pour modifier leur comportement selon le contexte courant. - service-locating service (service de localisation de services) : ce service fournit un mécanisme avec lequel des utilisateurs ou des applications peuvent localiser les fournisseurs et les interpréteurs de contexte. 5. Synthèse Le tableau 3 synthétise les aspects principaux de chaque architecture des plateformes étudiées : Context Toolkit, CoBrA, CMF et SOCAM. Nous remarquons que ces plateformes réutilisent d'une façon plus ou moins fidèle, le modèle général à base de cinq couches présenté dans la figure 1. Dans ces quatre plateformes, il y a un accord commun sur la séparation de l'acquisition du contexte d'une part et de son utilisation d'autre part. En effet, il est très important d'encapsuler les mécanismes d'acquisition du contexte dans des composants qui offrent une interface de communication standard. Actuellement, il n'y a pas un modèle standard d'acquisition de contexte à partir de plusieurs sources différentes. Chaque plateforme propose son propre modèle d'acquisition et de collecte de contexte. SOCAM utilise l'approche la plus Tarak CHAARI - 44 - Thèse de doctorat

Chapitre I Etat de l art : les systèmes sensibles au contexte sophistiquée de collecte et de dissémination du contexte : (i) les capteurs sont encapsulés par des services web; (ii) la communication avec l'interpréteur du contexte est réalisée par un échange d'événements en utilisant des représentations OWL des informations échangées. Context Toolkit CoBrA CMF SOCAM type d'architecture basé sur des widgets basé sur des agents centrée sur un gestionnaire de contexte middleware distribué méthode de capture widget de contexte module d'acquisition serveurs de ressources fournisseurs de contexte modèle de contexte attribut, valeur ontologies (OWL) ontologies (RDF) ontologies (OWL) interprétation du contexte transformation et agrégation moteur d'inférence et une base de connaissances service d'interprétation (context recognition service) moteur d'inférence Historique et stockage du contexte disponible dans un serveur distribué non disponible disponible dans une base de données sécurité et confidentialité appartenance de contexte politiques avec le langage Rei non disponible non disponible Tableau 3 - Comparatif des quatres plateformes : Context Toolkit, CoBrA, CMF et SOCAM Les plateformes existantes se distinguent aussi par le modèle de contexte utilisé. L utilisation des ontologies offre une grande richesse sémantique et plus de possibilité d'inférences et d'interprétation du contexte par rapport aux autres modèles de contexte. Cependant, leur implémentation reste difficile à réaliser surtout dans les cas d'utilisations de plusieurs ontologies comme dans le cas de SOCAM. L'utilisation d'un modèle trop simpliste comme les couples (attribut, valeur) est aussi à éviter car il est source de conflits d'interprétation et de description du contexte actuel de l'application et de l'utilisateur. La gestion d'historique du contexte est aussi un autre critère important dans les systèmes sensibles au contexte. En effet, l'historique permet d'implémenter des algorithmes d'apprentissage pour fournir des services hautement adaptables au contexte. De plus, avec ce genre d'algorithmes, des actions proactives peuvent être automatiquement déclenchées pour un certain nombre de services à l'utilisateur sans qu il formule une demande explicite. Un autre aspect important dans ces systèmes concerne la gestion de la sécurité et de la confidentialité des données. En effet, des concepts doivent être spécifiés pour définir à qui appartient l'information contextuelle. CoBrA utilise le langage Rei pour définir les politiques de sécurité en termes de droits et d'autorisations d'accès au contexte. Le context Toolkit implémente le concept d'appartenance du contexte à un utilisateur ou à une entité. Ainsi, une Tarak CHAARI - 45 - Thèse de doctorat

Chapitre I Etat de l art : les systèmes sensibles au contexte information contextuelle n'est accessible qu'à l'utilisateur ou l'entité auquel elle appartient. VI. CONCLUSION Malgré toutes ces propositions et tous ces critères évoqués par les travaux de recherche dans le domaine de la sensibilité au contexte, les plateformes proposées restent à instancier d'une manière ad hoc pour chaque application. Tous les travaux existants dans la conception de plateformes de déploiement et de développement d'application sensibles au contexte se basent sur le fait que la réaction de l'application par rapport aux changement du contexte capturé doit être assuré d'une manière ad hoc et spécifique par l'application elle-même. Ces travaux considèrent que les modifications du comportement de l'application restent une tâche propre au développeur de l'application et qu'elles restent un paramètre à prendre en compte lors de son développement. Une question se pose alors : que faire si l'application a été déjà développée pour supporter un contexte particulier et si on veut l'adapter à de nouveaux contextes d'utilisation? Les solutions existantes dans le domaine de la sensibilité au contexte n'ont qu'une seule réponse à cette question : reprendre tout le cycle de vie de l'application et redévelopper une nouvelle version. Cette solution reste très lourde à effectuer. Elle nécessite un apprentissage de la plateforme à utiliser pour pouvoir utiliser ses fonctions d'accès au contexte. La source de ce problème est l'absence d'une étape importante. Cette étape doit décrire comment l'application pourrait s'adapter aux changements du contexte. Pour répondre à ce besoin important, négligé dans le domaine de la sensibilité au contexte, nous avons élaboré une étude complète pour (i) identifier les moyens et les outils nécessaires avec lesquels nous pouvons assurer cette adaptation; et (ii) définir une stratégie générique et complète qui utilise ces outils pour réaliser et implémenter cette adaptation dans des cas concrets. Avant d'entamer la présentation de notre proposition pour l'adaptation des applications au contexte, nous présentons la notion d'adaptation et son utilisation dans d'autres domaines. Tarak CHAARI - 46 - Thèse de doctorat

CHAPIITRE H IIII ETAT DE L ART : LES TRAVAUX D ADAPTATIION EXIISTANTS T "L intelligence dérive de l'adaptation du sujet à son milieu" (Jean Piaget)

Chapitre II Etat de l art : les travaux d adaptation existants TABLE DES MATIERES I. INTRODUCTION 49 II. DEFINITION, UTILITE ET CARACTERISATION DE L ADAPTATION 49 1. Définition 49 2. Utilité 50 3. Caractérisation 50 III. L ADAPTATION DANS LES ARCHITECTURES A BASE DE COMPOSANTS 53 1. Concepts de la programmation à base de composants 53 2. Mécanismes d adaptation existants 54 3. Techniques d'adaptation de composants 56 4. Quelques architectures existantes d adaptation de composants 58 5. Synthèse sur l'adaptation des architectures à base de composants 61 IV. ADAPTATION DE CONTENU MULTIMÉDIA 61 1. Adaptation coté serveur 62 2. Adaptation coté client 62 3. Adaptation intermédiaire 62 4. Synthèse sur les approches d'adaptation de contenu 63 V. ADAPTATION DES INTERFACES UTILISATEUR 64 1. Modélisation des interfaces utilisateurs 64 2. Adaptation des interfaces homme-machine 66 3. Synthèse sur l'existant dans l'adaptation de présentation 66 VI. CONCLUSION 67 Tarak CHAARI - 48 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants I. INTRODUCTION Les travaux existants dans le domaine de la sensibilité au contexte se sont focalisés sur tous les aspects de capture, interprétation, modélisation, stockage et dissémination du contexte. Cependant, il y a beaucoup moins de travaux qui s'intéressent à l'adaptation et l'actualisation de l'application au contexte. Ce travail de thèse se focalise spécialement sur cet aspect d'adaptation ou d'adaptabilité au contexte. Il constitue le dernier maillon de la chaîne de sensibilité des applications au contexte. L'adaptation prend une dimension très importante surtout dans le cas où on veut ajouter la sensibilité au contexte à des applications déjà existantes qui ne sont pas adaptées aux nouveaux besoins dus au changement de leurs environnements d'utilisation. Dans ce chapitre, nous présentons la notion d'adaptation. Nous évoquerons aussi son utilité, ses objectifs et les domaines où elle est utilisée. La plus grande partie de ce chapitre est dédiée aux travaux d'adaptation existants que l'ont peut classer en 3 catégories : l'adaptation des architectures à base de composants, l adaptation des contenus multimédia et l adaptation de présentation. Enfin, nous synthétisons ces travaux et nous présentons les objectifs de ce travail de thèse. II. DEFINITION, UTILITE ET CARACTERISATION DE L ADAPTATION 1. Définition L'adaptation est, selon le grand dictionnaire [granddictionnaire], l'opération qui consiste à apporter des modifications à un logiciel ou à un système informatique dans le but d'assurer ses fonctions et, si possible, d'améliorer ses performances, dans un environnement d'utilisation" [granddictionnaire]. Dans le domaine de la sensibilité au contexte, l'adaptation est étendue par la notion d'adaptabilité qui caractérise un système qui est capable de changer son comportement luimême afin d'améliorer ses performances ou de continuer son exécution dans des environnements différents. Dans [Layaïda99], on trouve la définition : «Par adaptabilité, on entend les moyens automatiques ou semi-automatiques qui permettent aux contenus [ ] d'être utilisables sur des terminaux ayant des caractéristiques et des ressources très variées.». Sur l utilité de l adaptation, M. Satyanarayanan a dit dans [Satyanarayanan01] «L adaptation est nécessaire quand il y a une disparité significative entre l offre et la demande d une ressource». Tarak CHAARI - 49 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants 2. Utilité Après avoir mis en œuvre une application, plusieurs raisons peuvent conduire à l adapter. Ces raisons peuvent être classées en quatre catégories [Ketfi02] : 2.1 ADAPTATION CORRECTIONNELLE Dans certains cas, on remarque que l application en cours de son exécution ne se comporte pas correctement ou comme prévu. La solution est d identifier le module de l application qui cause le problème et de le remplacer par une nouvelle version supposée correcte. Cette nouvelle version fournit la même fonctionnalité que l ancienne, elle se contente simplement de corriger ses défauts. Dans ce travail de thèse, nous nous n intéressons pas à ce type d adaptation. Par contre, on s intéresse aux trois types qu on va présenter - dans la suite de cette section - par ordre de priorité de leur utilité pour l adaptation au contexte. 2.2 ADAPTATION ADAPTATIVE Même si l application développée s exécute correctement, parfois son environnement d exécution (comme le système d'exploitation), les composants matériels (ou d autres applications ou données dont elle dépend) changent. Dans ce cas, l application est adaptée en réponse aux changements affectant son environnement d exécution. 2.3 ADAPTATION EVOLUTIVE Au moment du développement de l application, certaines fonctionnalités ne sont pas prises en compte. Avec l évolution des besoins de l utilisateur, l application doit être étendue avec de nouvelles fonctionnalités. Cette extension peut être réalisée en ajoutant un ou plusieurs modules pour assurer les nouvelles fonctionnalités ou même en modifiant les modules existants pour étendre leurs fonctionnalités tout en gardant l architecture de l application. 2.4 ADAPTATION PERFECTIVE L objectif de ce type d adaptation est d améliorer les performances de l application. A titre d exemple, on se rend compte que l implémentation d un module n est pas optimisée. On décide alors de remplacer l implémentation du module en question. Un autre exemple peut être un module qui reçoit beaucoup de requêtes et qui n arrive pas à les satisfaire. Pour éviter la dégradation des performances du système, on diminue la charge de ce module en installant un autre module qui partage la charge avec le premier. 3. Caractérisation Après avoir présenté les différentes raisons d'utilisation de l'adaptation dans une Tarak CHAARI - 50 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants application, nous énumérons dans cette section les différentes classifications utilisées dans les travaux existants d'adaptation. Cette classification élaborée par [Chassot06] dépend de la manière d'application de l'adaptation : statique, dynamique, centralisée, distribuée, comportementale ou architecturale. 3.1 STATIQUE VS DYNAMIQUE L adaptation statique ou manuelle consiste à préparer plusieurs versions de la même ressource avant son exploitation. Cette ressource peut être un document, une image, une vidéo ou même une application. La ressource est adaptée manuellement avant de pouvoir la réutiliser dans son nouveau contexte. Cette technique a été adoptée pour plusieurs développements au début de l apparition des terminaux mobiles afin de pouvoir exploiter des ressources initialement prévues pour des PC standards. Avec une adaptation statique, le résultat est dédié au nouveau contexte d'utilisation de la ressource ce qui garantit la sûreté de son exploitation. Elle présente aussi une solution simple et efficace car chaque fournisseur s occupe de l adaptation de la ressource pour ses contextes. Cependant, elle présente l inconvénient de la difficulté d évolution pour la prise en charge de nouveaux contextes d'utilisation. Contrairement à l approche précédente, l adaptation dynamique effectue les transformations sur la ressource au cours de son utilisation. Un système d adaptation automatique intercepte les requêtes des utilisateurs et effectue à la volée des transformations suivant les caractéristiques du contexte d'utilisation actuel. OPERA [Lemlouma01] et MUSA [Menkhaus02] sont des applications où les données sont adaptées dynamiquement aux caractéristiques du terminal utilisé. Elles présentent une adaptation des pages WEB pour différents terminaux en agissant sur leur composition logique, spatiale, temporelle et hypertextuelle. Avec une adaptation dynamique, on gagne un temps de développement important puisque la ressource est transformée automatiquement à la demande de l utilisateur. Cependant, des problèmes d adaptation peuvent surgir dans un nouveau contexte d'utilisation inconnu, en fournissant un résultat d'adaptation qui n'est peut-être pas adéquat à ce contexte. En outre, le temps d'attente nécessaire à l adaptation de la ressource peut gêner l utilisateur. En effet, l'adaptation dynamique augmente automatiquement la latence de renvoi de l'information demandée par l'utilisateur. Malgré un grand intérêt pour l'adaptation dynamique, l'adaptation statique reste aussi un moyen sûr et efficace pour assurer l'exploitation des ressources dans différents contextes d'utilisation. Pour assurer une adaptation efficace et ouverte à plusieurs contextes, il est Tarak CHAARI - 51 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants important, à notre point de vue, d'utiliser les deux approches de façon complémentaire. 3.2 VERTICALE VS HORIZONTALE L'adaptation peut concerner une ressource locale à une machine ou distribuée sur plusieurs machines (typiquement un protocole). Dans le cas où la ressource est distribuée, le processus d'adaptation peut être centralisé ou réparti sur les différents pairs où les différentes parties de la ressource ont été stockées. Si l'adaptation est centralisée alors elle est qualifiée de verticale, sinon elle est horizontale. La solution centralisée est plus facile à implémenter et donne des performances meilleures au niveau du temps d'accès à la ressource adaptée. Ceci limite l'utilisation de la solution horizontale à des cas particuliers concernant les protocoles de communication. [Bridges01] soulève les problèmes de synchronisation de l'adaptation distribuée et propose un protocole dédié pour gérer cette synchronisation. 3.3 COMPORTEMENTALE VS ARCHITECTURALE L adaptation peut être qualifiée de comportementale (ou algorithmique) lorsqu'elle modifie le comportement de la ressource sans affecter sa structure interne. Ceci facilite l'implantation et l'exploitation de l'adaptation. En effet, puisque la structure est la même, la nouvelle ressource reste directement exploitable comme la ressource d'origine. L'implantation est aussi facilitée car cette adaptation n'effectue pas de changements profonds qui demanderaient une ré-évaluation des modifications effectuées. Cependant, cette approche comportementale limite le degré d'adaptation de la ressource. Elle est très utilisée pour l'adaptation de la couche transport à la qualité de service comme dans [Akan04]. L'adaptation est architecturale lorsque la structure interne de la ressource peut être modifiée en fonction des besoins applicatifs de l'utilisateur. Cette solution est intéressante car elle offre un haut degré d'adaptabilité mais elle reste très difficile à implanter. Elle ne reste possible que si on dispose d'une connaissance suffisante sur l'architecture de l'application et ses différents composants. L'adaptation architecturale reste restreinte aux applications orientées composant. Beaucoup de techniques d'adaptation intéressantes sont proposées pour ce type d'applications. Nous dédions le paragraphe IV de ce chapitre à ces techniques. Les paragraphes V et VI présentent les techniques existantes pour l adaptation des données et des interfaces utilisateur des applications. Tarak CHAARI - 52 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants III. L ADAPTATION DANS LES ARCHITECTURES A BASE DE COMPOSANTS Paradigme introduit dans les années 90, la programmation à base de composants ([Heineman01], [Szyperski02], [Riveill00]) a pour but d'améliorer la réutilisabilité, la sûreté et la flexibilité des applications. Pour cela, elle se base sur les notions de «composant» et «d'assemblage». Elle propose de concevoir une application comme un assemblage de briques logicielles préfabriquées. Grâce à la modularité de cette approche, un grand nombre de travaux l'ont adoptée pour le développement d'applications adaptables. Dans cette section, nous présentons les concepts de base de la programmation à base de composants et les techniques existantes d adaptation des architectures orientées composants. 1. Concepts de la programmation à base de composants Un composant [Szyperski97] est une unité logicielle qui possède un état constitué par les données qu'elle traite, une implantation qui est le code réalisant ce traitement et des interfaces fournies et requises qui sont des ports d'entrée/sortie pour interagir avec le monde extérieur (voir figure 9). Cette unité logicielle est liée à une infrastructure (conteneur) qui lui permet d échanger des messages avec des d autres composants. Cet échange dépend d un modèle d implantation de composants. Parmi les modèle les plus utilisés, nous citons les EJB (Enterprise Java Beans) de Sun, le CCM (Corba Component Model) et Fractal du consortium Object Web. Figure 9 - Vue extérieur d'un composant logiciel 1.1 LE MODELE EJB Les EJB [Roman02] sont des éléments clé de la plate-forme J2EE (Java 2 Enterprise Édition). Ce sont des composants Java portables, réutilisables et déployables qui peuvent être Tarak CHAARI - 53 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants assemblés pour créer des applications. Le cycle de vie d un EJB est géré par un conteneur qui fournit des services de gestion de l utilisation de ses composants. 1.2 LE MODELE CCM CCM [Raj99] est un modèle de composants indépendant de la plateforme et du langage de programmation. Ce modèle propose une API générique pour définir l interface du composant, son comportement, son intégration dans une application et la manière dont il échange des messages avec les autres composants. CCM est un modèle compatible avec les EJB. 1.3 LE MODELE FRACTAL Fractal [Objectweb04] est un modèle de composants Java réflexif et générique qui supporte la définition des composants et des liens entre leurs interfaces. Une application Fractal est vue comme un assemblage de composants qui communiquent des envois de messages synchrones entre leurs interfaces. Un composant Fractal est constitué d'un contrôleur par lequel passent toutes les interactions avec les autres composants et d'un contenu qui peut être un objet simple ou composé. 2. Mécanismes d adaptation existants Il existe plusieurs mécanismes qui permettent aux composants de réagir aux changements de contexte. Sans être exhaustif, les mécanismes les plus connus sont : la réflexivité et l'adaptation par contrat. 2.1 REFLEXIVITE La réflexivité représente la capacité d un composant à s observer et à agir sur lui-même durant son exécution [Cazzola99] [Maes87]. Un composant réflexif doit contenir deux niveaux : un niveau de base et un niveau «méta». Le niveau de base contient le code métier qui traite le domaine d'application. Le niveau «méta» manipule la représentation abstraite de système. Ces deux niveaux sont liés de façon causale, c'est-à-dire que tout changement dans l'un d'eux se répercute sur l'autre. Les interactions entre les deux niveaux se font dans les deux sens. Ainsi, on identifie deux aspects : l introspection et l intercession. L introspection est la capacité d un système à observer et raisonner sur son propre état et l intercession est la capacité d un programme à modifier son propre état d exécution. Ainsi, la réflexivité permet de modifier dynamiquement la structure et le comportement d'une application en réaction aux changements de son environnement. L'avantage majeur apporté par cette technique est la séparation entre le code métier des applications et le code qui gère l'adaptation. Mais elle engendre un surcoût inévitable en Tarak CHAARI - 54 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants temps d'exécution. 2.2 ADAPTATION PAR CONTRAT Une politique (policy) définit généralement le comportement attendu des systèmes distribués hétérogènes, des applications et des réseaux [Wies95]. La gestion d'un système basée sur une politique (politique-based management) consiste à spécifier un ensemble de règles qui sont appliquées dans des situations précises tout en assurant la cohérence et la sécurité. Ces règles peuvent spécifier des actions correctives qui devraient être faites dans certaines circonstances ou ajouter des contraintes aux états atteints par les composants du système. Elles sont utilisées aussi pour donner une priorité à une tâche plus haute qu'une autre ou pour définir des droits d'accès à un ensemble de ressources. La séparation entre la politique et l'implémentation d'un système offre des avantages. Elle permet de changer dynamiquement la stratégie de gestion du système en modifiant la politique. Ainsi, on modifie le comportement d'un système sans changer son implémentation. Cette approche a été utilisée dans différents domaines comme les bases de données actives et distribuées [Widom96] [Baral96], les applications du Web sémantique [May05] ou les systèmes distribuées [Sloman94]. Récemment, des systèmes d'adaptation (comme [Andrade03] et [Keeney03]) ont suivi la même logique pour spécifier et appliquer une politique d adaptation. Cette dernière est décrite dans un fichier appelé «contrat d adaptation» ou «fichier de règles d'adaptation». Nous présentons certains travaux qui illustrent ce principe dans le paragraphe 4 de cette section. 2.3 ADAPTATION PAR TISSAGE D ASPECTS Le paradigme de tissage d aspects permet de développer des applications en séparant leur code métier de leur code technique (non fonctionnel) [Kickzales97] [Pawlak01]. Cette séparation permet de structurer l application en modules indépendants : un noyau qui représente le cœur fonctionnel de l application. les aspects qui correspondent à des propriétés non fonctionnelles d'usage général, qui sont transversales à plusieurs composants du programme de base, telles que la synchronisation, la tolérance aux fautes, l équilibrage de charge ou la sécurité. Les aspects sont écrits séparément dans des langages appropriés tel AspectJ [Kiczales01]. Ensuite, un compilateur appelé tisseur intègre (ou tisse) ces aspects avec le noyau de base pour produire un seul composant exécutable. Pour utiliser ce mécanisme comme technique d'adaptation, le procédé d adaptation est considéré comme du code technique qui sera intégré dans le code fonctionnel du composant. L utilisation des aspects permet d obtenir un code Tarak CHAARI - 55 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants compréhensible et efficace. Le mécanisme de tissage d aspects présente un moyen d adaptation intéressant puisque le tissage peut être fait dynamiquement en cours d'exécution. 2.4 SYNTHESE SUR LES MECANISMES D ADAPTATION Nous considérons que les mécanismes d adaptation existants sont complémentaires. En effet, lors de l ajout d un module d adaptation à un système ou à un composant logiciel, il devient naturellement réflexif puisqu il doit percevoir les changements de son environnement et adapter son comportement à ces changements. Nous considérons également que l adaptation par contrat est une approche intéressante et efficace pour réaliser la réflexivité au sein d un composant ou d un système adaptatif. En effet, une politique d adaptation est nécessaire pour définir les règles selon lesquelles le système ou le composant va réagir pour adapter son comportement aux changements du contexte de son utilisation. Le tissage d aspects peut aussi être considéré comme un mécanisme intéressant pour implémenter les actions définies dans les contrats d adaptation. En effet, les actions définies dans ces contrats consistent généralement à l exécution d un code supplémentaire pour réaliser l adaptation. En conséquence, nous considérons que l utilisation de différents mécanismes d adaptation offre plus de possibilités pour garantir une adaptation adéquate et complète dans un système sensible au contexte. La section suivante «techniques d adaptation de composants» présentent les outils techniques qui permettent d implémenter les différents mécanismes d adaptation abordés dans cette section. 3. Techniques d'adaptation de composants Dans les travaux d'adaptation de composants comme ceux de [Aksit03] et [Ketfi02], nous avons relevé quatre techniques principales utilisées pour modifier le comportement d'une application : l'adaptation de l'architecture conceptuelle de l'application, l'adaptation de l'implémentation des composants, l'adaptation de l'interface du composant et l'adaptation du déploiement de l'application. 3.1 ADAPTER L ARCHITECTURE CONCEPTUELLE DE L APPLICATION - Ajouter un nouveau composant. Cette adaptation implique l adaptation des interconnexions entre le nouveau composant et les composants existants. Ce type d adaptation peut être classé en deux catégories : instancier le nouveau composant à ajouter à partir d un type déjà chargé par l application ou créer le nouveau composant à partir d un nouveau type. En général, quand un composant est ajouté à une application en cours d exécution, il doit prendre en compte l état de l application, il doit donc récupérer l état à partir duquel il doit Tarak CHAARI - 56 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants démarrer et se personnaliser en fonction de cet état. - Supprimer un composant existant. Le composant supprimé ne doit pas bloquer l exécution des autres composants. Il doit aussi être dans un état stable avant d être supprimé. Par exemple, si un composant est en cours d écriture de données dans un fichier, il ne doit par être supprimé avant la terminaison de sa tâche. Un autre défi concerne les données et les messages échangés entre le composant en question et les autres composants, ces données ou messages ne doivent pas être perdus pour maintenir le bon fonctionnement de l'application. - Modifier les interconnexions entre composants. Quand un nouveau composant est ajouté, il doit être connecté aux composants existants. En général, pour connecter deux composants, les types de leurs ports connectés doivent être compatibles. Dans une application répartie, la connexion entre deux composants spécifie le type de communication entre eux et dépend de leur localisation. En d autres termes, la communication entre deux composants dans le même espace d exécution est différente de la communication entre deux composants dans deux espaces d exécution différents sur la même machine. Elle est également différente de la communication entre deux composants s exécutant sur deux machines différentes. L adaptation des interconnexions doit préserver les messages et les données en transit. 3.2 ADAPTER L IMPLEMENTATION D UN COMPOSANT Cette adaptation consiste à remplacer un composant par un autre pour une raison perfective, adaptative ou correctionnelle. Dans le premier cas, l adaptation est motivée par des raisons de performance. Par exemple, on décide de remplacer un composant de stockage utilisant un vecteur par un autre composant utilisant une table de hachage. Autre exemple, l'administrateur d une application souhaite expérimenter plusieurs algorithmes implémentant la même fonctionnalité; il doit pouvoir passer d une implémentation à une autre sans arrêter l application. Du point de vue adaptatif, on peut donner l exemple d un utilisateur qui change d imprimante ou d un autre dispositif, le pilote de ce dispositif doit changer. La vision correctionnelle de l adaptation consiste à modifier l implémentation pour résoudre des bugs ou des problèmes constatés dans l implémentation courante. 3.3 ADAPTER LES INTERFACES D UN COMPOSANT Dans ce type d'adaptation, la liste des interfaces fournies par le composant est modifiée. Ceci peut être réalisé en ajoutant/supprimant une interface à/de la liste des interfaces fournies par le composant. - Ajouter une interface : l objectif est d étendre les fonctionnalités du composant. Les fonctionnalités exposées à travers les autres interfaces restent inchangées. Tarak CHAARI - 57 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants - Supprimer une interface : Si les fonctions de l'interface en question ne seront pas utilisées, il peut être utile de supprimer cette interface et par conséquent son implémentation pour des raisons de performances. 3.4 ADAPTER L ARCHITECTURE DE DEPLOIEMENT DE L APPLICATION Ceci correspond à la migration d un composant d un site vers un autre, par exemple pour la répartition des charges. Ce type d adaptation n affecte pas la structure de l application. Cependant, la communication entre le composant déplacé et les autres composants doit être adaptée selon la nouvelle localisation du composant. L état interne du composant doit être sauvegardé et réinjecté dans le composant déplacé. Les messages reçus et non encore traités doivent être pris en compte. 4. Quelques architectures existantes d adaptation de composants Dans cette section, nous présentons trois architectures de référence d adaptation d applications orientées composant : K-Component [Dowling01], ACEEL [Chefrour02] et SAFRAN [David05]. Nous analysons les points forts et les points faibles des mécanismes d adaptation utilisés dans ces architectures. 4.1 K-COMPONENT K-Component [Dowling01] est un modèle de composants pour construire des applications adaptables au contexte. Il spécifie la reconfiguration dynamique comme la transformation d'un méta-modèle d'architecture du système. Il utilise des contrats d'adaptation pour séparer le code d'adaptation du code métier. L'architecture du logiciel est considérée comme un graphe connexe et orienté où les sommets sont des interfaces, étiquetées avec les instances de composant, et les arcs sont des connecteurs, étiquetés avec les propriétés de connecteur. L'adaptation consiste à changer les implémentations des composants et les propriétés des connecteurs pour étendre ou améliorer les services fournis. La logique de l adaptation dans K- components est spécifiée par des contrats qui décrivent le comportement adaptatif du logiciel à l aide du langage ACDL (Adaptation Contracts Declarative Language). L adaptation se produit en réponse à des événements adaptatifs envoyés par les composants de l application. Le gestionnaire d'adaptation interprète le fichier ACDL et reconfigure l'application si une adaptation s avère nécessaire. Le gestionnaire d'adaptation assure la configuration du graphe de l architecture et implémente les opérations et le protocole de la reconfiguration. Tarak CHAARI - 58 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants Figure 10 Architecture d adaptation dans K-Component Le K-Component fournit un modèle d'adaptation générique et dynamique applicable à différents domaines. Le protocole de la reconfiguration assure la consistance et l'intégrité du système modélisé par un graphe de composants. De plus, des contraintes existantes de K- Component permettent d'assurer un niveau de sécurité satisfaisant. Par contre, K-Component utilise pour la partie contrôle de l'adaptation un ensemble de règles spécifiques à chaque composant pour décrire l'évolution d'un composant en fonction de l'évolution du contexte. 4.2 ACEEL ACEEL [Chefrour02] est un modèle de composants auto-adaptatifs pour les environnements mobiles. Il assure le changement dynamique de leurs comportements afin de s'accommoder aux nouvelles conditions d'exécution. Le modèle se base sur un langage de script pour décrire les règles d adaptation dans le format ECA (when <event> if <condition> do <action>). Il contient un mécanisme de détection et de notification des changements du contexte. Une action d adaptation consiste à commuter dynamiquement entre les différents comportements du composant. Ainsi, une interface dispose de plusieurs implémentations alternatives, chacune adaptée à un contexte d'exécution particulier. Selon le mécanisme de réflexion, il existe deux niveaux séparés dans l'architecture d'aceel. Le niveau de base est construit à l'aide du patron de conception stratégie. Le niveau méta contient une partie qui prend en charge l'auto-adaptation du composant et un sous système de détection-notification des changements de l'environnement. Le framework ACEEL inclut aussi un protocole d'adaptation qui désactive le composant avant de le reconfigurer, puis le réactive en garantissant qu'aucun message destiné au composant n'a été perdu pendant sa reconfiguration. Tarak CHAARI - 59 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants Figure 11 Modèle de composants auto-adaptatifs de l architecture ACEEL L impact d adaptation dans cette approche est assez léger si on le compare avec celui de K-Component. Par ailleurs, c'est un modèle orienté objet qui n offre pas une séparation claire des différentes fonctionnalités. De plus, pour assurer le protocole d'adaptation, ACEEL impose des contraintes fortes sur les composants. Les comportements possibles de chaque composant doivent être prévus à l avance. Ceci garantit la cohérence architecturale mais réduit l ouverture et la dynamicité de l adaptation. 4.3 SAFRAN SAFRAN [David05] est un système pour le développement d'applications adaptatives basé sur le modèle de composants Fractal. La dynamicité de configuration de ces composants et leur réflexivité rendent ce modèle approprié pour la construction d applications adaptables. Les adaptations sont considérées comme des aspects qui sont tissés dynamiquement dans les applications. Les politiques d'adaptation de SAFRAN sont structurées suivant un ensemble de règles réactives de la forme ECA. Quand un événement survient, si la condition est satisfaisante, une action sera exécutée. Toutes les actions de reconfigurations sont écrites dans un langage dédié, nommé Fscript. Il permet de programmer les reconfigurations déclenchées suite à la détection d'un événement. Un sous-système, nommé WildCAT, joue le rôle de détection et de notification des événements qui déclenchent l exécution de l adaptation. L architecture de SAFRAN comprend un contrôleur Fractal, nommé AdaptationController. Ce contrôleur implémente le tissage des politiques d'adaptation et rend ainsi les composants adaptatifs. La figure 12 illustre le fonctionnement de ce contrôleur. Tarak CHAARI - 60 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants Figure 12 Stratégie d adaptation dans l architecture SAFRAN L avantage de cette architecture et son originalité résident dans l utilisation de la notion d aspect qui sépare le code d adaptation du code métier des composants. Cependant, les instructions de tissage sont chargées par le système au démarrage et ne peuvent pas être modifiées pendant l exécution. 5. Synthèse sur l'adaptation des architectures à base de composants Dans cette section, nous avons présentés les techniques utilisées pour adapter le comportement fonctionnel des applications. Les seules solutions proposées dans ce domaine concernent l'adaptation des architectures à base de composants qui restent spécifiques au modèle de composants utilisé (EJB, CCM,.net ) ce qui limite leur utilité sur des applications dont on ne connait pas leurs architectures exactes ou qui ne sont pas développées à base de composants. Enfin, les possibilités d'adaptation existantes dans ce domaine se limitent à des remplacements restreints de composants par d'autres ou de réassemblage de composants prédéfinis. IV. ADAPTATION DE CONTENU MULTIMEDIA Depuis l'apparition des systèmes pervasifs, l'adaptation de contenu multimédia a fait l objet d importantes recherches. Plusieurs techniques d'adaptation de données ont été proposées. Ces techniques reposent sur la transformation textuelle [Nagao01], [Housel96], [Liljeberg95], le transcodage d image [Wee00], [Lee03], [Chandra99], [Smith98] ou le traitement vidéo et audio [Libsie04], [Shanableh00], [Vetro02], [Bolot98]. Une des questions majeures en terme d architecture pour le développement d une fonctionnalité d adaptation de contenu est de savoir où se réalisent la prise de décision et les opérations d adaptation. Trois approches générales ont été proposées dans la littérature pour la localisation de la fonctionnalité d adaptation entre la source qui héberge le contenu et la destination qui le demande : (i) coté serveur (qui héberge la source de données), (ii) coté Tarak CHAARI - 61 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants client et (iii) au niveau d un intermédiaire situés entre la source de données et le client. 1. Adaptation coté serveur Dans la première approche, l adaptation est opérée au niveau du serveur qui héberge la ressource comme dans [Margaritidis01], [Mogul01], [Mohan99], [Bharghavan97] et [Bolot98]. Le serveur se charge de découvrir les capacités du client et la bande passante disponible et choisit la meilleure stratégie de transformation de contenu. Les solutions coté serveur présentent quelques inconvénients. En effet, les transformations effectuées sur le contenu demandé induisent une charge de calcul et une consommation de ressources conséquentes sur le serveur. Cependant, cette approche reste très adaptée aux situations à faible variabilité vu la simplicité de sa réalisation. Mais elle n'est pas fiable pour des cas où les critères d'adaptation varient fréquemment. 2. Adaptation coté client Dans la seconde approche, la fonctionnalité d adaptation réside au niveau du destinataire comme dans [Marriott02], [Lei01], [Björk99], [Yoshikawa97] et [Fisher97]. Les transformations de contenu nécessaires sont effectuées par le terminal du client, prenant en compte ses capacités matérielles qui sont ainsi directement accessibles. La source initialement fournie demeure inchangée quel que soit le contexte de son utilisation. Le client, à la réception du contenu, transforme celui-ci de manière à pouvoir le présenter ou l'exploiter. L adaptation coté client requiert des modifications minimales au niveau du récepteur et peut être extrêmement efficace dans la personnalisation du contenu jusqu à correspondre exactement et efficacement aux capacités du récepteur. Cette approche est efficace lorsque les caractéristiques de transmission sont moins critiques que les limites d affichage du terminal [Nandagopal99]. Toutefois, cette solution est mal adaptée aux situations où les propriétés de transmission sont tout aussi importantes que celles de l affichage. La complexité habituellement élevée des mécanismes d'adaptation freine également l adoption large de cette approche [Perkis01]. En effet, le terminal du client est généralement très limité en capacités de calcul et de stockage. 3. Adaptation intermédiaire La troisième approche tente de constituer un compromis entre les deux solutions précédentes : la fonctionnalité d adaptation est placée sur un nœud intermédiaire habituellement qualifié de proxy (proxy) ou passerelle (gateway). Des exemples de systèmes à base de proxys se trouvent dans les références [Singh04], [Wee03], [Kim03], [Chandra99], Tarak CHAARI - 62 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants [Fox98], [Angin98], [Bickmore97] et [Noble97]. Le proxy intercepte la réponse du serveur, décide et effectue l adaptation du contenu en fonction des préférences de l utilisateur, des capacités des terminaux et de l état du réseau, puis envoie le contenu adapté au client. L adoption d une solution à base de proxy présente plusieurs avantages. D abord, l adaptation intermédiaire déplace la charge de calcul du serveur de contenu vers le proxy. En second lieu, le proxy peut être positionné au point le plus critique du chemin de données. On considère habituellement que la bande passante entre un proxy et un serveur est plus large que celle qui est disponible entre un client et un proxy. Le placement du proxy dans un endroit optimal entre le serveur de contenu et le client permet de disposer d une vue globale sur les ressources de l environnement, telles que la latence du réseau, la bande passante, la taille du contenu à transporter, les préférences de l utilisateur, toute modification survenant dans le temps, etc. En conséquence, la flexibilité du positionnement du mécanisme d adaptation sur le meilleur point de distribution de contenu constitue un avantage important en faveur de la solution du proxy vis-à-vis des deux autres approches (coté client et coté serveur). La solution basée sur un proxy présente aussi des inconvénients. En premier lieu, elle passe difficilement à l échelle à cause des coûts de calcul considérables induits par les opérations d adaptation [Lum02]. En second lieu, le fait de passer par un intermédiaire pour la transmission d un contenu soulève des problèmes de sécurité. Le tiers manipulant le proxy doit être digne de confiance auprès du receveur et de la source. En l absence d un tiers de confiance, l approche "proxy" ne peut pas se charger d adapter du contenu. De plus, le tiers est susceptible de facturer son service et les ressources sollicitées pour la réalisation de l adaptation. De ce fait, des mécanismes de comptabilité devraient être intégrés à cette solution afin de mesurer le coût global du processus d'adaptation. En troisième lieu, la liste des mécanismes d adaptation de contenu n est pas exhaustive et pourrait s enrichir dans un futur proche ; l intégration de ces nouveaux outils risque de ne pas être possible si le proxy n est pas extensible. Enfin, placer toutes les fonctionnalités d adaptation au sein du proxy requiert des unités de calcul puissantes et beaucoup de mémoire. 4. Synthèse sur les approches d'adaptation de contenu En résumé, de nombreux efforts ont été menés pour développer différentes approches et techniques d adaptation de contenu. Des produits commerciaux (par exemple : IBM Transcoding [IBM06], Web Clipping [Hillerson01], WebSphere [Rodriguez01], etc.) et des prototypes issus de travaux de recherche (comme : TranSend [Fox98], Odyssey [Noble00], Conductor [Yarvis01], Digestor [Bickmore97], etc.) ont été développés pour fournir des Tarak CHAARI - 63 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants techniques d adaptation de données multimédia dans des environnements hétérogènes. Ces produits ont beaucoup contribué à l élaboration de stratégies, d architectures et de techniques d adaptation. Cependant aucune ne nous semble résoudre convenablement les problèmes d interopérabilité, d extensibilité, de flexibilité et de passage à l échelle qui sont des points essentiels dans un environnement sensible au contexte. De plus, les systèmes existants sont conçus pour des besoins spécifiques ; les types d adaptation de contenu qui ont été abordés se sont principalement focalisés sur la transformation d images ou le transcodage vidéo, et ne fournissent pas de solution générique d adaptation. V. ADAPTATION DES INTERFACES UTILISATEUR L adaptation des interfaces utilisateur au contexte consiste à produire des interfaces d interactions homme-machine qui peuvent être déployées et utilisées sur différent types de terminaux et qui satisfassent les préférences de l utilisateur. La plupart des travaux d'adaptation des interfaces utilisateur s'appuient sur des modèles décrivant les différents aspects de l interaction entre l homme et la machine. Dans la suite de cette section, nous présentons les modèles principaux existants et nous illustrons leur utilisation dans le processus d'adaptation. 1. Modélisation des interfaces utilisateurs Des études approfondies ont été réalisées pour pouvoir modéliser les différents aspects des interfaces homme machine. Dans ces travaux, nous distinguons deux approches : cognitives et d ingénierie. Les approches cognitives s intéressent aux modes de communication entre l homme et l interface graphique, traitant les problèmes d ergonomie et des capacités intellectuelles et physiques de l utilisateur. Dans cette optique, des travaux essaient de définir des langages d expressions de tâches. Ces études sont centrées sur la définition et l élaboration de trois entités : BUT ACTION TACHE : on commence par définir les buts de l utilisateur qui décrit le rôle de l interface graphique. Ensuite, on déduit les tâches associées. Enfin, on définit l action qui va déclencher l exécution de la tâche pour atteindre le but spécifié. Cette approche touche aussi les domaines de l extraction de connaissances et de la multimodalité qui servent à détecter les gestes et les actes d interaction de l'utilisateur avec l interface du système. Ces domaines se basent essentiellement sur la notion de modalité d interaction. Le terme modalité désigne le moyen physique ou logique permettant une communication entre l homme et la machine. Comme modalités physiques on peut citer la souris, le clavier, un Tarak CHAARI - 64 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants capteur de gestes ou de voix Une zone texte sur une interface graphique ou un logiciel de reconnaissance vocale représentent des modalités logiques d interaction. Ces modalités peuvent aussi être classées suivant leur sens d interaction : de l utilisateur vers l interface (modalités d entrées) ou de l interface graphique vers l utilisateur (modalités de sortie). Dans cette approche, les modèles proposés décrivent les moyens d interaction avec l utilisateur. Les modèles principaux sont : le modèle de tâches, le modèle de dialogue, et le modèle utilisateur. Le modèle utilisateur décrit les caractéristiques cognitives et les préférences ergonomiques de l utilisateur. Le modèle de tâche décrit les actions que l utilisateur peut effectuer sur le système. Enfin, le modèle de dialogue décrit les moyens d interaction de l utilisateur avec le système. Dans ce cadre, l équipe de recherche IIHM [IIHM] présente de nouveaux outils d interaction comme la réalité et la virtualité augmentées [Dubois01] basées sur la gestualité. Les approches d ingénierie s intéressent plus au développement des interfaces. Elles proposent des outils de développement et de conception des interfaces homme machines. Ainsi, les chercheurs s intéressent au passage d une problématique de visualisation ou de mise à jour de données à une solution concrète (le code de l interface). Ce passage est généralement basé sur des modèles techniques décrivant la structure et la composition logique de l interface d une part et son interaction avec le système d autre part. Ceci nécessite une connaissance approfondie du système. C est le rôle du modèle de domaine dans ces approches. Il décrit tous les aspects fonctionnels du système (entités, relations, collaboration ). Une formalisation de tous ces aspects est définie dans le langage UML [Booch98]. Les autres modèles de ces approches d'ingénierie décrivent la structure logique de l interface, la disposition de ses composants et son interaction avec le système. Plusieurs spécifications, modèles et langages de ce type ont été proposés. Voici une liste des modèles les plus connus dans les approches d ingénierie : - UMLi [Pinheiro00] est une extension de UML permettant de décrire l aspect interaction d une application. Basé sur le même concept (représentation graphique) de UML, UMLi permet de spécifier les composants logiciels constituant l interface graphique et leur interaction avec le reste du système. Les diagrammes UMLi restent assez complexes et fastidieux à construire pour aboutir à une description complète de l'interface utilisateur d'une application. - UIML [Abrams99], contrairement à UMLi, se base sur le langage de balisage XML. Ce langage cherche à masquer la diversité des plateformes et des langages de développement. La spécification de la présentation est dépendante de la plateforme cible. Si le développeur vise une IHM pour WML et pour Java, il se doit de produire deux spécifications distinctes. L une Tarak CHAARI - 65 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants utilisera les balises WML, la seconde les classes awt/swing. AUIML [Merrick04] est une amélioration de UIML. Il résout l un des principaux problèmes de UIML puisque la spécification est indépendante de la plate-forme cible. - XIML [Puerta02], est un langage basé sur XML. Il présente l'avantage d'être totalement indépendant des plateformes cibles en présentant un niveau d'abstraction très haut. Cependant, l'instantiation de ce langage pour des plateformes concrètes reste très difficile et complexe à réaliser. 2. Adaptation des interfaces homme-machine A partir de ces modèles, une stratégie d adaptation doit être définie pour assurer le bon fonctionnement de l interface utilisateur. Beaucoup de systèmes permettant l adaptation des interfaces hommes machines aux préférences de l utilisateur s'appuient sur l un des modèles cités dans le paragraphe précédent. Ces systèmes permettent d obtenir le code source de ces interfaces d une façon automatique ou semi automatique. Les exemples les plus intéressants sont : UIDE [Sukaviriya93], AME [Märtin96], JANUS [Balzert96], TRIDENT [Bodart95], GENIUS [Janssen93], Mobi-D et MECANO [Puerta96]. Dans tous ces travaux d adaptation, nous distinguons deux techniques d adaptation : par transformation et par génération. L adaptation par transformation consiste à partir d une entrée assez proche du code qui doit être généré. Cette solution a été adoptée par [Lemlouma02] pour assurer l adaptation des pages web aux terminaux cibles en partant d un langage XML. Dans ce genre d adaptation, on utilise des feuilles de transformation comme XSLT [Clark99], basées sur des règles de remplacement des informations du langage de départ pour obtenir le code d arrivée. L adaptation par génération concerne surtout les interfaces graphiques programmées en partant d un langage de haut niveau, comme par exemple dans le système SEFAGI [Chaari04]. LiquidUI [Hormonia06] est un autre produit permettant de générer des interfaces graphiques à partir du langage UIML. Cependant, dans cette plateforme, le langage utilisé n est pas très loin du code généré. Ceci complique considérablement la description de l'interface utilisateur voulue. 3. Synthèse sur l'existant dans l'adaptation de présentation De nombreux travaux de recherche on été effectués sur l'adaptation de présentation surtout pour les interfaces graphiques WEB basées sur un balisage. Cependant ces interfaces offrent des moyens d'interaction limités et ne permettent pas d'accéder aux ressources des terminaux utilisés pour détecter leurs propriétés. Sur le marché, nous trouvons aussi des produits Tarak CHAARI - 66 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants commerciaux pour l'aide à la création des interfaces utilisateurs comme JBuilder [JBuilder06], Eclipse [Eclipse06], Visual Studio [Johnson03] Cependant, ces produits ne permettent pas la génération complète du code et exigent un développement ad hoc pour chaque type de terminaux. Ceci les rend peu utiles dans le domaine de la sensibilité au contexte où de nombreux types d'interfaces utilisateurs nomades doivent être pris en compte. A l'image de LiquidUI de Harmonia [Hormonia06], les approches existantes restent limitées à des plateformes spécifiques et utilisent des langages de description très complexes pour pouvoir générer le code complet de l'interface utilisateur nécessaire pour l'interaction avec les différents services d'une application. VI. CONCLUSION Dans ce chapitre, nous avons fait un tour d horizon des différents travaux d adaptation existants dans différents domaines. Ces contributions ont généralement concerné des besoins spécifiques d amélioration de la qualité de service en adaptant les informations envoyées d un serveur à un client aux différentes variations des propriétés de la transmission. D autres travaux d adaptation ont concerné les architectures à base de composants. Ils proposent un réassemblage de la structure globale de l application en se basant sur un ensemble de composants prédéfinis. Ces contributions présentent trois inconvénients majeurs : (i) la majorité de ces travaux restent spécifique au modèle de composant choisi (EJB, CCM,.NET ) ; (ii) les outils d adaptation proposés se limitent à un remplacement d un composant ou un assemblage de composants prédéfinis et (iii) ces travaux ne prennent leur intérêt que pour des applications en cours de développement et non pour des applications déjà développées qu on veut adapter à de nouveaux contextes d utilisation. De nouvelles contributions pour les systèmes d information pervasifs sont aussi proposées pour l adaptation des documents WEB à plusieurs types de terminaux et aux préférences des utilisateurs. Ces travaux ne sont pas suffisants pour adapter une application entière, déjà développée, à de nouveaux contextes d utilisation pour deux raisons principales : (i) ces adaptations ne touchent pas les fonctions métier de l application. En effet, les fonctions offertes par l application peuvent ne pas être adaptées à un nouveau contexte d utilisation. Par exemple, une fonction qui renvoie un gros volume de données (une requête sur une base de données par exemple) ne peut pas être utilisée sur un terminal à faible capacité ; (ii) les interfaces utilisateurs WEB sont très limitées par rapport aux interfaces programmées. Ces dernières, contrairement à la solution WEB, autorisent l accès aux ressources systèmes (mémoire disponible, charge du processeur ) et fournissent des moyens d interaction plus Tarak CHAARI - 67 - Thèse de doctorat

Chapitre II Etat de l art : les travaux d adaptation existants évoluées à l utilisateur (gestion évoluée des évènements d interaction). Nous trouvons aussi beaucoup de travaux intéressants sur l adaptation des données multimédia échangées entre les serveurs de contenus et les clients. Ces travaux sont spécifiques au domaine de l extraction de données multimédia (multimedia data retrieval). Cependant, ils présentent des techniques intéressantes qui peuvent être reprises dans le domaine de la sensibilité au contexte afin d adapter les données échangées entre l application et le client. Dans ce travail de thèse, notre contribution consiste à proposer une architecture et une stratégie d adaptation d applications à de nouveaux contextes d utilisation en se basant sur les objectifs suivants : - Fournir une architecture générique et évolutive permettant l adaptation des applications à de nouveaux contextes d utilisation. - Fournir une stratégie d adaptation globale (fonctionnalités, données et présentation) d une application à de nouveaux contextes d utilisation. - Garantir l évolutivité des mécanismes d adaptation disponibles que nous pouvons appliquer à une application. Tarak CHAARI - 68 - Thèse de doctorat

CHAPIITRE IIIIII - CONTRIIBUTIIONS : DEFIINIITIIONS, OBJECTIIFS ET ARCHIITECTURE Context is an operational term: something is context because of the way it is used in interpretation, not due to its inherent properties (Terry Winograd)

Chapitre III Contributions : Définitions, Objectifs et Architecture TABLE DES MATIERES I. INTRODUCTION 71 II. NOTRE VISION DU CONTEXTE 71 1. Définition du contexte 71 2. Notion de situation contextuelle 73 3. Modélisation d une situation contextuelle 75 III. MODELISATION FONCTIONNELLE D UNE APPLICATION 78 1. Notion d entité logicielle 78 2. Notion de service 79 3. Notion de dépendance d exécution de services 80 4. Notion de modèle fonctionnel 81 IV. OBJECTIFS DE NOTRE TRAVAIL 85 V. SECAS : PLATEFORME POUR L ADAPTATION D APPLICATIONS A DE NOUVEAUX CONTEXTES D UTILISATION 87 1. Présentation de la plateforme SECAS 87 2. Couche de gestion du contexte 87 3. Couche d adaptation 89 4. Couche de déploiement d applications 93 VI. CONCLUSION 94 Tarak CHAARI - 70 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture I. INTRODUCTION Les applications client/serveur sont conçues et développées pour une utilisation dans un environnement et dans des conditions spécifiques. En fonction de leur utilisation, de nouveaux besoins apparaissent. Ces applications peuvent être intégrées dans de nouvelles situations et de nouveaux environnements non prévus. Malgré les efforts fournis dans le domaine du génie logiciel pour garantir l évolutivité de ces applications, leur cycle de vie est généralement totalement repris dès la phase d analyse des besoins. Dans ce chapitre, nous précisons ce que nous entendons par «contexte» et par «adaptation». Puis nous rappelons les objectifs de ce travail. Avant de conclure, nous présentons notre architecture d adaptation d applications à de nouveaux contextes d utilisation. Nous avons nommée cette architecture SECAS pour «Simple Environment For Context-Aware Systems». II. NOTRE VISION DU CONTEXTE 1. Définition du contexte Dans le domaine de la sensibilité au contexte, les chercheurs n ont pas encore abouti à une définition de la notion de contexte d utilisation qui soit à la fois générique et pragmatique. En effet, les définitions proposées sont soit très abstraites soit très spécifiques à un domaine particulier. Ces définitions variées rendent la formalisation du contexte difficile par manque de précision ou par manque de généricité. La définition de Anind K. Dey [Dey01b]: 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 est la plus répandue et la plus acceptée par la majorité des chercheurs dans le domaine de la sensibilité au contexte. Cependant, cette définition peut être une source de conflits parce qu elle ne précise pas de limite entre ce qui fait partie du contexte et ce qui n en fait pas partie. Selon notre expérience dans le domaine, dans un souci d évolutivité, les applications doivent être conçues et même développées indépendamment du contexte. Le concepteur d une application peut identifier les données qui sont directement liées au domaine de l application d une part et les autres informations caractérisant le contexte d autre part. Les paramètres du contexte peuvent être identifiés en aval de la conception de l application. Ces Tarak CHAARI - 71 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture considérations devraient permettre aussi de transformer une application existante (legacy) en une application sensible au contexte sans toucher au code existant. Pour aboutir à ce but, la limite entre le contexte et les données propres à l application doit être clairement précisée. Cette séparation n est pas évidente et dépend généralement du domaine de l application. Par exemple, les coordonnées GPS de l utilisateur constituent une donnée propre à l application dans une application de régulation de trafic routier alors qu elle constitue un paramètre du contexte dans une application de télémédecine. Ainsi, identifier les paramètres du contexte n est pas une tâche évidente. Nous avons élaboré une étude sur les caractéristiques des paramètres du contexte afin de faciliter la tâche de leur identification lorsqu on considère une application donnée. Ces caractéristiques concernent principalement les sources qui produisent ces paramètres d une part et leur importance pour l application et l utilisateur d une autre part. La première constatation que nous avons faite est que ces paramètres ne proviennent pas d un stockage permanent de l application. En effet, les données stockées dans des sources du domaine de l application n appartiennent pas à son environnement externe mais font partie de ses constituants. A notre avis, l utilisation du contexte est utile pour des raisons de perfectionnement de l application et ne constitue pas un élément primordial pour son fonctionnement. Les paramètres du contexte ne sont pas fournis par des sources directement liées au domaine de l application. Le cas échéant, elles appartiennent au domaine de l application mais pas à son environnement externe. La deuxième caractéristique, qui nous semble la plus importante, est que les paramètres du contexte ne sont pas toujours significatifs pour l utilisateur et doivent être gérés de façon transparente. En effet, le contexte d une application ne doit pas altérer ou changer complètement les fonctionnalités attendues par l utilisateur. Ce dernier peut intervenir et participer à modifier certains paramètres du contexte (par exemple ses préférences) mais d une façon indépendante de l utilisation de l application. Dans un cadre plus général, nous pouvons fournir une nouvelle définition du contexte : Le contexte est l ensemble des paramètres externes à l application qui peuvent influer sur son comportement en définissant de nouvelles vues sur ses données et ses fonctionnalités. Ces paramètres peuvent être dynamiques et peuvent donc changer durant l utilisation de l application. Cette définition vient compléter les efforts de Winograd [Winograd01] qui a essayé Tarak CHAARI - 72 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture d apporter plus de précisions sur la définition de Dey en diminuant l espace infini et illimité tracé par Dey. Winograd insiste sur le fait que 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. 2. Notion de situation contextuelle Une instance des paramètres d un contexte donné caractérise une situation contextuelle. Cette situation ne modifie pas l information que l utilisateur veut avoir de l application à un instant donné mais peut conduire à la traiter ou à la présenter différemment. Par exemple une situation contextuelle peut être caractérisée par les paramètres suivants : {utilisateur="médecin néphrologue", terminal="pda", localisation="domicile du patient X"}. L application doit être adaptée à cette situation selon le profil du médecin et son rôle (avec ses droits d accès, etc), selon la capacité du terminal utilisé (par exemple, en présentant les données par petits blocs à la place de tables volumineuses) et selon la localisation spécifique de l utilisateur (par exemple, en retirant les interfaces indisponibles au domicile du patient). Pour définir formellement une situation contextuelle, nous considérons un espace multi-dimensionnel où chaque dimension représente une facette du contexte. Nous définissions le contexte d utilisation d une application comme un vecteur à cinq dimensions : Contexte = (terminal, communication, utilisateur, localisation, environnement) - Terminal : Cette facette décrit toutes les caractéristiques matérielles et logicielles des terminaux utilisés incluant par exemple la description de l écran (taille, résolution, nombre de couleurs), de sa mémoire (de stockage et volatile) et de l API de programmation disponible. - Communication : Elle comprend les caractéristiques des réseaux utilisés comme leurs bandes passantes, leurs connectivités et leurs qualités de services. - Utilisateur : Cette facette décrit toutes les caractéristiques de l utilisateur final de l application incluant ses capacités, ses préférences, son profil et ses droits d accès. - Localisation : Cette facette décrit l emplacement logique et physique de l utilisateur. L emplacement logique peut être une adresse IP alors que l emplacement physique est généralement l adresse géographique de l utilisateur (pièce, adresse postale). - Environnement : Cette facette est complémentaire aux autres facettes du contexte. Elle sert à enrichir le modèle de contexte par d autres paramètres utiles selon le domaine d application. Par exemple, nous pouvons trouver dans cette facette la température ambiante, l activité ou l état actuel de l utilisateur (conduire une voiture, dormir, occupé ) Tarak CHAARI - 73 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture Les cinq facettes sont rarement utilisées en même temps pour une même application. La figure 13 présente deux exemples de situations contextuelles C 1 et C 2 dans un espace tridimensionnel {utilisateur, terminal, localisation}. C 1 présente une situation contextuelle où l'utilisateur est un médecin généraliste situé dans son bureau utilisant un PC standard et qui modifie le traitement d'un patient. Dans le contexte C 2, une infirmière consulte le même dossier médical au domicile du patient en utilisant un PDA, pour appliquer la prescription du médecin généraliste. Dans les deux contextes, les utilisateurs utilisent le même service «prescription». Cependant, l'application ne se comporte pas de la même manière car les deux situations contextuelles sont différentes : le profil d'utilisateur (médecin et infirmière) affecte les droits d'accès aux données ; le lieu (bureau et domicile du patient) modifie la liste des services disponibles, puisque certains appareils médicaux ne sont pas présents au domicile du patient ; la facette terminal modifie la forme de présentation des données et l'interaction de l'utilisateur avec l'application. Par exemple, l information est entièrement envoyée sur un PC standard alors qu elle doit être décomposée en plusieurs lots pour un terminal à faible capacité. Terminal Téléphone portable PDA Médecin généraliste P Cabine Extérieur Localisation Infirmier Hospitalier C C Utilisateur Figure 13 - Représentation tridimensionnelle du contexte Chaque facette regroupe un ensemble de paramètres du contexte. A un instant donné, la situation contextuelle est définie par les valeurs associées aux paramètres de contexte. La modification d'une de ces valeurs correspond à une transition vers une autre situation contextuelle. Cette transition peut modifier le comportement de l application en définissant de nouvelles vues sur ses données et ses fonctions. Nous rappelons que la notion de situation contextuelle permet de décrire l environnement de l application et de l utilisateur à un instant donné. Nous avons défini cette notion afin (i) de modéliser et de quantifier le contexte et (ii) d y adapter le comportement de l application. Tarak CHAARI - 74 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture Nous détaillons la structure générale d une situation contextuelle dans le paragraphe suivant. 3. Modélisation d une situation contextuelle Pour stocker les paramètres du contexte, nous utilisons une représentation XML basée sur le modèle CSCP [Held02]. Nous avons utilisé la richesse et la généricité de ce modèle pour définir un élément XML pour chaque facette du contexte (contextfacet). Par exemple, dans la figure 15, la ligne 3 définit un élément qui représente la facette «terminal». Chaque facette regroupe un ensemble de paramètres de contexte (ContextParameter). Ces paramètres peuvent appartenir à des structures hiérarchiques regroupées dans des catégories (contextcategory). Par exemple, la ligne 5 de la figure 15, définit un paramètre «model» représentant le modèle du terminal utilisé. Ce paramètre appartient à la facette «terminal». La ligne 11 de la même figure définit un paramètre «width» qui représente la largeur du terminal utilisé. Ce paramètre appartient à la sous-catégorie «screensize» (taille de l écran) qui est elle-même une sous catégorie de «hardwareplatform» (plateforme matérielle) de la facette «terminal». Chaque paramètre du contexte peut être statique s il ne change pas durant une session utilisateur ou dynamique si sa valeur peut varier dans une même session utilisateur. Nous associons pour chaque paramètre, un attribut «mode» pour différencier les paramètres dynamiques des paramètres statiques. Cette différenciation est très importante pour le processus d adaptation. En effet, l application doit être informée immédiatement lors du changement d un paramètre dynamique alors que les paramètres statiques sont consultés en cas de besoin. La ligne 8 de la figure 15 définit un exemple de paramètre statique qui représente la mémoire vive totale du terminal. Le paramètre «availablememory» de la ligne 9 du même listing présente un paramètre dynamique qui représente la mémoire virtuelle disponible lors de l utilisation de ce terminal. Contrairement à la mémoire totale du terminal, la mémoire disponible varie selon l utilisation du terminal. Un paramètre de contexte requis dans une application peut être inutile dans d autres environnements. Ainsi, cette structure XML peut être étendue par des catégories et des paramètres additionnels selon le domaine d'application. En particulier, la facette «environnement» peut encapsuler toute information supplémentaire de contexte qui n'est pas décrite dans les autres facettes de base. La figure 14 présente la structure générale de notre modèle du contexte. Pour chaque session utilisateur nous associons un profil «contextprofile» qui décrit les cinq facettes du contexte. Chaque facette peut contenir des paramètres du contexte comme elle peut contenir Tarak CHAARI - 75 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture des catégories «contextcategory» pour classer les paramètres. Chaque catégorie peut contenir d autres catégories. ContextProfile ID 1..5 ContextFacet facetname 1..n 0..n ContextSubCategory name 1..n ContextParameter name type=static/dynamic Figure 14 - Le modèle général du contexte La figure 15 donne l exemple d une situation contextuelle associée à une session utilisateur. Ce dernier se connecte en utilisant un téléphone mobile de type NOKIA 6230 à connectivité limité. La première facette du contexte «terminal» (ligne 3) décrit les caractéristiques générales du terminal puis les formats de données qu il accepte ainsi que l API disponible. La deuxième facette «network» (ligne 35) décrit la connectivité disponible pour communiquer avec l application. La troisième «userprofile» (ligne 41) donne les caractéristiques générales de l utilisateur et ses préférences. Enfin, la quatrième facette «location» (ligne 56) présente les coordonnées logiques et physiques de la localisation de l utilisateur. Tarak CHAARI - 76 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 <?xml version="1.0" encoding="utf-8"?> <contextprofile ID="U17T355008002783631"> <contextfacet name="terminal"> <contextparameter name="mode" mode="static">cldc</contextparameter> <contextparameter name="model" mode="static">nokia6230</contextparameter> <contextparameter name="serialnumber" mode="static">355008002783631</contextparameter> <contextcategory name="hardwareplatform"> <contextparameter name="totalmemory" mode="static">6114</contextparameter> <contextparameter name="availablememory" mode="dynamic">4322</contextparameter> <contextcategory name="screensize"> <contextparameter name="width" mode="static">128</contextparameter> <contextparameter name="height" mode="static">128</contextparameter> </contextcategory> </contextcategory> <contextcategory name="softwareplatform"> <contextcategory name="accepteddatamodes"> <contextparameter name="images" mode="static">png, bmp</contextparameter> <contextparameter name="text" mode="static">plain, String, html</contextparameter> <contextparameter name="numeric" mode="static">int, short, long</contextparameter> <contextparameter name="videos" mode="static">3gp</contextparameter> <contextparameter name="applications" mode="static">vnd.nokia.ringing-tone </contextparameter> <contextparameter name="audio" mode="static">wav, midi, mp3, 3gp</contextParameter> <contextparameter name="other" mode="static">date</contextparameter> </contextcategory> <contextcategory name="api"> <contextparameter name="virtualmachine" mode="static">monty 1.0 VM</contextParameter> <contextparameter name="userinterfacelbrary" mode="static"> http://liris-7024/midpuilibrary.xml</contextparameter> <contextparameter name="serviceinvocationdescriptor" mode="static"> http://liris-7024/midpserviceinvocation.xml</contextparameter> </contextcategory> </contextcategory> </contextfacet> <contextfacet name="network"> <contextparameter name="connectionmode" mode="static">gprs</contextparameter> <contextparameter name="bandwidth" mode="static">236.8</contextparameter> <contextparameter name="delay" mode="static">135</contextparameter> <contextparameter name="connectionstate" mode="dynamic">connected</contextparameter> </contextfacet> <contextfacet name="userprofile"> <contextcategory name="basicinformation"> <contextparameter name="userid" mode="static">17</contextparameter> <contextparameter name="generaldomain" mode="static">medical</contextparameter> <contextparameter name="specificdomain" mode="static">nephrology</contextparameter> <contextparameter name="profession" mode="static">specialist</contextparameter> </contextcategory> <contextcategory name="preferences"> <contextparameter name="language" mode="dynamic">fr</contextparameter> <contextcategory name="display"> <contextparameter name="numericvalues" mode="static">curves</contextparameter> <contextparameter name="images" mode="static">fullscreen</contextparameter> </contextcategory> </contextcategory> </contextfacet> <contextfacet name="location"> <contextcategory name="physical"> <contextparameter name="country" mode="dynamic">france</contextparameter> <contextparameter name="city" mode="dynamic">villeurbanne</contextparameter> <contextparameter name="zipcode" mode="dynamic">69621</contextparameter> <contextparameter name="streetname" mode="dynamic">jean Capelle</contextParameter> <contextparameter name="streetnumber" mode="dynamic">7</contextparameter> <contextparameter name="building" mode="dynamic">501</contextparameter> <contextparameter name="room" mode="dynamic">330</contextparameter> </contextcategory> <contextcategory name="logical"> <contextparameter name="ipaddress" mode=" dynamic ">134.214.107.20</contextParameter> </contextcategory> </contextfacet> </contextprofile> Figure 15 - Exemple d une situation contextuelle Tarak CHAARI - 77 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture III. MODELISATION FONCTIONNELLE D UNE APPLICATION 1. Notion d entité logicielle Pour garantir l adaptation des applications aux différentes évolutions du contexte, nous devons nous intéresser à deux aspects : quoi adapter? Et comment réaliser cette adaptation? Dans le reste de ce chapitre, nous nous intéressons au quoi et nous détaillerons notre stratégie d adaptation (le comment) dans le chapitre suivant. A un instant donné lors de l utilisation d une application, on échange des données avec l un de ses services à l aide d une interface utilisateur. En conséquence, nous définissons une entité logicielle comme étant un triplet associant un service de l application, une interface utilisateur qui assure l interaction avec ce service et les données échangées entre l utilisateur et le service. La figure 16 présente l exemple concret d une entité logicielle où l utilisateur est en train de visualiser des images radios fournies par un service d images médicales. Le clic sur l URL d une image entraîne son téléchargement à partir du service de gestion des images médicales. Ce dernier prend en entrée l URL d une image et renvoie son contenu sous un format binaire. L image est affichée sur l interface utilisateur. Entité logicielle Service d images médicales URL Données IMAGE Service Figure 16 - Un exemple d'une entité logicielle Interface utilisateur L élément principal d une entité logicielle est son service puisque les données de l entité logicielle et son interface graphique dépendent fortement du service associé : ces données constituent les entrées et les sorties du service. L interface utilisateur d une entité logicielle est composée d une interface d entrée et d une interface de sortie. L interface d entrée permet de fournir les paramètres d entrée du service et l interface de sortie permet de transférer les données de sortie du service à l utilisateur. Tarak CHAARI - 78 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture 2. Notion de service Nous définissons un service comme un processus applicatif autonome. Un service fournit un ensemble de données de sorties suivant un ensemble de paramètres d entrée. Un service f qui prend en entrée un ensemble de paramètres INPUT=(x 1,x 2, x m ) et qui renvoie un ensemble de valeurs OUTPUT=(c 1, c 2 c n ) où INPUT et OUTPUT sont des vecteurs de valeurs typées. Ainsi un service peut être modélisé par une fonction f : OUTPUT = f (INPUT) où INPUT est le vecteur d entrée du service f et OUTPUT est son vecteur de sortie. Chaque composant c i de OUTPUT est une classe qui a un nom et un type (c i.name et c i.type). Le composant c i peut être récupéré à l aide de l opérateur [] sur le vecteur de sortie (c i = OUTPUT[i]). Nous associons à chaque composant c i, un vecteur ri=(ri a, ri b ) où ri a, ri b sont les valeurs renvoyées par le service f et associées au composant de sortie c i. les vecteurs ri peuvent être considérées comme des instances de c i. Cette définition générique permet d établir une structure d échange commune entre les services ; ceci facilite la composition et l adaptation des services. La figure 17 illustre notre modélisation d un service d une entité logicielle. INPUT=(x 1,x 2, x m ) f OUPUT=(c 1, c 2 c n ) ci entrée sortie + name Service Paramètre de sortie + type Valeur de sortie ri * + value Figure 17 - Modélisation d'un service d'une entité logicielle Contrairement à la majorité des travaux existants comme ceux de [Hamadi03], un service comprend une seule opération qui est représentée par la fonction f selon notre approche. Les autres travaux modélisent un service par un ensemble d opérations qui échangent des messages pour remplir une certaine tâche. L échange de messages se fait à travers des états représentés par un ensemble de propriétés (ou attributs en orienté objet). Nous remplaçons cette notion d état par la notion de dépendance d exécution de services que nous présentons dans le paragraphe suivant. Nous considérons que la connaissance de l état d un service est restreinte à ses développeurs ou concepteurs. Cependant, notre but est de réaliser l adaptation de services dont on ne connait pas forcément la conception ou la réalisation. Par ailleurs, nous considérons que ce choix reste compatible avec les modélisations existantes puisqu un service qui comprend plusieurs opérations peut être décomposé en un ensemble de services monoopération qui échangent des messages selon des dépendances d exécution que nous Tarak CHAARI - 79 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture modélisons dans le paragraphe suivant. 3. Notion de dépendance d exécution de services Les paramètres nécessaires à l exécution d un service f peuvent provenir de la sortie de plusieurs services f 1,f 2,f n. Nous disons dans ce cas que le service f dépend de f 1, f 2 et/ou f n. Nous pouvons avoir des dépendances en «et» si f dépend de f 1, f 2 et f n. Nous pouvons aussi avoir des dépendances en «ou» si f dépend de f 1, f 2 ou f n. Nous utilisons la notation (f 1 f 2 f n ) f pour modéliser la dépendance «f dépend de f 1, f 2 et f n». Dans le cas présenté dans la figure 18, le service f ne peut pas être offert à l utilisateur avant l exécution des services f 1, f 2 et f n. f 1 f 2 f n f Figure 18 Dépendance en «et» entre services Nous utilisons aussi la notation (f 1 f 2 f n ) f pour modéliser la dépendance «f dépend de f 1, f 2 ou f n». Dans ce cas, le service f ne peut être offert à l utilisateur que si au moins l un des services f 1, f 2 ou f n a été déjà invoqué. Ce cas est valable quand les paramètres nécessaires à l exécution du service f peuvent parvenir de l un des services f 1, f 2 f n. La figure 19 illustre le cas de la dépendance en «ou». f 1 f 2 f n f Figure 19 Dépendance en «ou» entre services Nous utilisons cette modélisation pour décrire tous les services de l application et leurs dépendances, formant ainsi le modèle fonctionnel de l application. Tarak CHAARI - 80 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture 4. Notion de modèle fonctionnel Nous définissons le modèle fonctionnel d une application par le réseau de pétri non autonome qui décrit tous les services d une application et toutes les dépendances d exécution entre eux. Les places dans un réseau de pétri représentent les descriptions des services de l application et les transitions détaillent les dépendances qui existent entre ces services. La racine de ce réseau est le descripteur du service initial offert à l utilisateur (par exemple, un service d authentification). Chaque transition est passée si l exécution de tous ses services d entrée (en cas d une dépendance en «et») ou l un de ses services d entrée (en cas d une dépendance en «ou») se passe sans erreur. Une condition générale supplémentaire qui concerne des événements externes (comme par exemple, «le terminal supporte des images») peut aussi être définie pour chaque transition. Par défaut, cette condition prend la constante booléenne «vraie». Chaque transition est chronométrée ; elle possède un délai d expiration au bout duquel une erreur est générée et présentée à l utilisateur pour éviter les blocages du coté du client (time deadlocks). Les transitions peuvent générer des erreurs si les conditions définies sur leurs paramètres de sortie ne sont pas satisfaites (Par exemple, «UserID is not null»). Ainsi, le passage aux services suivants est bloqué. A chaque moment de l exécution de l application, l utilisateur peut revenir en arrière dans le modèle fonctionnel par des transitions implicites qui sont déclenchées quand l utilisateur effectue une action explicite sur l interface d interaction avec l application ou bien quand le délai maximum d une transition est dépassé. Formellement, un modèle fonctionnel FM d une application est un tuple FM=(f 0, F, T) qui satisfait les recommandations suivantes : 1. F est un ensemble fini de services f 1, f 2,, f n 2. f 0 est la racine du réseau de pétri. Il représente le service initial de l application. 3. T est un ensemble fini de transitions t 1, t 2,, t m 4. Chaque transition t i est un triplet (d, gc, A) où : a) d est le délai maximum pour passer la transition b) gc est la condition générale de la transition c) A est un ensemble fini d associations a 1, a 2,, a l entre les services. d) a i est un ensemble fini de paires (inputexpression, destinationparameter) modélisant une association entre deux services en liant un paramètre de sortie inputexpression d un Tarak CHAARI - 81 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture service à un paramètre d entrée destinationparameter d un autre service. La valeur de inputexpression peut être une expression qui utilise un ensemble d opérateurs standard (comme l'addition de nombres, la concaténation de chaînes de caractères, l évaluation booléenne...) sur les paramètres de sortie des services sources. Chaque association a i représente un lien de dépendance d exécution entre un service source a i.sourceservice et un service destination a i.destinationservice. Ainsi, l exécution du service destination n est possible dans l application qu après avoir exécuté le service source de l association. La figure 20 donne le modèle fonctionnel d une application médicale simple. Cette application offre aux professionnels de santé un service d authentification (Authentication), un service qui permet de chercher un patient suivi par le professionnel de santé connecté (PatientList) et des services de consultation des informations stockées dans le dossier médical du patient sélectionné (Temperatures, RecordInfo, RecordImages). Authentication UserID PatientList PatientID PatientID PatientID Temperatures RecordInfo RecordImages Figure 20 - Le modèle fonctionnel d'une application médicale Nous avons utilisé le langage XML pour implémenter le modèle fonctionnel d une application. L élément racine de cette structure XML est «application». Chaque place est représentée par un élément «place» identifié par un attribut «id» et caractérisé par l url du service correspondant. Chaque place est composée d une méthode caractérisée par un identifiant, une description éventuelle et un ensemble de paramètres d entrée et de sortie. Chaque transition est modélisée par un élément «transition». Pour des raisons de cohérence du modèle et de la représentation des dépendances entre les services, il est à noter qu une transition ne concerne qu un et un seul service de sortie. Cependant, une transition peut être liée à plusieurs services d entrée. La figure 21 présente un diagramme de classes d un modèle fonctionnel et la figure 22 présente un extrait de la représentation XML du modèle fonctionnel de la figure 20. Tarak CHAARI - 82 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture Cet extrait présente la description d un service d authentification et d un service qui liste les patients suivis par le professionnel de santé authentifié. Un élément transition décrit l association entre ces deux services en spécifiant une condition de passage au service de la liste des patients : l identifiant de l utilisateur fourni par le service d authentification est non nul. Nous avons étendu le langage de description des réseaux de pétri PNML (Petri Net Markup Language) [Billington03] pour élaborer notre représentation XML des modèles fonctionnels d applications. Figure 21 - Diagramme de classes d'un modèle fonctionnel Tarak CHAARI - 83 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture <?xml version="1.0" encoding="iso-8859-1"?> <application> <!-- A service is described by its service id, url and methods (with parameters) --> <service id="authentication"> <url>http://secasserver.insa-lyon.fr/xmlrpc</url> <method id="sicom.identification"> <description>checks login and password of a Sicom user; returns userid and username </description> <input name="sicom.login" type="secas:string"/> <input name="sicom.password" type="secas:string"/> <output name="sicom.userid" type="secas:int"/> <output name="sicom.username" type="secas:string"/> </method> </service> <service id="patientlist"> <url>http://secasserver.insa-lyon.fr/xmlrpc</url> <method id="sicom.listepatient"> <description>returns the list of the dialyzed patients treated by the practionner identified by "sicom.userid"</description> <input name="sicom.userid" type="secas:int"/> <output name="sicom.recordid" type="secas:int"/> <output name="sicom.patientname" type="secas:string"/> <output name="sicom.patientbirthdate" type="secas:date"/> <output name="sicom.dialysismode" type ="secas:string"/> <output name="sicom.dialysistype" type ="secas:string"/> <output name="sicom.recordcreationdate" type="secas:date"/> </method> </service> <!-- other services... --> <!-- A transition specifies at least one association between a source service and a destination service. For each association we list its source and destination parameters, and define a maximum delay in seconds for the execution of all the source services of all the associations of the transition. A transition can have a condition for every entry service. The condition is represented by a logical expression on the output parameters of the entry service. --!> <transition id="t1" delay="100"> <generalcondition> <expression value= always true > </generalcondition> <association sourceservice="authentication" destinationservice="patientlist"> <sourceparameter methodid="sicom.identification" inputexpression="sicom.userid" condition= sicom.userid is not null /> <destinationparameter methodid="sicom.listepatient" parametername="sicom.userid"/> </association> </transition> <!-- other transitions...--> </application> Figure 22 - Extrait de la représentation XML du modèle fonctionnel d une application médicale Tarak CHAARI - 84 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture IV. OBJECTIFS DE NOTRE TRAVAIL Ce travail de thèse a pour objectif principal, la spécification et la réalisation d une plateforme d adaptation automatique d applications à de nouveaux contextes d utilisation. Nous définissons l adaptation d une application à une situation contextuelle par les mécanismes et les transformations nécessaires pour modifier le comportement de cette application afin qu elle puisse être utilisée d une façon efficace et conviviale dans l environnement décrit par la situation contextuelle. Nous avons nommé notre plateforme d adaptation «SECAS» (Simple Environment for Context-Aware Systems). SECAS est composée de trois couches : une couche de gestion du contexte, une couche d adaptation et une couche d intégration d applications. La couche de gestion du contexte assure la capture, l interprétation et la dissémination du contexte à la couche d adaptation. La couche d adaptation offre les fonctions et les outils nécessaires à l adaptation des applications à de nouveaux contextes d utilisation. Enfin, la couche de déploiement d applications permet à SECAS d intégrer de nouvelles applications pour les adapter. Dans ce travail de thèse, nous nous focalisons sur la couche d adaptation et plus particulièrement sur les moyens et outils de génie logiciel nécessaires pour garantir l adaptation des applications à de nouveaux contextes d utilisation. Cette adaptation doit être effectuée sur les trois composantes de chaque entité logicielle de l application : le service, l interface utilisateur et les données échangées entre l interface et le service. Cet intérêt particulier à la couche d adaptation est dû principalement à l absence d une approche complète d adaptation dans les systèmes sensibles au contexte. En effet, plusieurs travaux intéressants concernent la gestion du contexte au niveau de la capture, l interprétation et la dissémination du contexte alors que la question «comment adapter l application au contexte?» reste sans réponse précise et complète. Dans la suite de cette section, nous présentons les trois critères principaux que nous avons fixés pour la réalisation de notre plateforme : (1) Généricité Plusieurs standards de communication et de développement pour des environnements fixes et mobiles ont été testés et étudiés afin de choisir les meilleures technologies pour développer notre plateforme. Nous avons fait ce choix pour que SECAS puisse être utilisée dans le maximum d environnements et sur le maximum de types d applications. Nous considérons Tarak CHAARI - 85 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture qu une application existante est une boite noire composée d un ensemble d entités logicielles identifiées par les services (qui représentent les fonctionnalités) offerts par l application. Ceci nous permet de supporter un plus grand nombre d applications indépendamment de leur conception et de leur développement. Notre modèle garantit aussi la généricité du processus d adaptation. En effet, le modèle abstrait d entité logicielle est applicable à la majorité des applications. En outre, toutes les transformations et modifications d adaptation définies sur une entité logicielle restent d ordre générique et peuvent être appliquées indépendamment des technologies de conception et de développement de l application. Nous avons aussi choisi les technologies les plus génériques et les plus répandues (comme JAVA et les services WEB) pour développer notre plateforme. De plus, nous avons donné beaucoup d importance à l interaction homme-machine pour que notre plateforme puisse être utilisée dans plusieurs environnements cibles comme les PC standards, les téléphones mobiles ou les PC de poche. (2) Evolutivité Nous avons aussi accordé une grande importance à l évolutivité de notre plateforme afin de supporter le maximum de situations et le maximum d adaptations possibles. De nouveaux outils et moyens d adaptation doivent être facilement intégrés dans SECAS. Une interface d administration et des fichiers de configuration doivent être fournis pour réaliser cette adaptation sans toucher au code des applications et de la plateforme. De nouveaux fournisseurs de contexte doivent être aussi facilement ajoutés à la plateforme sans arrêter le fonctionnement de l application. L ajout de nouveaux services à une application existante est aussi prévu afin d enrichir des applications anciennes par de nouvelles fonctionnalités. (3) Intégrité de l information Le processus d adaptation que nous avons défini peut transformer ou modifier une donnée afin de pouvoir l exploiter dans un nouveau contexte. Certaines transformations sont avec pertes comme elles peuvent aussi donner des résultats incompatibles avec le résultat d origine. Nous accordons une grande importance à la qualité de l information produite par les services de l application. Tous les outils et les transformations d adaptation ne doivent pas biaiser l intégrité sémantique de l information transmise à l utilisateur. Par exemple, il est plus judicieux de remplacer une image médicale par le rapport textuel du médecin sur un terminal mobile de capacités limitées que de réduire la taille de l image et perdre sa valeur sémantique. Tarak CHAARI - 86 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture V. SECAS : PLATEFORME POUR L ADAPTATION D APPLICATIONS A DE NOUVEAUX CONTEXTES D UTILISATION 1. Présentation de la plateforme SECAS Les architectures présentées dans les travaux existants pour assurer la sensibilité au contexte (context-aware architectures) accordent une très grande importance à la gestion du contexte sans présenter comment modifier le comportement de l application pour qu elle s adapte au contexte. Dans notre architecture, nous dédions une couche entière à l adaptation et nous détaillons les différents modules et outils qui permettent de garantir cette adaptation. Nous avons aussi défini une couche de gestion du contexte afin de réaliser les étapes - que nous considérons classiques pour notre travail - de capture, interprétation, stockage et dissémination du contexte. Une dernière couche assure l intégration de nouvelles applications pour garantir leur adaptation. Nous avons choisi une architecture basée sur trois couches indépendantes afin d assurer une adaptation en aval du développement classique des services de base de l application. Ceci permet d ajouter la sensibilité au contexte à des applications non adaptées, où apparaissent de nouvelles situations contextuelles. Dans cette section nous détaillons SECAS, notre plateforme d adaptation avec ses trois couches et leurs différents composants. 2. Couche de gestion du contexte Pour pouvoir adapter une application au contexte, nous devons définir les moyens nécessaires pour la capture, l interprétation, le stockage et la dissémination du contexte. Nous avons regroupé ces quatre fonctions dans la couche de gestion du contexte. La fonction principale assurée par cette couche est la capture du contexte. Le contexte peut parvenir de plusieurs sources comme les capteurs physiques, les capteurs logiques ou les capteurs virtuels comme présenté dans l état de l art de ce mémoire (paragraphe IV.1 du chapitre I). Puisque le contexte capturé peut ne pas être significatif à l'application dans son format brut, un module d'interprétation du contexte traduit le contexte de bas niveau en une représentation de niveau plus élevé. Par exemple, il transforme des coordonnées géographiques en une adresse physique (Rue, ville et pays). Ensuite, les données contextuelles interprétées sont stockées dans un registre contextuel (context repository) sous le format XML présenté dans le paragraphe II.2 de ce chapitre. Enfin, un courtier (broker) assure la communication entre la couche de gestion du contexte et la couche d adaptation. Il informe les différents modules d adaptation des changements éventuels du contexte. Dans la Tarak CHAARI - 87 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture suite de cette section, nous détaillons les différents composants de la couche de gestion du contexte. 2.1 FOURNISSEUR DE CONTEXTE (CONTEXT PROVIDER) Un fournisseur de contexte est un composant logiciel lié à un ou plusieurs dispositifs matériels physiques ou virtuels qui assurent la capture du contexte de l environnement de l utilisateur ou de l application. Ce composant logiciel assure l interprétation des données capturées dans un format directement exploitable par la couche d adaptation. Par exemple, un capteur de température peut être associé à un module logiciel pour détecter le dépassement d un seuil fixé. La figure 23 présente la modélisation d un fournisseur de contexte. Figure 23 - Modélisation d'un fournisseur de contexte 2.2 REGISTRE DE CONTEXTE (CONTEXT REPOSITORY) Le registre de contexte stocke les paramètres interprétés du contexte sous le format XML défini dans le paragraphe II.2. Pour chaque session utilisateur, un profil de contexte est créé comme présenté dans la figure 15. Dès la connexion d un utilisateur, le dernier profil de contexte associé à cet utilisateur est chargé. Ensuite, il est rafraîchi par les différents fournisseurs de contexte au cours de l utilisation de la plateforme. Le taux de rafraîchissement dépend fortement du changement de contexte au niveau des fournisseurs. Par exemple, le type du terminal utilisé est un élément statique dans une session utilisateur. Par contre, la localisation de l utilisateur peut varier rapidement dans une même session s il est en déplacement dans un véhicule. Figure 24 - Modélisation d'un registre de contexte La figure 24 illustre la modélisation d un registre de contexte. Il fournit deux fonctions principales : getcontextparameter() et setcontextparameter() pour accéder à (ou modifier) la Tarak CHAARI - 88 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture valeur d un paramètre de contexte dans son profil correspondant. 2.3 COURTIER DE CONTEXTE (CONTEXT BROKER) Le courtier de contexte assure l échange de données entre la couche d adaptation et le registre de contexte d une part et entre les fournisseurs et le registre d autre part. Les différents composants de la couche d adaptation doivent s abonner au courtier pour pouvoir accéder aux différents paramètres du contexte dans le registre. Le courtier offre deux modes d échange d information : «Push» et «Pull». Le mode «Push» permet d informer la couche d adaptation à chaque changement d un paramètre dynamique du contexte. Le mode «Pull» est dédié aux paramètres statiques du contexte dont l accès est conditionné par une demande explicite de la couche d adaptation. Les fournisseurs doivent aussi s abonner au courtier pour pouvoir stocker les paramètres de contexte capturés et interprétés dans le registre du contexte. Le courtier transfère directement les paramètres contextuels dynamiques à la couche d adaptation avant leur stockage dans le registre contexte pour garantir une adaptation rapide à des changements fréquents du contexte. La figure 25 présente la modélisation d un courtier de contexte avec les différentes entités qu il utilise pour échanger les paramètres du contexte avec le registre et le fournisseur du contexte d une part et avec la couche d adaptation d autre part. Figure 25 - Modélisation d'un courtier de contexte 3. Couche d adaptation La couche d adaptation permet la mise à jour et la réactualisation automatique des applications existantes à de nouveaux contextes d utilisation. Cette adaptation touche les trois composantes de chaque entité logicielle de l application : le service, l interface utilisateur et les données échangées entre l utilisateur et le service. Nous dédions un module à l adaptation de chaque composante d une entité logicielle. Ces trois modules effectuent des adaptations «intra-entité logicielle» en modifiant le comportement de son service, en transformant les données que le service échange avec l utilisateur ou en générant automatiquement une interface graphique adaptée au contexte d utilisation de l entité logicielle. Ces trois modules sont orchestrés par un gestionnaire d applications qui assure l adaptation «inter-entités Tarak CHAARI - 89 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture logicielles» en modifiant la structure globale du modèle fonctionnel. Nous détaillons dans les paragraphes suivants les différents composants de la couche d adaptation. 3.1 INTERFACE DE CONSOMMATION DE CONTEXTE L interface de consommation de contexte (context consumer) offre les différentes fonctions nécessaires pour pouvoir échanger les paramètres du contexte entre la couche d adaptation et la couche de gestion de contexte. En effet, les trois modules d adaptation de services, de données et de présentation consomment du contexte et doivent être avertis des changements des différents paramètres du contexte. Ces trois modules s abonnent au courtier (context broker) en indiquant les paramètres (context parameters) qui leur sont pertinents et le mode (mode) d échange de données avec la couche de gestion du contexte (Push ou Pull). L interface de consommation de contexte que nous avons conçue est indépendante du modèle de contexte utilisé. Il suffit de préciser le nom du paramètre éventuellement préfixé avec les informations nécessaires pour trouver ce paramètre dans le modèle utilisé du contexte. Par exemple, pour le modèle que nous avons utilisé dans la figure 15, (context.terminal.screensize.width) référence le paramètre (width) de la catégorie (screensize) de la facette (terminal) du contexte. La figure 26 illustre l interaction possible (opération d abonnement subscribe) entre l interface de consommation du contexte et le courtier. Figure 26 - Interaction entre l'interface de consommation du contexte et le broker 3.2 MODULE D ADAPTATION DE SERVICES Ce module applique les transformations nécessaires sur le modèle fonctionnel d une application pour modifier son comportement suivant une situation contextuelle donnée. Ce module s appuie sur un gestionnaire d adaptation de services (service adaptation manager) pour appliquer un ensemble de règles d adaptation (adaptation rules) définies par le concepteur de l application à adapter. Ces règles configurent des entités d adaptation, que nous avons appelés adaptateurs (adapters), pour exécuter un ensemble d actions d adaptation (adaptation actions) sur le modèle fonctionnel de l application. Par exemple, ces actions peuvent remplacer un service par un autre plus adéquat à la nouvelle situation ; elles peuvent aussi éclater un service sur plusieurs services si le résultat est trop volumineux pour la mémoire du terminal utilisé Nous formalisons ces actions d adaptation et nous détaillons Tarak CHAARI - 90 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture notre stratégie d adaptation de services dans la section II du chapitre suivant. La figure 27 présente les entités principales du module d adaptation de services. Figure 27 Architecture générale du module d'adaptation de services 3.3 MODULE D ADAPTATION DE DONNEES Ce module assure l adaptation des données multimédia renvoyées par les services vers l utilisateur. Il s appuie sur un gestionnaire d adaptation de contenu (content adaptation manager) pour instancier un adaptateur de contenu (content adapter) pour chaque service de l application. Il identifie les données de sortie non adaptées à la situation contextuelle en question. Les adaptateurs de contenu utilisent un mandataire d adaptation de contenu (content adaptation proxy) qui exécute un ensemble de services d adaptation de contenu (content adaptation services) afin d effectuer les transformations nécessaires. Nous détaillons notre stratégie d adaptation de données dans la section III du chapitre suivant. La figure 28 présente les entités principales du module d adaptation de services. Figure 28 Architecture générale du module d'adaptation de données 3.4 MODULE D ADAPTATION DE PRESENTATION Ce module assure l adaptation de la présentation des données échangées avec les différents services de l application. Il se base sur un gestionnaire d adaptation de présentation (presentation adaptation manager) pour générer une interface d interaction avec chaque service adapté de l application. Le code de cette interface est produit par un générateur d interface utilisateur (user interface generator). Le processus de génération dépend principalement du type des données échangées avec les services adaptés, de la facette «terminal» du contexte et des préférences de l utilisateur dans la facette «utilisateur». Des facilités de navigation entre les entités logicielles sont aussi générées pour que l utilisateur puisse interagir avec tous les services de l application. Les interfaces générées sont enfin déployées sur le terminal de l utilisateur pour interagir avec l application adaptée. Ces interfaces sont mises en cache sur le serveur SECAS pour ne pas relancer tout le processus d adaptation de présentation chaque fois que le même utilisateur accède à une application adaptée dans le même contexte. La figure 29 donne l architecture générale du module Tarak CHAARI - 91 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture d adaptation de présentation. Nous détaillons cette architecture dans la section IV du chapitre IV. Figure 29 - Architecture générale du module d'adaptation de présentation 3.5 GESTIONNAIRE D APPLICATIONS Le gestionnaire d applications de SECAS (SECAS application manager) orchestre les trois modules d adaptation : de services, de données et de présentation. Le gestionnaire d applications lance le processus d adaptation de services en sollicitant le module d adaptation de services. Ce dernier notifie le gestionnaire d applications lorsqu il termine l adaptation de services. Le gestionnaire d applications peut ainsi transmettre le modèle fonctionnel adapté au module d adaptation de contenu pour adapter les données d entrée et de sortie des services. Figure 30 - Orchestration du processus d'adaptation par le gestionnaire d'applications Enfin, le gestionnaire d applications notifie le module d adaptation de présentation pour déclencher le processus de génération automatique d interfaces utilisateur adaptées au contexte en question. Le gestionnaire d applications gère les différents modèles fonctionnels adaptés pour chaque situation contextuelle. Il associe un modèle fonctionnel à chaque session Tarak CHAARI - 92 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture utilisateur et assure son adaptation dynamique aux changements du contexte. Il peut réutiliser un ancien modèle fonctionnel adapté si le même utilisateur se connecte dans la même situation contextuelle associée au modèle fonctionnel en question. La figure 30 présente le rôle du gestionnaire d applications dans l orchestration du processus d adaptation de services, de données et de présentation. 4. Couche de déploiement d applications Couche de gestion du contexte stockage du contexte Gestionnaire de contexte broker Interpréteur Interpréteur Fournisseur de de contexte contexte de contexte Abonnement() push() pull() Consommateur de contexte Couche d adaptation Module d adaptation des données BR Module d adaptation de présentation IUA IUA Module d adaptation des services Gestionnaire d applications MFA MFA MFA Flux de données/contrôle BR MF/A IUA héritage dépendance Base de règles d adaptation Modèle fonctionnel / adapté Interface utilisateur adaptée Services de base Données de l application MF Couche de déploiement d applications Figure 31 - Architecture générale de SECAS La couche de déploiement d applications permet d ajouter de nouvelles applications dans SECAS. L administrateur d une nouvelle application doit déployer son modèle fonctionnel en décrivant les différents services de l application et leurs dépendances. L élaboration du modèle fonctionnel peut se faire manuellement ou assistée par un outil de détection automatique des échanges de données entre l utilisateur et l application. Les services de base Tarak CHAARI - 93 - Thèse de doctorat

Chapitre III Contributions : Définitions, Objectifs et Architecture de l application peuvent renvoyer des données extraites d une source de données. Le modèle fonctionnel est la seule description nécessaire pour intégrer une application dans SECAS. La figure 31 présente l architecture générale de la plateforme SECAS avec ses trois couches : la couche de gestion du contexte, la couche d adaptation et la couche de déploiement d applications. VI. CONCLUSION Dans ce chapitre, nous avons défini les notions de contexte, d adaptation et de modèle fonctionnel, utiles pour élaborer notre approche d adaptation des applications à de nouveaux contextes d utilisation. Puis, nous avons présenté notre objectif qui consiste à réaliser une plateforme générique d adaptation des applications au contexte d utilisation. Avant Nous avons enfin présenté l architecture de notre plate-forme d adaptation d applications à de nouveaux contextes d utilisation, que nous avons nommée SECAS. Cette plate-forme est basée sur trois couches. La première couche assure la gestion du contexte depuis sa capture, son interprétation et sa dissémination à la couche d adaptation. La deuxième couche assure l adaptation du comportement de l application au contexte capturé. Cette adaptation est assurée sur les trois composantes des entités logicielles de l application : le service, l interface utilisateur et les données échangées avec le service. La troisième couche permet d intégrer de nouvelles applications à la plateforme en vue de leur adaptation. Dans ce travail de thèse, nous n irons pas loin dans la couche de gestion de contexte. Notre contribution principale se situe dans la couche d adaptation que nous détaillons dans le chapitre suivant. Tarak CHAARI - 94 - Thèse de doctorat

CHAPIITRE IIV - CONTRIBUTIIONS I : STRATEGIIE D ADAPTATIION P AU CONTEXTE Sans innovation, la stratégie est inutile; sans stratégie, l'innovation n'a pas de but (John KAO)

Chapitre IV Contributions : Stratégie d adaptation au contexte TABLE DES MATIERES I. PRESENTATION DE NOTRE STRATEGIE D ADAPTATION 97 II. ADAPTATION FONCTIONNELLE 98 1. Principe de l adaptation fonctionnelle 98 2. Règles d adaptation fonctionnelle 99 3. Opérateurs d adaptation fonctionnelle 101 4. Processus d adaptation fonctionnelle dans SECAS 118 5. Synthèse sur l adaptation fonctionnelle dans SECAS 120 III. ADAPTATION DE CONTENU 120 1. Principe de l adaptation de contenu 120 2. Module d adaptation de contenu 122 3. Planification de l adaptation de contenu [Berhe05] 124 4. Synthèse sur l adaptation de contenu dans SECAS 129 IV. ADAPTATION DE PRÉSENTATION 129 1. Principe de l adaptation de présentation 129 2. Modélisation d une interface utilisateur dans SECAS 130 3. Processus de génération automatique d interfaces adaptées 133 4. Synthèse sur l adaptation de présentation dans SECAS 137 V. CONCLUSION 138 Tarak CHAARI - 96 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte I. PRESENTATION DE NOTRE STRATEGIE D ADAPTATION Le domaine de la sensibilité au contexte (context-awareness) a conduit les chercheurs à se focaliser sur la couche de gestion de contexte (capture, interprétation, modélisation et dissémination du contexte). D autres chercheurs ont travaillé dans le domaine de la conception d applications sensibles au contexte. Cependant, leurs solutions sont ad hoc et spécifiques au domaine de l application étudiée (principalement dans le domaine du tourisme). Nous remarquons l absence d une méthodologie complète et générique pour l adaptation de l application au contexte. En effet, la majorité des contributions existantes dans ce domaine (comme [Aksit03], [Ketfi02], [Dowling01], [Chefrour02] ) se limitent à l assemblage ad-hoc de composants pré-développés en fonction du contexte. Selon notre point de vue, l assemblage de composants n est qu un opérateur parmi plusieurs actions d adaptation possibles sur une application. Modèle fonctionnel initial Module d adaptation fonctionnelle Modèle fonctionnel avec comportement adapté de services contexte Module d adaptation de contenu Interface utilisateur adaptée Module d adaptation de présentation Modèle fonctionnel avec données adaptées Figure 32 - Principe général de l'adaptation dans SECAS Dans ce chapitre nous détaillons notre approche d adaptation d applications à de nouveaux contextes d utilisation en se basant sur la description fonctionnelle de leurs services (Modèle fonctionnel). Cette approche adapte les trois composants de chaque entité logicielle de l application (les services, les données et la présentation). En premier lieu, notre approche assure l adaptation du comportement des services de l application (adaptation fonctionnelle). Par exemple, un service qui renvoie la longue liste des patients suivis par un médecin donné est substitué automatiquement par un autre service qui renvoie les résultats par blocs de dix Tarak CHAARI - 97 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte patients à la fois. Cette étape est suivie d une adaptation des données échangées avec les services adaptés (adaptation de contenu). Par exemple, le service précédent peut renvoyer les photos d identités des patients suivis par le médecin connecté. Le format des photos doit être adapté aux types d images supportées par le terminal utilisé. Enfin, une interface graphique adaptée au contexte d utilisation de l application (environnement d exécution de l interface) est générée automatiquement pour que l utilisateur final de l application puisse interagir avec les services et les données adaptées (adaptation de présentation). La figure 32 présente le principe général de notre approche d adaptation. Dans la suite de ce chapitre nous présentons les trois types d adaptation que nous avons élaborés durant ce travail de thèse. II. ADAPTATION FONCTIONNELLE 1. Principe de l adaptation fonctionnelle Une application offre un ensemble de services à l utilisateur. Certains services peuvent être non exploitables lors du changement du contexte. Par exemple, un service qui retourne un gros volume de données n est plus utilisable sur un terminal de faible mémoire de traitement. Le comportement de ce service doit être adapté aux limitations matérielles du dispositif de l utilisateur. Dans ce cas, nous décomposons les données renvoyées par le service en plusieurs blocs, chacun étant directement exploitable par le terminal. Nous remplaçons le service original par un autre service qui renvoie les données bloc par bloc. Nous définissons l adaptation fonctionnelle d une application par le changement du comportement de ses services pour qu ils puissent être utilisés d une manière plus conviviale et plus correcte dans le contexte en question. Dans SECAS, l adaptation fonctionnelle consiste à transformer le réseau de pétri de dépendances de services en un autre réseau de pétri de services adaptés. Cette transformation porte sur les places du réseau de pétri (les services) et aussi sur ses arcs (dépendances entre les services). Pour des raisons de simplification, nous utiliserons aussi le terme adaptation de services dans quelques paragraphes de ce mémoire pour désigner la même notion d adaptation fonctionnelle. Nous avons défini un ensemble d opérateurs d adaptation afin de réaliser les transformations sur le modèle fonctionnel de l application. Nous avons défini deux types principaux d opérateurs d adaptation. Le premier type concerne les opérateurs inter-services Tarak CHAARI - 98 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte qui sont gérés par le gestionnaire d adaptation de services. Il spécifie les opérateurs qui peuvent être appliqués sur le modèle fonctionnel d une application. Le second concerne les opérateurs intra-services qui sont gérés par des adaptateurs associés à chaque service. Ce deuxième type d opérateurs contient deux sous-types : les opérateurs de filtrage des entrées/sortie des services et les opérateurs de gestion des versions des services. Ces opérateurs sont utilisables dans des règles d adaptation définies par l administrateur de l application. Nous décrivons ces règles dans le paragraphe 3 et nous détaillons les différents types d opérateurs d adaptation dans le paragraphe 4 de cette section. 2. Règles d adaptation fonctionnelle Une règle d adaptation fonctionnelle définit les actions d adaptation à effectuer sur le modèle fonctionnel de l application dans une situation contextuelle donnée. Nous modélisons une règle par une paire (Expressions, Actions). {( context.terminal.accepteddatatypes.acceptimages) ( f F i f.output[i].type= image ) lockservice(f) } Figure 33 - Exemple d'une règle d'adaptation La partie Expressions décrit une situation contextuelle de l application. Elle est définie par un ensemble d expressions logiques basées sur des opérateurs logiques simples comme «equal», «superior», «inferior», «exist» Ces expressions concernent les valeurs des paramètres du contexte et les propriétés de l application. Dans le cas où l expression est une condition sur les paramètres du contexte, elle est modélisée par le triplet (paramètre de contexte, opérateur logique, valeur). Par exemple le triplet (context.terminal.softwareplatform.accepteddatatypes.acceptimages, equals, false) décrit une situation où le terminal utilisé n accepte pas les images. Pour simplifier l écriture de cette expression, nous utilisons la formule logique équivalente suivante : ( context.terminal.accepteddatatypes.acceptimages) Dans le cas où l expression concerne des propriétés de l application, nous utilisons des expressions existentielles suivies de conditions sur les différents éléments du modèle fonctionnel. Ces expressions doivent respecter la structure d un modèle fonctionnel présentée dans le paragraphe III.4 du chapitre 3 de ce mémoire). Les expressions existentielles peuvent concerner l ensemble F des services de l application, l ensemble T des transitions du modèle fonctionnel, le vecteur d entrée (et/ou de sortie) de chaque service f et/ou l ensemble des associations A de chaque transition ti. On modélise ces expressions existentielles par des triplets : (entité élémentaire, opérateur existentiel, ensemble fini d éléments). Par exemple, Tarak CHAARI - 99 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte l expression (f, belongsto, F) ^ (i, belongsto, [0..n])^(f.OUTPUT[i].type, equals, secas:image), décrit l existence d un service f qui fournit un paramètre de sortie de type image. Pour simplifier l écriture de cette expression, nous utilisons la formule logique équivalente suivante : ( f F i [0..n] f.output[i].type= secas :image ) La partie «Actions» décrit une liste d actions à effectuer lorsque l évaluation des expressions est vraie. Chaque action correspond à un opérateur d adaptation qui définit la transformation à effectuer pour modifier le comportement de l application ou d un service particulier. Nous reviendrons en détails sur ces opérateurs d adaptation dans la section II.3. La figure 33 donne un exemple simple de règle d adaptation où la partie «expressions» est composée de deux expressions logiques exprimant la situation contextuelle : «le terminal ne supporte pas les images et il existe un service qui fournit un paramètre de sortie de type image». L action associée à cette situation est «bloquer l accès au service». Pour éviter les conflits d exécution et d interprétation des règles, l administrateur de chaque application doit spécifier une liste de règles d adaptation avec un ordre de priorité afin d éviter les conflits d exécution et d interprétation. En effet, dans le cas général, l exécution des règles n est pas commutative : l application d une règle A suivie d une deuxième règle B ne donne pas le même résultat d adaptation que l exécution de la règle B suivie de la règle A. L ordre de priorité d exécution est représenté par une hiérarchie numérique. Par exemple, la règle 1.2.3 est exécutée avant les règles de priorité 1.2.3.1, 1.2.3.1.1, 1.2.3.1.2. Elle sera aussi appliquée avant les règles de priorité 1.2.4, 1.2.5, 1.2.6 Cette numérotation permet d insérer facilement des règles avec un ordre de priorité intermédiaire entre deux règles déjà définies. Il est à noter que lors de l insertion d une règle, tout le processus d adaptation fonctionnelle est réinitialisé pour garantir la cohérence du résultat d adaptation. Ceci est dû à la non commutativité de l application des règles d adaptation. L administrateur doit aussi spécifier le mode d exécution de chaque règle. Nous avons défini deux modes : le mode simple et le mode récursif. Avec le mode simple, la règle est vérifiée une seule fois pour toutes les entités du modèle. Avec le mode récursif, la règle est réévaluée plusieurs fois d une façon récursive sur toutes les entités du modèle fonctionnel jusqu à ce que la partie expressions soit évaluée a false. Le mode récursif permet de réitérer l application de la règle d adaptation et d aboutir ainsi à un degré d adaptabilité plus élevé. Les règles d adaptation fonctionnelle peuvent être génériques ou spécifiques. Les règles génériques sont applicables sur plusieurs applications et sur plusieurs services (comme la Tarak CHAARI - 100 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte règle de la figure 33). Les règles spécifiques concernent des services particuliers et permettent de réaliser une adaptation personnalisée. Des règles spécifiques peuvent aussi être réalisées en se basant sur d autres règles génériques déjà enregistrées. Ceci peut être réalisé en ajoutant des conditions sur le nom du service. Dans les paragraphes suivants nous détaillons les types d opérateurs d adaptation que nous avons définis et nous présentons le processus d adaptation fonctionnelle d une application à de nouveaux contextes d utilisation. 3. Opérateurs d adaptation fonctionnelle 3.1 DEFINITION D UN OPERATEUR D ADAPTATION FONCTIONNELLE Chaque action définie dans la partie «actions» des règles d adaptation correspond à un opérateur d adaptation. Un opérateur d adaptation fonctionnelle effectue des transformations sur le modèle fonctionnel de l application en modifiant ses services ou ses transitions. Nous modélisons un opérateur d adaptation par une fonction operator qui prend en entrée un ensemble «parameters» de paramètres typés et qui peut fournir un résultat res. res = operator ( parameters) Chaque paramètre (ainsi que le résultat de l application de l opérateur) représente une instance d un élément «FunctionalModelElement» du modèle fonctionnel de l application. Cet élément peut être un modèle fonctionnel, un service, un ensemble de paramètres d entrée/sortie, une transition... Par exemple, dans la figure 33, l opérateur utilisé dans la règle spécifiée est lockservice. Il prend en entrée un service du modèle fonctionnel de l application et bloque l accès à ce service ainsi qu à tous les services qui en dépendent. Cet opérateur fournit en sortie un nouveau modèle fonctionnel différent de l initial. Nous revenons à cet opérateur en détails dans la section 3.3.4 de cette partie. La figure 34 illustre le diagramme de classes d un opérateur d adaptation fonctionnelle (Functional Adaptation Operator). Il utilise un ensemble de paramètres d adaptation (Adaptation Parameters) et produit un résultat d adaptation (Adaptation Result). Les paramètres et les résultats de ces opérateurs sont des éléments du modèle fonctionnel (Functional Model Elements). Tarak CHAARI - 101 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte Figure 34 - Modélisation d'un opérateur d'adaptation fonctionnelle Dans le cas où l opérateur effectue des modifications sur un service, nous le qualifions d opérateur intra-service. Dans le cas où l opérateur effectue des transformations sur la structure globale du modèle fonctionnel nous le qualifions d opérateur inter-services. Nous détaillons les opérateurs intra-service dans le paragraphe 3.2 et les opérateurs inter-services dans la section 3.3. 3.2 OPERATEURS D ADAPTATION INTRA-SERVICE Un opérateur d adaptation intra-service effectue des transformations locales sur un service de l application. Ce type d opérateurs prend en entrée le service (f) à adapter et produit en sortie un autre service adapté (res) selon la nature de l opérateur et ses paramètres d entrées (parameters). L exécution de ce type d opérateur est assurée par une entité d adaptation associée à chaque service de l application. Nous appelons cette entité «adaptateur». L adaptateur constitue un intermédiaire entre l utilisateur final de l application et le service original qui lui est associé par le gestionnaire d adaptation de services. Les règles d adaptation configurent les adaptateurs pour qu ils exécutent une liste d opérateurs d adaptation intra-service suivant les règles d adaptation fournies à la plateforme. Avant leur configuration, les adaptateurs renvoient le résultat du service original associé. La figure 35 présente l architecture globale d un adaptateur. Ce dernier consomme une partie spécifique du contexte c que nous notons Cad(c). Cette partie du contexte est définie par les règles d adaptation. En effet, dès qu un service initial de l application est concerné par une règle d adaptation, le gestionnaire d adaptation de services abonne son adaptateur aux paramètres contextuels mentionnés dans cette règle. L adaptateur prend aussi en entrée, le vecteur d entrée INPUT du service d origine. Il fournit une sortie adaptée OUTPUT qui dépend des opérateurs d adaptation qui lui ont été affectés par les règles d adaptation et de la sortie initiale OUTPUT. Tarak CHAARI - 102 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte Sortie adaptée (OUTPUT ) Paramètres d entrée du service initial (INPUT) Adaptateur (ad) Op 1 Op 2 Op n Liste d opérateurs Vue du contexte cad(c) Entrée (INPUT) Sortie initiale (OUTPUT) Service initial (f) Figure 35 - Entité d'adaptation d'un service initial f L adaptateur intercepte l appel vers le service initial f et réalise la fonction d adaptation suivante : ad(input, cad(c))/{fa, fb...} = Op 1 Op 2 Op n ( f) où : - est l opérateur de composition de fonctions. Par exemple f f(x) = f (f(x)) - ad est l adaptateur au contexte - {fa, fb } est l ensemble des versions disponibles du service initial f. Une version particulière peut être activée selon le contexte. - INPUT est le vecteur de paramètres d entrée du service initial f. - cad(c) est la vue du contexte c utile à l adaptateur ad pour effectuer l adaptation. (Op 1, Op 2, Op n ) est la liste des opérateurs d adaptation intra-services affectée à l adaptateur par les actions des règles d adaptation. L adaptateur garantit l exécution des actions d adaptation intra-service (SActions : Service adaptation Actions) indiquées dans les règles d adaptation. Nous rappelons que chaque action définie dans ces règles correspond à un opérateur d adaptation fonctionnelle. Nous distinguons deux types d actions d adaptation intra-service : filtrage des sorties de services (OActions : Output adaptation Actions) et gestion des versions de services (VActions : Version adaptation Actions) comme l activation d une version, ajout/suppression d une version 3.2.1 Actions d adaptation des sorties de services (OActions) Les actions d adaptation fonctionnelle des sorties de services (Output adaptation Actions) correspondent à des opérateurs qui réalisent des transformations sur le vecteur de sortie OUTPUT d un service initial f. Ils fournissent un nouveau service res qui représente une structure de sortie différente de celle du service initial f. Dans ce qui suit nous présentons quelques exemples de ces opérateurs. Bien qu ils soient inspirés d opérateurs SQL, nous Tarak CHAARI - 103 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte insistons sur le fait que nos opérateurs sont appliqués aux vecteurs de sortie résultant de l exécution de services et non à des tables soumises aux contraintes d intégrité des bases de données. (1) Projection Cet opérateur permet de choisir un sous-ensemble de paramètres de sortie d un service afin de sélectionner des paramètres précis de sa sortie. Il est appliqué sur un service f qui produit un nouveau service f tel que : f = projection(f, params) où : OUTPUT=f(INPUT) avec OUTPUT=(c 1,..., c n ) params= (c i,..., c k ) avec {c i,..., c k } OUTPUT et 0<i<= k<=n f (INPUT) = OUTPUT = (c 1,..., c k ) Cet opérateur est utile pour sélectionner un sous-ensemble de paramètres de sortie d un service ou pour masquer des paramètres de sortie à l utilisateur. Vecteur de sortie d un service infosclients idclient nomclient photoclient Résultat de l application de la projection idclient nomclient 1 2 Nom 1 Nom 2 1.jpg 2.jpg Nom 1 Nom 2 1.jpg 2.jpg n Nom n n.jpg Nom n n.jpg projection(infoclients, (idclient, nomclient)) Figure 36 - Exemple d utilisation de l'opérateur de projection La figure 36 illustre un exemple où le paramètre de sortie photoclient d un service infosclients est masqué à l utilisateur final de l application avec l opérateur de projection. (2) Sélection Cet opérateur permet d enlever les instances qui ne sont pas pertinentes pour l utilisateur final de l application dans une situation contextuelle donnée. La sélection est effectuée selon un critère explicite exprimé selon une syntaxe analogue à l opérateur SQL SELECT. f = selection(f, params) où : Tarak CHAARI - 104 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte - f(input)= OUTPUT = (c 1,..., c n ) - params = ( param, (and/or, param)* ) - param = (c i, cmp, value) avec 0<=i<=n, cmp {=,>, <, <>,!=} et value est une constante du même type que le paramètre c i. Résultat de sortie d un service infosclients idclient nomclient photoclient Résultat de l application de la selection idclient nomclient photoclient 1 2 3 4 Nom 1 Nom 2 Nom 3 Nom 4 1.jpg 2.jpg 3.jpg 4.jpg 3 Nom 3 3.jpg selection(infoclients, (idclient, =,3)) Figure 37 - Exemple d utilisation de l opérateur de sélection La figure 37 illustre un exemple de sélection d un client particulier parmi les clients renvoyés par le service infosclients. (3) Produit Cet opérateur permet d ajouter d autres paramètres de sortie à un service en combinant sa sortie sous forme de produit cartésien avec le résultat d un autre service. Cet opérateur est analogue au produit cartésien entre deux tables SQL. Il prend comme entrées le service original f et le service qui va fournir les paramètres supplémentaires f. Le résultat de l application de cet opérateur fournit un service res qui réalise le produit cartésien des deux structures de sortie OUTPUT et OUTPUT des services f et f respectivement. res = produit ( f, f ) où : - f(input) = OUTPUT, est le service initial avec OUTPUT=(c 1,..., c n ) et INPUT=(x 1,..., x m ) - f (INPUT ) = OUTPUT est le service qui va fournir les paramètres supplémentaires avec OUTPUT =(c 1,..., c n ) et INPUT =(x 1,..., x m ) - res(input res )=OUTPUT res est le service qui prend en entrée le vecteur INPUT res =( x 1,..., x m, x 1,..., x m ) et qui fourni en sortie le vecteur OUTPUT res =( c 1,..., c n, c 1,..., c n ) Par exemple, considérons un service reservationhotel de réservation de chambres dans un hôtel et un service reservationvol de réservation de vols. L utilisateur final de l application Tarak CHAARI - 105 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte peut exprimer une préférence pour choisir le vol et la chambre qui lui conviennent dans une seule action d interaction. Le produit des résultats de ces deux services lui permet d avoir cette nouvelle fonctionnalité. La figure 38 présente un exemple de résultat fourni par l application de l opérateur «produit» sur ces deux services. Résultat de sortie du service reservationvols numerovol aller retour TU750 Le 18/03/2007 de Lyon à 11h35. Arrivé à Tunis à 13h25 Le 12/04/2007 de Tunis à 16h10. Arrivé à Lyon à 18h00 Résultat de sortie du service reservationhotel NumeroChambre photointérieure 313 411 photoi313.jpg photoi414.jpg Résultat de sortie du service res = produit(reservationvol,reservationhotel) numerovol aller retour NumeroChambre photointérieure TU750 Le 18/03/2007 de Lyon à 11h35. Arrivé à Tunis à 13h25 Le 12/04/2007 de Tunis à 16h10. Arrivé à Lyon à 18h00 313 photoi313.jpg TU750 Le 18/03/2007 de Lyon à 11h35. Arrivé à Tunis à 13h25 Le 12/04/2007 de Tunis à 16h10. Arrivé à Lyon à 18h00 411 photoi414.jpg Figure 38 - Exemple d'utilisation de l'opérateur «produit» (4) Union Cet opérateur permet d ajouter d autres instances des paramètres de sortie d un service f en les intégrant à la fin des instances de sortie d un autre service f. Cet opérateur n est applicable que si les vecteurs de sorties OUTPUT et OUTPUT respectifs de f et de f ont le même nombre de paramètres de sortie (OUTPUT.length = OUTPUT.length). Cet opérateur prend en entrée le service initial f, le service qui va fournir les instances supplémentaires f et leurs vecteurs d entrée respectifs INPUT et INPUT. Le résultat de l application de cet opérateur fournit un service res qui a la même structure que le vecteur de sortie OUTPUT du service initial f. Tarak CHAARI - 106 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte res = union ( f, f ) où : - f(input) = OUTPUT, est le service d origine avec OUTPUT=(c 1,..., c n ) et ci = (ri 1,,ri k ) - f (INPUT ) = OUTPUT est le service qui va fournir les instances supplémentaires avec OUTPUT =(c 1,..., c n ) et ci = (r i 1,,r i l ) - res(input) = OUTPUT est le service résultant de l union avec OUTPUT=(c1,..., cn) et ci = (ri 1,,ri k,r i 1,,r i l ) Cet opérateur est généralement utile quand l union est réalisée avec le même service pour couvrir plus de cas possibles ou pour avoir des résultats plus pertinents. Par exemple, supposons que l utilisateur final de l application veuille avoir la liste des restaurants proches de lui. Le service disponible listeresto n offre que la liste des restaurants par communes. Si l utilisateur se trouve sur les frontières de deux communes voisines, l union des deux listes des restaurants de chacune de ces communes présente un résultat plus pertinent à cet utilisateur. La figure 39 présente un exemple de résultat fourni par l application de l opérateur «union» de cette nouvelle situation contextuelle. Résultat de sortie du service listeresto(69001) nomresto adresse Barocco 13 rue du Garet La Gargotte 15 rue Royale Résultat de sortie du service listeresto(69002) nomresto adresse Les belles saisons 12 cours Verdun Benoît Restaurant 15 rue Royale Résultat de sortie du service res = union(listeresto(69001),listeresto(69002)) nomresto adresse Barocco 13 rue du Garet La Gargotte 5 rue Tupin Les belles saisons 12 cours Verdun Benoît Restaurant 15 rue Royale Figure 39 - Exemple d'utilisation de l'opérateur «union» Tarak CHAARI - 107 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte 3.2.2 Actions d adaptation de gestion de versions de services (VActions) Les actions d adaptation fonctionnelle de versions de services (Version adaptation Actions) correspondent à des opérateurs qui gèrent un ensemble de versions affectées d une façon dynamique à chaque adaptateur. Ces actions assurent l ajout, la suppression et l activation d une version suivant le contexte d utilisation. Voici une liste non exhaustive de ces opérateurs : (1) activateversion Cet opérateur permet de choisir une instance (ou version) d un service. Il prend en paramètre le service initial et l identifiant de la version qui doit être activée. Il produit en sortie un service res représenté par la nouvelle version sélectionnée. res = activateversion ( f, versionid) où : - f est le service initial - versionid {a,b,c } -res = f versionid est le service résultant de l opérateur d activation de la version versionid Cet opérateur permet de modifier le comportement d un service en activant une version suivant le contexte d utilisation. (2) addversion Cet opérateur permet d ajouter une version à l adaptateur associé à un service donné. Il prend en paramètre la description la nouvelle version à ajouter et la description du service initial. Il produit en sortie un adaptateur ad qui peut activer ultérieurement la version ajoutée. res = addversion ( f, f ) où : - f est le service initial - f est la description du service à ajouter - res = ad(input, cad(c))/{fa, fb..., f } est le service résultant de l ajout de la version f à l adaptateur ad(input, cad(c))/{fa, fb...} de f. Cet opérateur est utile pour l ajout d un nouveau comportement adapté à une nouvelle situation contextuelle. Ceci permet aussi de réaliser une adaptation évolutive d un service. Tarak CHAARI - 108 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte (3) removeversion Cet opérateur permet de supprimer une version associé à l adaptateur d un service donné. Il prend en paramètre le service concerné et l identifiant de la version à supprimer. Il renvoie en sortie un adaptateur ad qui ne pourrait plus activer la version supprimée. res =removeversion ( f, versionid) où : - f est le service initial - versionid est la version à supprimer de l adaptateur du service f - res = ad(input, cad(c))/{fa, fb...} est le service résultant de la suppression de la version identifiée par versionid à l adaptateur ad(input, cad(c))/{fa, fb..., versionid } de f. Cet opérateur permet de supprimer une version jugée inutile par l administrateur de l application. Il peut aussi être utilisé conjointement avec addversion pour remplacer des versions existantes par d autres versions plus adéquates. 3.3 OPERATEURS D ADAPTATION INTER-SERVICES Un opérateur d adaptation inter-services effectue des transformations sur le modèle fonctionnel de l application. Il réalise un ensemble de modifications sur les transitions et les places du réseau de pétri décrivant le modèle fonctionnel. Ces opérateurs prennent en entrée le modèle fonctionnel à adapter et produisent un modèle fonctionnel modifié selon la nature de l opérateur et ses paramètres. Ce type d opérateurs est exécuté par le gestionnaire d adaptation de services selon les règles d adaptation fournies au système. Le tableau 4 donne un récapitulatif des opérateurs d adaptation inter-services que nous avons définis pour le test de notre stratégie d adaptation fonctionnelle. Nous détaillons le fonctionnement de ces opérateurs dans le paragraphe suivant LockService (et Opérateur ReplaceService InsertServiceAfter InsertAlternativeService UnlockService) Verrouille (et Remplace un Insère un service à la Insère un service comme déverrouille) Fonction service par un sortie d un autre frère d un autre l accès à un autre service service -servicetoinsert -servicetoinsert -servicetoinsert Paramètres - referenceservice -referenceservice -referenceservice -referenceservice Tableau 4 Exemples d opérateurs d'adaptation inter-services Tarak CHAARI - 109 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte 3.3.1 ReplaceService Cet opérateur remplace un service servicetoreplace" par un nouveau service "newservice". Il prend en entrée la description du service à remplacer servicetoreplace", la description du nouveau service "newservice" et le mode de remplacement. Ce mode peut être récursif ou simple. Dans le cas où le mode est récursif, une transition en boucle est ajoutée à la sortie du nouveau service sur lui-même. Le mode récursif est utilisé pour renvoyer un résultat sur plusieurs parties (opérateur de pagination). Après avoir vu la première page des résultats du service, l utilisateur final de l application peut soit passer à la page suivante en utilisant la nouvelle transition en boucle, soit passer au service suivant avec la transition sortante d origine (voir figure 40). res = replaceservice (servicetoreplace, newservice, mode) où : - "servicetoreplace" est le service à remplacer - "newservice" est la description du nouveau service qui va remplacer "servicetoreplace" - res = (f0, F, T) est le modèle fonctionnel modifié après le remplacement du service "servicetoreplace". f1 f1 replaceservice (servicetoreplace, newservice, simple) servicetoreplace newservice f2 f3 f2 f3 Figure 40 - Exemple d application de l opérateur replaceservice en mode simple L opérateur de remplacement de service remplace le service "servicetoreplace" par le service "newservice" dans l ensemble F des services du modèle fonctionnel. Cet opérateur modifie aussi les transitions du modèle fonctionnel suivant les règles suivantes : - Si les sorties du nouveau service "newservice" correspondent aux entrées des services sortants du service initial "servicetoreplace", toutes les transitions sortantes de "servicetoreplace" sont mises à jour en modifiant leur source par "newservice". Nous disons dans ce cas, que le nouveau service "newservice" remplace complètement l ancien service "servicetoreplace". Tarak CHAARI - 110 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte - Si les entrées du nouveau service ne correspondent pas avec l une des transitions entrantes à l ancien service "newservice", le service newservice est retiré de l ensemble F des services du modèle fonctionnel et l ancien service "servicetoreplace" est remis dans cet ensemble. Dans ce cas, nous disons que le nouveau service "newservice" ne remplace pas "servicetoreplace". Sinon, toutes les transitions entrantes de l ancien service sont mises à jour pour pointer vers le nouveau service "newservice". - Si les paramètres de sortie du nouveau service "newservice" ne correspondent pas avec l une des entrées des services sortants de "servicetoreplace", la source des associations correspondantes (entre l ancien service et les services sortants en question), est modifiée à "null". Le service associé devient ainsi temporairement inaccessible à partir du nouveau service. Nous disons dans ce cas que le service remplace partiellement l ancien service (cas de la figure 40). Nous qualifions la transition modifiée de transition instable et le service qui en dépend de service isolé. f1 f1 replaceservice (servicetoreplace, newservice, recursive) servicetoreplace newservice f2 f3 f2 f3 Figure 41 - Résultat de l application de l opérateur replaceservice en mode récursif La figure 42 présente l algorithme général de l opérateur "replaceservice" suivant les règles ci-dessus. Dans la figure 40, la source de la transition entre "servicetoreplace" et le service f2 est modifiée vers "newservice". Par contre, la source de la transition entre "servicetoreplace" et le service f3 est modifiée à "null". Une application ultérieure d un autre opérateur doit mettre à jour cette valeur pour maintenir la cohérence du modèle fonctionnel. Nous avons préféré cette solution à l élimination de la transition instable et du service isolé pour laisser une opportunité à son rattachement au réseau de pétri par d autres opérateurs. Ceci nous permet de ne pas perdre la fonctionnalité offerte par le service isolé. Tarak CHAARI - 111 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte replaceservice(servicetoreplace, newservice, mode) { If ( ti= (d, gc, A) T ai= (sourceparameter, destinationparameter) A ai.destinationservice = servicetoreplace && destinationparameter newservice.input) { // newservice est incompatible avec servicetoreplace et ne peut pas le remplacer => quitter replaceservice Break } For each (ti = (d,gc,a) T) { A := For each (ai= (sourceparameter,destinationparameter) A ai.sourceservice=servicetoreplace) { If (sourceparameter newservice.output) ai.sourceservice :=newservice else ai.sourceservice :=null } If (mode= recursive ) { a :=(pagenumber, pagenumber) a.sourceservice :=newservice a.destinationservice=newservice T:=T {(defaultdelay, defaultgeneralcondition, { a })} } } F=F \ {servicetoreplace} F=F {newservice} } Figure 42 - Algorithme de l'opérateur de remplacement de services Nous avons défini deux algorithmes qui permettent de vérifier s il y a des transitions instables connectables à un service isolé donné en entrée ou en sortie. La figure 43 donne l algorithme de connexion en entrée d un service isolé et la figure 44 donne l algorithme de connexion en sortie. Tarak CHAARI - 112 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte connectserviceinput (referenceservice) { For each (ti = (d,gc,a) T) { transitioncompatibility := true if ( ai= (sourceparameter, destinationparameter) A ai.destinationservice = null && sourceparameter referenceservice.input) TransitionCompatibility := false if (transitioncompatibility) { For each (ai = (sourceparameter, destinationparameter) A ai.destinationservice = null && sourceparameter referenceservice.input) ai.destinationservice :=referenceservice } } } Figure 43 - Algorithme de connexion en entrée d'un service isolé connectserviceoutput (referenceservice) { For each (ti = (d,gc,a) T) { transitioncompatibility := true if ( ai= (sourceparameter, destinationparameter) A ai.sourceservice = null && destinationparameter referenceservice.output) TransitionCompatibility := false if (transitioncompatibility) { For each (ai = (sourceparameter, destinationparameter) A ai.sourceservice = null && destinationparameter referenceservice.output) ai.sourceservice=referenceservice } } } Figure 44 - Algorithme de connexion en sortie d'un service isolé 3.3.2 InsertServiceAfter Cet opérateur d adaptation insère un service servicetoinsert" après un service de référence "referenceservice". Il ajoute le service servicetoinsert" à l ensemble F des services du modèle fonctionnel. res = insertserviceafter(servicetoinsert, referenceservice) où : - "servicetoinsert" est le service à insérer Tarak CHAARI - 113 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte - "referenceservice" est la description du service après lequel le nouveau service "servicetoinsert" sera inséré - res = (f0, F, T) est le modèle fonctionnel modifié après l insertion du service "servicetoinsert" à la sortie du service "referenceservice" f1 f1 referenceservice Insert Service After referenceservice f2 f3 servicetoinsert f3 f2 Figure 45 - Résultat de l application de l opérateur InsertServiceAfter Cet opérateur effectue aussi des modifications sur les transitions sortantes de "referenceservice" suivant les règles suivantes : - Si la sortie du service à insérer correspond à l entrée des services sortants (f2, f3 ) de "referenceservice", le nouveau service "servicetoinsert" est lié en sortie à tous ces services (f2,f3 ). - Si la sortie du service à insérer ne correspond pas à l entrée de l un des services de sortie du service de référence "referenceservice", la liaison du service en question est gardée avec "referenceservice". Par exemple, dans la figure 45, la transition entre le service f3 et "referenceservice" est gardée car les sorties du nouveau service ne correspondent pas aux entrées de f3. - S il existe une transition avec source à "null" et la sortie du service inséré correspond à la destination de cette transition, la source de cette transition est mise à jour avec le nouveau service (appel de la fonction "connectserviceoutput(servicetoinsert)"). La figure 46 présente l algorithme correspondant à l opérateur "insertserviceafter" suivant les règles citées ci-dessus. Tarak CHAARI - 114 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte insertserviceafter (servicetoinsert, referenceservice) { F :=F {servicetoinsert} For each (ti=(d,gc,a) T) { A := For each (ai=(sourceparameter,destinationparameter) A sourceparameter referenceservice.output) If (destinationparameter servicetoinsert.output) { A := Break } Else { a := (destinationparameter,destinationparameter) a.sourceservice :=servicetoinsert a.destinationservice := ai.destinationservice A := A {a } ai.destinationservice :=servicetoinsert } If (A!= ) { T :=T {(d,gc, A )) } } } connectserviceoutput(servicetoinsert) Figure 46 - Algorithme de l'opérateur insertserviceafter 3.3.3 InsertAlternativeService Cet opérateur insère un service servicetoinsert" comme une alternative au service "referenceservice" (c'est-à-dire dans les services immédiatement sortants du service qui précède le service de référence "referenceservice"). Par exemple, dans la figure 47, l insertion du service servicetoinsert" avec cet opérateur, permet d avoir deux alternatives après l exécution du service f1. En effet, l utilisateur final de l application peut désormais exécuter l ancien service "referenceservice" ou le nouveau service inséré servicetoinsert". res = insertalternativeservice (servicetoinsert, referenceservice) où : - "servicetoinsert" est le service à insérer - "referenceservice" est le service de référence Tarak CHAARI - 115 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte - res = (f0, F, T) est le modèle fonctionnel modifié après l insertion du service "servicetoinsert" comme alternative au service "referenceservice". Cet opérateur ajoute le nouveau service "servicetoinsert" à l ensemble F des services du modèle fonctionnel et effectue des modifications sur les transitions du modèle fonctionnel suivant les règles suivantes : - Si la sortie du nouveau service correspond à l entrée des services sortants du service de référence "referenceservice" (comme le service f2 dans la figure 45), une transition est créée entre le nouveau service et ces services. - S il existe une transition avec source à "null" et la sortie du service inséré correspond à la destination de cette transition, la source de cette transition est mise à jour avec le nouveau service (appel de la fonction "connectserviceoutput(servicetoinsert)"). f1 Insert Alternative (servicetoinsert, referenceservice) f1 referenceservice referenceservice servicetoinsert f2 f2 Figure 47 - Résultat de l'application de l'opérateur insertalternativeservice La figure 48 donne l algorithme correspondant à l opérateur "insertalternativeservice". Tarak CHAARI - 116 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte insertalternativeservice (ServiceToInsert, referenceservice) { } { F :=F {servicetoinsert} For each (ti=(d,gc,a) T) A := For each (ai= (sourceparameter,destinationparameter) A ai.destinationservice=referenceservice) } If (destinationparameter ServiceToInsert.INPUT) { A := Break } Else { a := (sourceparameter,destintionparameter) a.sourceservice := ai.sourceservice a.destinationservice := servicetoinsert A := A { a } } If (A!= ) T :=T {(d, gc, A )} For each (ti= (d, gc, A) T) { } A := For each (ai= (sourceparameter,destinationparameter) A ai.sourceservice = referenceservice) If (sourceparameter servicetoinsert.output) { } Else { } A := Break a :=(sourceparameter,destinationparameter) a.sourceservice :=servicetoinsert a.destinationservice := ai.destinationservice A := A { a } If (A!= ) T:=T {(d, gc, A )} Figure 48 - Algorithme de l'opérateur insertserviceafter 3.3.4 LockService & UnlockService LockService et UnlockService permettent respectivement de verrouiller et de déverrouiller Tarak CHAARI - 117 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte l accès à un service dans le modèle fonctionnel. L application de ces opérateurs sur un service bloque (ou débloque) le passage des transitions entrantes au service concerné. Ils modifient la condition générale des transitions entrantes à ce service. res = lockservice (referenceservice) ou bien res = UnlockService (referenceservice) où : - "referenceservice" est la description du service de référence - res = (f0, F, T) est le modèle fonctionnel modifié après le verrouillage (ou le déverrouillage) d accès au service "referenceservice". La figure 49 et la figure 50 présentent respectivement les algorithmes des opérateurs lockservice et UnlockService. lockservice(referenceservice) { For each (ti = (d,gc,a) T) { If ( ai= (sourceparameter, destinationparameter) A ai.destinationservice = referenceservice) gc :=false } } Figure 49 - Algorithme de l'opérateur LockService unlockservice(referenceservice) { For each (ti = (d,gc,a) T) { If ( ai= (sourceparameter, destinationparameter) A ai.destinationservice = referenceservice) gc :=true } } Figure 50 - Algorithme de l'opérateur UnlockService 4. Processus d adaptation fonctionnelle dans SECAS Pour adapter une application à de nouveaux contextes d utilisation, un administrateur SECAS doit fournir le modèle fonctionnel de l application et la liste des règles d adaptation qui utilisent les opérateurs définis dans les sections précédentes de ce chapitre. Dès le déploiement du modèle fonctionnel, le gestionnaire d adaptation de services commence par instancier un adaptateur pour chaque service du modèle fonctionnel (figure 51). Tarak CHAARI - 118 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte deployfunctionalmodel(fm=(f0, F, T)) { adaptedfunctionalmodel := clone(fm) For each (fi F) { Adapter a := instanciateadapter(fi) adaptedfunctionalmodel := updateadapter(adaptedfunctionalmodel, fi, a) } return adaptedfunctionalmodel } Figure 51 - Algorithme de déploiement d un modèle fonctionnel Puis, dès que la liste des règles associée à ce modèle fonctionnel est déployée ou que le contexte change (ou que la liste des règles est modifiée), le gestionnaire d adaptation de services applique les actions d adaptation spécifiées dans ces règles. Chaque règle n est exécutée que si sa partie «expressions» est satisfaite (la fonction evaluateexpressions de la figure 52 donne la valeur "true"). Pour chaque règle, l application des actions d adaptations (la fonction applyactions de la figure 52) se fait sur deux étapes. En premier lieu, le gestionnaire configure les adaptateurs par les opérateurs spécifiés dans les actions d adaptation intra-service. En second lieu, il applique les opérateurs correspondant aux actions d adaptation inter-services pour effectuer les modifications spécifiées sur la structure du modèle fonctionnel. Si le contexte change, toutes ces règles sont réévaluées pour adapter le comportement des services à ce nouveau contexte. Ceci correspond à la ré-exécution de la fonction applyrules de la figure 52. Cette fonction est aussi rappelée chaque fois que la liste des règles d adaptation est mise à jour ou modifiée. applyrules(functionalmodel FM=(f0, F, T), Rules R) { For each (r i = (expressions, actions) R) { if (r i.mode = recursive ) while ( f i F evaluateexpressions(expressions, fi)=true ) FM := applyactions(fm, fi, actions) Else For each (f i F evaluateexpressions(expressions, fi)=true ) FM := applyactions(fm, fi, actions) return FM } Figure 52 - Algorithme d'application de règles d'adaptation A la fin de l application de ces règles, un modèle fonctionnel adapté est renvoyé au gestionnaire d application SECAS (sortie de la fonction applyrules de la figure 52). Ce Tarak CHAARI - 119 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte modèle présente les services adaptés à la situation contextuelle courante. Dans ce modèle, les références vers les services initiaux sont mises à jour pour pointer sur leurs adaptateurs. 5. Synthèse sur l adaptation fonctionnelle dans SECAS Dans le paragraphe II de ce chapitre, nous avons présenté notre stratégie d adaptation fonctionnelle d une application au contexte. Cette stratégie est basée sur une liste de règles d adaptation qui associent une situation contextuelle à un ensemble d actions d adaptation de services. La situation contextuelle est décrite par un ensemble de conditions logiques sur les paramètres du contexte et les services de l application. Les actions d adaptation utilisent un ensemble d opérateurs intra et inter services. Les opérateurs inter-services effectuent des transformations sur la structure du modèle fonctionnel. Ils sont exécutés par un gestionnaire d adaptation de services. Les opérateurs d adaptation intra-services effectuent des modifications sur les sorties des services et sur les versions associées aux services d origine. Ils sont gérés par des entités d adaptation de services que nous avons appelé «adaptateurs». L application des règles d adaptation fonctionnelle produit un nouveau modèle fonctionnel d adaptateurs qui présentent un comportement fonctionnel adapté au contexte d utilisation. Dès que ce nouveau modèle est créé, le gestionnaire d adaptation de services notifie le gestionnaire d applications de SECAS pour démarrer le processus d adaptation de contenu. III. ADAPTATION DE CONTENU 1. Principe de l adaptation de contenu Les services du modèle fonctionnel de l application fournissent un ensemble de données multimédia (images, vidéos, son, texte ). Ces données peuvent ne pas être exploitables dans un contexte d utilisation particulier. Par exemple, si le terminal de l utilisateur final de l application ne supporte que des images de format PNG et que cet utilisateur invoque un service qui fournit des images sous un autre format, un transcodage est nécessaire sur les données. Le transcodage de format d images n est pas le seul opérateur d adaptation requis. En effet, plusieurs autres types d adaptation peuvent être indispensables pour fournir des données directement exploitables par le client. Tarak CHAARI - 120 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte Nous définissons l adaptation de contenu d une application par l ensemble des opérations nécessaires pour garantir une exploitation directe et optimale des données de l application dans un contexte d utilisation précis. Le but de l adaptation de données est de fournir la meilleure information possible à l utilisateur final de l application dans un contexte donné. La réussite et l efficacité de l adaptation de contenu dépendent fortement de la qualité et de la quantité de connaissances recueillies sur : (i) le contexte d utilisation de l application, (ii) les outils d adaptation de données disponibles et (iii) le contenu. Nous définissons les métadonnées de contenu comme étant l ensemble des propriétés décrivant les données échangées avec les services de l application. Les métadonnées de contenu sont utilisées pour décrire les caractéristiques du contenu telles que le format, la taille, la dimension, etc. Nous avons choisi le format de description MPEG-7 pour représenter ces métadonnées. Notre choix repose sur le fait que MPEG-7 est indépendant du média. Ce format est actuellement le standard qui fournit l ensemble le plus riche et le plus souple de descriptions de propriétés multimédia, il est considéré comme le standard le plus réputé et le plus interopérable dans le milieu industriel. Les descripteurs de données MPEG-7 sont utilisés dans le profil de contexte au niveau des formats de données acceptés par le terminal. Ils sont aussi utilisés dans la description des paramètres d entrée et de sortie des services au niveau du modèle fonctionnel. Les outils d adaptation de données que nous avons utilisés sont des services Web qui exécutent des opérateurs d adaptations de contenu (comme la compression d une image, synthèse vocale, traduction de texte ). Ces services représentent des transformations dont nous décrivons les entrées et les sorties. Chaque service d adaptation de données prend en entrée une donnée à adapter et sa description MPEG7 et fournit en sortie une donnée adaptée et sa nouvelle description MPEG7. Nous avons conçu et développé un module d adaptation de contenu fondé sur le moteur d adaptation de données des travaux de [Berhe05]. Ce moteur assure la sélection et l orchestration d un ensemble d opérateurs d adaptation de contenu afin de fournir des données adaptées au contexte d utilisation. Pour chaque service du modèle fonctionnel de l application, le module d adaptation de contenu sélectionne les opérateurs d adaptation de données nécessaires pour adapter toutes ses sorties à leur contexte d utilisation. Tarak CHAARI - 121 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte Dans le paragraphe suivant, nous détaillons le fonctionnement et les composantes principales du module d adaptation de contenu. 2. Module d adaptation de contenu Le module d adaptation de contenu réalise les transformations de données nécessaires afin d envoyer des données supportées par le terminal de l utilisateur et conformes à ses préférences et à son environnement. Il est basé sur quatre types de composants : l annuaire de services d adaptation, les adaptateurs de contenu, le mandataire local d adaptation et le composant de planification d adaptation de contenu. 2.1 ANNUAIRE DE SERVICES D ADAPTATION DE CONTENU L annuaire de services d adaptation ou ASR (Adaptation service registry) stocke des références sur les différents opérateurs d adaptations disponibles sous forme de services WEB. L ASR est similaire à un annuaire UDDI (Universal Description, Discovery and Integration) [UDDI07] qui gère les descriptions fonctionnelles et non fonctionnelles des services d adaptation multimédia. L ASR offre aussi des fonctions de recherche de services d adaptation. Les services sont décrits en suivant la représentation utilisée dans le modèle fonctionnel (paragraphe IV.3 du chapitre 3). Une fonction qui calcule le coût de chaque service d adaptation de contenu est aussi référencée dans l annuaire. Cette fonction mesure des critères de qualité des services comme le temps d exécution, la charge du service a le prix de son utilisation si elle n est pas gratuite. 2.2 ADAPTATEURS DE CONTENU Un adaptateur de contenu est un service logiciel qui réalise les transformations nécessaires pour adapter les données échangées entre un service du modèle fonctionnel et l utilisateur. Ces adaptateurs sont instanciés et déployés dynamiquement par le gestionnaire d adaptation de contenu pour chaque service de l application. Pour chaque donnée qui n est pas adaptée au contexte d utilisation, l adaptateur délègue son adaptation à un mandataire (proxy) local d adaptation de contenu et récupère une URL sur la donnée adaptée. 2.3 MANDATAIRE D ADAPTATION DE CONTENU Le mandataire d adaptation de contenu (Local adaptation proxies) assure, en premier lieu, la récupération des paramètres du contexte. Ensuite, il décide du type et du nombre de transformations de données nécessaires, découvre les services d adaptation correspondants et planifie leur exécution. L élément fondamental de ce mandataire est le composant de planification d adaptation de contenu (Content Adaptation Planification Component). Ce Tarak CHAARI - 122 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte dernier détermine un graphe des compositions possibles des différents services d adaptation de contenu qui réalisent l adaptation du contenu et effectue le choix de la séquence optimale dans ce graphe. 2.4 COMPOSANT DE PLANIFICATION D ADAPTATION DE CONTENU Ce composant détermine un plan d exécution optimal pour le traitement adaptatif du média associé. Après l identification de ce plan, ce composant informe le mandataire local d adaptation de contenu pour mettre à jour le descripteur de l adaptateur de contenu associé. Le composant de planification d adaptation de contenu que nous utilisons dans SECAS s appuie sur le générateur de graphes d adaptation multimédia (Multimedia Adaptation Graph Generator : MAGG) élaboré dans les travaux de [Berhe05] que nous détaillons dans le paragraphe suivant. Le composant de planification d adaptation de contenu utilise des critères de qualité comme le coût du service et le temps d exécution pour choisir les services d adaptation optimaux afin de réaliser les transformations nécessaires d adaptation de chaque paramètre de sortie des services de l application. Ces critères de qualité sont extraits à partir de l annuaire des services d adaptation de contenu. Le plan d adaptation calculé par ce composant n est exécuté par le mandataire local que lors de la première invocation du service. Après cette première invocation, la donnée adaptée et son plan d adaptation sont mis dans un cache local pour des invocations ultérieures du même service dans le même contexte d utilisation. 2.5 FONCTIONNEMENT DU MODULE D ADAPTATION DE CONTENU Dès que l adaptation de services se termine, le gestionnaire d application SECAS sollicite le gestionnaire d adaptation de données (Content Adaptation Manager) pour préparer le processus d adaptation de contenu (figure 53). preparecontentadaptation(functionalmodel FM=(f0, F, T)) { For each (fi F) { ContentAdapter ca := instanciatecontentadapter(fi) adaptedfunctionalmodel := updateadapter(adaptedfunctionalmodel, fi, ca) } return adaptedfunctionalmodel } Figure 53 - Algorithme général de la fonction de préparation de l'adaptation de contenu Le gestionnaire d adaptation de contenu instancie un adaptateur de contenu (Content Adapter) pour chaque service du modèle fonctionnel fourni au module d adaptation de Tarak CHAARI - 123 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte contenu (figure 54). instanciatecontentadapter(servicedescription f) { ContentAdapter ca := new ContentAdapter(f) For each(cj f) { adaptationplan := LocalProxy.calculateAdaptation(cj) ca.updatedescription(adaptationplan, cj) } return ca } Figure 54 - Algorithme général d'instanciation des adaptateurs de contenu L adaptateur délègue le calcul de l adaptation des données au mandataire d adaptation de contenu (figure 55). Ce dernier communique avec la couche de gestion de contexte de SECAS à travers l interface "ContextConsumer" afin de récupérer le profil de l utilisateur et du terminal dont il dispose et de vérifier si la donnée est adaptée à son contexte d utilisation ou non. Le mandataire utilise le composant de planification d adaptation de contenu (Content Adaptation Planification Component) pour chercher un plan d adaptation (Adaptation Plan) composé d une séquence de services d adaptation. Ces services sont identifiés dans l annuaire de services d adaptation (Adaptation Service Registry). Nous détaillons la planification de l adaptation de contenu dans le paragraphe suivant. calculateadaptation(mediaobjectdescriptor c) { adaptationplan :=ContentAdaptationPlanificationComponent.calculateAdaptation(c) intializecache(adaptationplan) return adaptationplan } Figure 55 - Algorithme général de calcul du plan d'adaptation de contenu 3. Planification de l adaptation de contenu [Berhe05] 3.1 DEFINITIONS ET NOTATIONS UTILISEES DANS LA PLANIFICATION 3.1.1 Objet média Un objet média est une donnée multimédia fournie par un service du modèle fonctionnel. Cette donnée peut être un texte, une image, un son ou une vidéo représentée par : M (m 1, m 2,, m n ) où m 1, m 2,, m n sont des propriétés du media comme le format, la taille, le nombre de couleurs, la langue Tarak CHAARI - 124 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte 3.1.2 État d un objet média L état S d un objet media M, noté S (M) est décrit par des valeurs des propriétés du média. Par exemple : pour un objet image, l état comporte les valeurs du format, de la couleur, de la hauteur, de la largeur, etc. L état S est une fonction qui renvoie les méta-données de M. Ces méta-données servent à savoir si chaque donné est adaptée à son contexte d utilisation. Par exemple, S("identitePatient_91425378.bmp") = (bmp, 24 bits, 245 pixels, 300 pixels) décrit une image en format bitmap dont chaque pixel est codé sur 24 bits et dont la taille est de 245*300 pixels. 3.1.3 Tâche d adaptation de contenu Une tâche d adaptation de contenu est une transformation t qui prend un vecteur de paramètres d entrées X = (x 1, x 2 x n ) et qui renvoie un vecteur de paramètres de sortie OUTPUT = (r 1, r 2 r m ). Par exemple, (imageout) = ImageFormatConversion(imageIn, oldformat, newformat) avec : - imagein : fichier-image en entrée, - imageout : fichier-image en sortie - oldformat : format d entrée de l image, - newformat : format de sortie de l image. Les tâches d adaptation représentent une description abstraite des transformations qu on peut effectuer sur un objet média. 3.1.4 Opérateur d adaptation de contenu Un opérateur d adaptation de contenu encapsule un service réalisant une tâche d adaptation et décrit les conditions nécessaires pour pouvoir exécuter le service correspondant. Nous utilisons ces opérateurs pour réaliser l adaptation d un objet média à son contexte d utilisation. L opérateur d adaptation de contenu est décrit par le service qu il encapsule, ses entrées, ses sorties, les pré-conditions nécessaires à son exécution et d effets représentant l état de sortie du média adapté par cet opérateur. Nous décrivons aussi les attributs de qualités (coût, temps, etc.) du service en termes de coût, temps de réponse, charge Nous dénotons un opérateur d adaptation de contenu par o = (f, INPUT, OUTPUT, Pre, Eff, Q) avec : Tarak CHAARI - 125 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte - f : un service de l annuaire des services d adaptation qui exécute une tâche d adaptation t. Une tâche d adaptation peut être réalisée par plusieurs services. - INPUT : les paramètres d entrée du service, - OUTPUT : les paramètres de sortie du service, - Pre : les pré-conditions du service, - Eff : les effets du service, - Q = {q1, q2,, qn}: représente les attributs de qualité (coût, temps, etc.) du service. Pour l exemple de la tâche d adaptation d images donnée dans le paragraphe III.3.1.3, nous pouvons avoir l instance de l opérateur de planification suivant : - Opérateur : ImageFormatConversionOperator - Entrée : image1 - Sortie : image2 - Pré-condition : hasformat (image1, jpeg) - Effet : hasformat (image2, bmp) - Qualité : (cost=30 units, responsetime=97 ms) 3.1.5 Graphe d adaptation de contenu Un graphe d adaptation de contenu est un graphe représentant toutes les séquences possibles d opérateurs d adaptation de contenu permettant d adapter un média M pour passer d un état non adapté S A à un état adapté S Z. Un graphe d adaptation de contenu G (V, E) est un graphe orienté acyclique (Directed Acyclic Graph) dans lequel : - V est l ensemble des nœuds qui représentent les opérateurs d adaptation ; - E est l ensemble des arcs qui représentent les connexions possibles entre les opérateurs d adaptation. Le nœud initial A V est un opérateur avec effet (état initial) mais sans pré-condition. Le nœud terminal Z V est un opérateur avec pré-condition (état final) mais sans effet. Une liaison ou un arc orienté e ij est associé entre un nœud source o i V et un noeud destination oj V si la condition suivante est satisfaite o j.pre o i.eff où : o j.pre dénote les pré-conditions de o j et o i.eff dénote les effets de o i. Ceci assure l enchainement des opérateurs d adaptation de contenu pour réaliser une tâche d adaptation. Par exemple, nous disposons de deux opérateurs : le premier assure la traduction d un texte français en anglais ; le deuxième assure la synthèse vocale d un texte anglais. Pour réaliser la synthèse vocale d un texte fourni en français, le graphe d adaptation va enchainer successivement la traduction du texte Tarak CHAARI - 126 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte d origine et puis la synthèse vocale du texte traduit. Dans cet exemple, l enchaînement est possible puisque l effet du premier service o i.eff (langue du texte en anglais) est compatible avec les préconditions du deuxième opérateur o j.pre. 3.1.6 Problème de la planification de l adaptation. Un problème de planification d adaptation est un 4-uplet (S A, S Z, T, D) où S A est l état initial de l objet média, S Z est l état final de l objet média, T est une liste de tâches d adaptation et D est la liste des opérateurs d adaptation. La résolution du problème de planification d adaptation produit un graphe d adaptation de contenu G = (V, E). 3.2 ALGORITHME DE GENERATION DU GRAPHE D ADAPTATION DE CONTENU Pour construire le graphe d adaptation, nous avons utilisé l algorithme élaboré par [Berhe05] (Multimedia Adaptation Graph Generator : MAGG). Cet algorithme cherche tous les chemins possibles d adaptation qui permettent d aboutir à un résultat adapté au contexte d utilisation du média considéré. Le code de cet algorithme est détaillé dans l annexe D de ce mémoire. Le graphe produit par cet algorithme présente plusieurs chemins possibles pour réaliser l adaptation du média considéré. Nous utilisons le modèle de qualité de services élaboré par Girma Berhe pour choisir le chemin optimal d adaptation de contenu. Nous détaillons ce modèle et son utilisation dans le paragraphe 3.3 de cette section. 3.3 RECHERCHE D UN PLAN D ADAPTATION OPTIMAL 3.3.1 Définition d un plan d adaptation Un plan d adaptation est un chemin dans le graphe d adaptation G qui relie le nœud initial au nœud terminal. Il est représenté par une liste de la forme p = (A o 1 o 2 o n Z) où : A et Z sont le nœud initial et le nœud terminal du graphe d adaptation G o i est une instance d opérateur d adaptation. Si p = (A o 1 o 2 o n Z) est un plan et que S est un état du média à adapter dans G, alors S(p) est l état de l objet média produit après l exécution de la suite ordonnée o 1, o 2,, o n sur l objet média en entrée. Q(p) est la valeur globale de qualité du chemin p calculée selon l équation (6). 3.3.2 Modèle de qualité de service (QoS) Puisqu un opérateur d adaptation peut être réalisé par plusieurs services, le choix du service optimal est important pour le résultat d adaptation. Une fois le graphe d adaptation généré avec toutes les séquences d adaptation possibles, le choix de la meilleure séquence est Tarak CHAARI - 127 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte fait en se basant sur des critères de qualité de services extraits du contexte d utilisation de l application. Le modèle de qualité de service utilisé dans les travaux de (Berhe & al) se base sur deux caractéristiques : le temps de réponse du service et son coût (charge). Soit p = (A s 1 s 2 s N Z) un chemin dans le graphe d adaptation où N est le nombre de services. On définit la qualité de service du chemin, dénotée par Q(p), comme suit : Q( p) = ( Q ( p), Q ( p)) (1) où : COST TIME - Q COST ( p) : le coût total du chemin - Q TIME ( p) : le temps total d exécution du chemin. - Q COST ( p) est défini par Q ( p) = Q ( s ) (2) COST N i= 1 COST - Q COST s )représente le coût d exécution du service d adaptation et celui de la ( i transmission des données. - Q TIME ( p) est défini par Q ( p) = Q ( s ) (3) TIME N i= 1 TIME - Q TIME s ) : le temps d exécution du service d adaptation et le temps de transmission des données. ( i i i Pour agréger les valeurs qualitatives, on définit les qualités échelonnées Qs COST ( s i ) et Qs TIME ( s i ) comme suit : max QCOST QCOST ( si ) max min if Q 0 ( ) max min COST QCOST Qs COST si = QCOST Q (4) COST max min QCOST QCOST = 0 1 if max QTIME QTIMe ( si ) max min if Q 0 ( ) max min TIME QTIME Qs TIME si = QTIMe Q (5) TIME max min QTIME QTIME = 0 1 if Q COST Q COST Q TIME Q TIME max min max min où,, et sont respectivement : le coût maximum, le coût minimum, le temps d exécution maximum et le temps d exécution minimum des services disponibles. Les utilisateurs peuvent indiquer leurs préférences sur la qualité de service en modifiant les impacts des différents critères telle que le service le plus rapide ou le moins coûteux en spécifiant des valeurs de pondération pour chaque critère. Le score d un chemin avec des valeurs pondérées est établi comme suit : Tarak CHAARI - 128 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte N ( QsCOST ( si ) wcost + QsTIME ( si ) wtime ) Score( p) = (6) i= 1 où w [0, 1] et wtime COST [0, 1] représentent les valeurs de poids affectées respectivement au coût et au temps avec w w = 1 (7) COST + TIME Soit P set = {p 1, p 2,, p K } l ensemble de tous les chemins possibles dans un graphe d adaptation. Le chemin optimal est le chemin dont la valeur du score est maximale, score max, où score max est défini comme suit : Score max iε { { Score( p )} = max (8) 1, K } i 4. Synthèse sur l adaptation de contenu dans SECAS Dans cette section, nous avons présenté la stratégie d adaptation de contenu que nous avons élaborée pour SECAS. Cette stratégie garantit l adaptation des données d entrée et de sortie des services résultant du module d adaptation de services. Pour chaque donnée échangée avec le client, si elle n est pas adaptée à son contexte d utilisation, le module d adaptation de contenu instancie un adaptateur de contenu qui s occupe de l adaptation de cette donnée à la situation contextuelle en question. L adaptateur utilise un algorithme élaboré par [Berhe05] pour chercher et composer un ensemble de transformations possibles afin d adapter les données à leur contexte d utilisation. Les adaptateurs exécutent le résultat de la composition lors de la première invocation des services. Ensuite, ce résultat est mis en cache local pour accélérer sa réutilisation dans la même situation contextuelle. Le processus d adaptation de contenu fournit ainsi un nouveau modèle fonctionnel avec des services fournissant des données adaptées à leur contexte d utilisation. IV. ADAPTATION DE PRESENTATION 1. Principe de l adaptation de présentation Les interfaces d interaction assurent les échanges de données entre l utilisateur final de l application et les différents services de l application. Ces interfaces doivent fonctionner correctement dans leur contexte d utilisation. La bonne exécution de ces interfaces est conditionnée par leur capacité à s adapter au terminal utilisé et aux préférences de l utilisateur. Tarak CHAARI - 129 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte Nous définissons l adaptation de présentation d une application dans SECAS par l ensemble des opérations nécessaires pour créer automatiquement une interface utilisateur fonctionnelle assurant l interaction avec les services et les données adaptées de l application. L adaptation de présentation dépend principalement des caractéristiques du terminal utilisé (facette terminal du contexte) et des préférences de l utilisateur (facette utilisateur du contexte). Elle dépend aussi de la description des données adaptées de l application. Dans SECAS, l adaptation de présentation consiste à générer automatiquement le code complet des interfaces graphiques qui permettent à l utilisateur d interagir avec les différents services du modèle fonctionnel. Pour chaque service de l application, le module d adaptation de présentation de SECAS génère l interface graphique qui assure l interaction entre l utilisateur et le service de l application. Cette interface fournit des facilités de navigation pour que l utilisateur puisse interagir avec tous les services du modèle fonctionnel de l application. Le processus d adaptation de présentation suit immédiatement le résultat de la planification de l adaptation de contenu afin de préparer l interface homme-machine adéquate qui va présenter les données adaptées à l utilisateur. Pour réaliser la génération de cette interface, nous avons réalisé une étude approfondie sur les API d interaction existantes dans le cadre du projet SEFAGI [Chaari04]. Dans cette étude, nous avons remarqué que la difficulté de génération réside dans la diversité des machines virtuelles implantées sur les différents terminaux mobiles du marché. Pour surmonter cette difficulté, nous avons défini une API abstraite d interaction qui doit être implémentée pour chaque machine virtuelle cible. Cette API présente une modélisation orientée-objet des différentes entités qui assurent l interaction avec les services et les données adaptés de l application. 2. Modélisation d une interface utilisateur dans SECAS Pour pouvoir générer l interface utilisateur qui assure l interaction avec les services de l application et qui s adapte à son contexte d utilisation, nous avons élaboré un modèle générique abstrait décrivant les différents éléments qui constituent l interface. Ce modèle est réifié dans le contexte d utilisation de l application afin de fournir le code nécessaire à l interaction avec ses différents services. Pour chaque service du modèle fonctionnel de l application, nous associons une fenêtre graphique qui assure l interaction avec ce service. Cette fenêtre est une entité qui regroupe Tarak CHAARI - 130 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte deux panneaux graphiques : un panneau d entrée et un panneau de sortie. Un panneau regroupe un ensemble de composants d interaction élémentaires qui encapsulent des paramètres d entrée ou de sortie du service. Un composant réalise l affichage (ou la saisie) d une valeur correspondant à un paramètre de sortie (ou d entrée) du service. Pour pouvoir exécuter un service, nous avons défini des composants graphiques réactifs que nous avons appelés commandes. Ces composants sont généralement des menus ou des boutons. La figure 56 montre les éléments graphiques de l interface d interaction avec les services et les données adaptés de l application. Ces éléments abstraits, que nous détaillons dans la suite de cette section, constituent un environnement d exécution abstrait (Abstract Interface Runtime Environment) de l interface d interaction avec les services de l application. L implémentation de ces éléments est nécessaire pour pouvoir générer le code concret de l interface utilisateur de l application. 2.1 COMPOSANT Un composant (Component) représente le composant abstrait qui encapsule une donnée d entrée ou de sortie des services de SECAS. Pour chaque type de donnée dans les paramètres d entrée et de sortie des services, nous associons un composant graphique abstrait qui doit être implémenté dans le langage de l API d interaction cible. Par exemple, nous avons le composant ShortTextComponent pour les textes courts, BooleanComponent pour les valeurs booléenne, ImageComponent pour les images, AudioComponent pour la lecture de son Ces composants sont implémentés et fournis par l administrateur de SECAS. Nous nous basons sur une table de correspondance des types de données définis dans les paramètres d entrée et de sortie des services et les composants abstraits qui permettent de les présenter ou de les saisir. Cette table permet d ajouter dans la plateforme de nouveaux types de données et leurs composants d interaction. 2.2 PANNEAU Un panneau (Panel) représente le regroupement physique d un ensemble de composants. Dans SECAS, nous utilisons deux panneaux pour chaque service : un panneau d entrée (InputPanel) pour la saisie des valeurs d entrée et un panneau de sortie (OutputPanel) pour l affichage des valeurs de sortie. Le panneau fournit également des moyens de sélection pour que l utilisateur puisse sélectionner une instance particulière des valeurs renvoyées par le service. L instance sélectionnée peut constituer une entrée d un autre service du modèle fonctionnel. Nous utilisons une structure d échange (Exchange Structure) basée sur un ensemble de paires (Paramètre, Valeur) afin de réaliser cet échange de données entre les Tarak CHAARI - 131 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte services (cf section IV.2.6). 2.3 COMMANDE Une commande (Command) est un composant graphique réactif qui permet de déclencher un événement et d exécuter le code qui lui est associé. Nous utilisons les commandes pour exécuter un service, passer d un service à un autre, revenir au panneau précédent Chaque Panneau contient deux commandes (Back et Next) pour naviguer entre les différents services de l application. Chacune de ces commandes est associée à un gestionnaire d événements qui assure l exécution du code correspondant. 2.4 FENETRE Une fenêtre (Window) est associée à chaque service de l application. Elle offre toutes les fonctions nécessaires pour la saisie des valeurs d entrée du service, son invocation et l affichage des résultats renvoyées par ce service. Elle constitue un regroupement logique de deux panneaux : un panneau d entrée et un panneau de sortie. Le panneau d entrée permet de saisir les paramètres d entrée du service et le panneau de sortie assure l affichage des résultats d exécution du service. L exécution du service est déclenchée lors de l utilisation de la commande Next du panneau d entrée (InputPanel). 2.5 FENETRE DE NAVIGATION La fenêtre de navigation (NavigationWindow) est une fenêtre (window) particulière qui interagit avec un service particulier (getavailableservices) du module d adaptation de présentation. Ce service renvoie la liste des services disponibles que l utilisateur pourrait exécuter à un instant donné de l exécution de l application. La fenêtre de navigation n est composée que d un seul panneau (OutputPanel) qui affiche les résultats d exécution du service getavailableservices. 2.6 FENETRE PRINCIPALE La fenêtre principale (MainWindow) est un élément graphique qui assure le lancement de l interface d interaction avec l application. Elle permet de lancer (ou de quitter) l application et de naviguer entre les fenêtres d exécution des services et la fenêtre de navigation. Cette fenêtre principale maintient une structure de données qui assure l échange de paramètres entre les services de l application. Chaque valeur renvoyée par un service et sélectionnée par l utilisateur est enregistrée dans cette structure d échange. Cette structure est une table de hachage qui stocke la valeur actuelle de chaque paramètre. Tarak CHAARI - 132 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte Window InputPanel MainWindow Component Command OutputPanel Figure 56 - Structure générale de l'interface d'interaction avec un service 3. Processus de génération automatique d interfaces adaptées Le processus de génération automatique d interfaces adaptées consiste à générer une interface qui assure l interaction avec les différents services de l application pour chaque plateforme cible. La génération du code de cette interface se base sur (i) l implémentation de l environnement abstrait d exécution de l interface (Abstract Interface Runtime Environment) et (ii) le modèle fonctionnel de l application. En effet, pour chaque service du modèle fonctionnel, le module d adaptation de présentation génère une fenêtre concrète qui assure l interaction avec ce service (algorithme présenté dans la figure 57). Nous utilisons la notation L pour la librairie des éléments qui implémentent l environnement abstrait d exécution de l interface. generateui(functionalmodel FM=(f0, F, T), RunTimeEnvironmentLibrary L) { For each (fi F) { W :=generatewindow(fi, L) storeincache(w) ; } } Figure 57 - Fonction de génération de l'interface d'interaction avec les services de l'application Pour organiser le code des fenêtres générées, nous avons utilisé le modèle MVC [Krasner88]. Ce modèle nous facilite la génération du code en séparant l affichage, les données et les traitements. Ainsi, suivant ce modèle MVC, le code d une fenêtre (Window) W est composé d une vue V (présentation graphique), un modèle M (traitements et stockage de données) et un contrôleur C (gestionnaire d évènements). W = {M, V, C} Le contrôleur réalise la liaison entre le modèle et la vue lors du déclenchement d un évènement suite à une action de l utilisateur final de l application sur l interface. Tarak CHAARI - 133 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte generatewindow(servicedescription f, RunTimeEnvironmentLibrary L) { M:= generatemodel(f, L) V:= generatevue(f, L) C := generatecontroller(f, L) W:= {M, V, C} return W } Figure 58 - Algorithme de la fonction de génération d'une fenêtre d'interaction avec un service La vue d une fenêtre est composée de deux panneaux : un panneau d entrée Pi (Input Panel) et un panneau de sortie Po (Output Panel). V= (Pi, Po) generatevue(servicedescription f, RunTimeEnvironmentLibrary L) { Pi:= generateinputpanel(f.input, L) Po:= generateoutputpanel(f.output, L) V:= {Pi, Po} return V } Figure 59 - Algorithme de la fonction de génération de la vue d'une fenêtre Le panneau d entrée Pi est composé d un affichage Ai et de deux commandes d interaction InputBack et InputNext. L affichage Ai est un vecteur de composants associés chacun à un paramètre d entrée du service actuel. Pi = {Ai, InputBack, InputNext} avec - Ai = (c 1, c 2 c n ) où n est le nombre de paramètres d entrée du service associé - InputBack est la commande qui permet de revenir à la fenêtre de navigation qui affiche la liste des services disponibles de l application. - InputNext est la commande qui permet d exécuter le service avec les valeurs d entrée saisies dans les composants (c 1, c 2 c n ) du panneau. Cette commande instancie ensuite le panneau de sortie Po pour afficher le résultat d exécution du service. La figure 60 présente l algorithme de la fonction de génération du panneau d entrée d un service. Tarak CHAARI - 134 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte generateinputpanel(parameters Params=(x1,x2 xn), RunTimeEnvironmentLibrary L) { A := For each (xi Params) { c := generatecomponent(xi, L) // instancie un composant c de la librairie L à partir du type du paramètre xi A :=A { c } } Pi:={A, L.InputBack, L.OutputBack} return Pi } Figure 60 - Algorithme de la fonction de génération du panneau d entrée d un service Le panneau de sortie Po est composé d un affichage Ao et de deux commandes d interaction OutputBack et OutputNext. L affichage Ao est un vecteur de composants associés chacun à un paramètre de sortie du service actuel. Po = {Ao, OutputBack, OutputNext} avec - Ao = (c 1, c 2 c m ) où m est le nombre de paramètres de sortie du service associé - OutputBack est la commande qui permet de revenir au panneau d entrée de la fenêtre pour pouvoir fournir de nouvelles valeurs d entrée afin de ré-exécuter le service. - OutputNext est la commande qui permet de valider la sélection de l utilisateur dans les valeurs de sortie affichées sur le panneau. Cette commande instancie ensuite la fenêtre de navigation qui présente la liste des services disponibles suite à l exécution du service actuel. La figure 61 présente l algorithme de la fonction de génération du panneau de sortie d un service. generateoutputpanel(parameters Params=(x1,x2 xn), RunTimeEnvironmentLibrary L) { A := For each (xi Params) { c := generatecomponent(xi, L) // instancie un composant c de la librairie L à partir du type du paramètre xi A :=A { c } } Po:={A, L.OutputBack, L.OutputNext} return Po } Figure 61 - Algorithme de la fonction de génération du panneau de sortie d un service Le modèle M de chaque fenêtre assure l exécution du service qui lui est associé. Nous utilisons la même entité ServiceInvoker pour exécuter tous les services du modèle fonctionnel. Tarak CHAARI - 135 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte Cette entité prend en entrée la description du service et ses paramètres d entrée, elle invoque le service et renvoie ses valeurs de sortie. Pour chaque plateforme cible la librairie L contient l implémentation de ServiceInvoker. La figure 62 donne l algorithme de la fonction de génération du modèle de la fenêtre d interaction avec un service f. M = {ServiceInvoker} generatemodel(servicedescriptor f, RunTimeEnvironmentLibrary L) { M:=generateServiceInvocation(f, L.ServiceInvoker) /* la fonction generateserviceinvocation génère le code nécessaire à l invocation du service f en utilisant l invocateur de services de la plateforme cible L */ Return M } Figure 62 - Algorithme de la fonction de génération du modèle d'exécution d'un service Afin d assurer la navigation entre les différents services de l application, le module d adaptation de présentation offre deux services getpreviousservices et getnextservices qui renvoient respectivement la liste des services immédiatement entrants au service actuel et la liste des services immédiatement sortants du service actuel dans le modèle fonctionnel. La figure 63 donne l algorithme de ces fonctions. getpreviousservices(functionalmodel FM=(f0, F, T), ServiceDescriptor f) { S:= For each (fi F) if ( (ti = (d,gc,a) T) ai= (sourceparameter, destinationparameter) A && ai.destinationservice = f && ai.sourceservice=fi) S:=S { fi} return S } getnextservices(functionalmodel FM=(f0, F, T), ServiceDescriptor f) { S:= For each (fi F) // chercher un service fi condidat pour être un service disponible après l exécution de f if ( (ti = (d,gc,a) T) ai= (sourceparameter, destinationparameter) A && ai.sourceservice = f && ai.destinationservice=fi) // Si tous les services à la transition ti sont déjà exécutés par l utilisateur if (For all (ai= (sourceparameter, destinationparameter) A ), executed(ai.sourceservice) ) S:=S { fi} } return S Figure 63 - Algorithmes des fonctions de navigation dans le modèle fonctionnel à partir d'un service f Le contrôleur C de la fenêtre contient toutes les actions nécessaires qui doivent être Tarak CHAARI - 136 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte exécutée lorsqu une commande est utilisée dans la vue de l interface. Ainsi, le contrôleur regroupe les gestionnaires d événements des quatre commandes définies dans la description abstraite de l interface d interaction avec l application (InputBack, InputNext, OutputBack et OutputNext). La figure 64 illustre l algorithme de la fonction de génération du contrôleur. C= {InputBackAction, InputNextAction, OutputBackAction, OutputNextAction} generatecontroller(servicedescriptor f, RunTimeEnvironmentLibrary L) { InputBackAction:= generateinputbackaction(f, L) /* le lancement de la commande InputBack instancie une fenêtre de navigation qui affiche la liste des services précédents de f en appelant le service de navigation getpreviousservices(f) */ InputNextAction:= generateinputnextaction(f, L) /* le lancement de la commande InputNext entraîne l exécution du service f et l instanciation du panneau de sortie Po avec les valeurs de sortie de f */ OutputBackAction:= generateoutputbackaction(f, L) /* le lancement de la commande OutputBack entraîne l instanciation du panneau d entrer Pi pour réexécuter le service service f */ OutputNextAction:= generateoutputnextaction(f, L) /* le lancement de la commande OutputNext instancie une fenêtre de navigation qui affiche la liste des services sortants de f en appelant le service de navigation getnextservices(f) */ C= {InputBackAction, InputNextAction, OutputBackAction, OutputNextAction} return C } Figure 64 - Algorithme de la fonction de génération du modèle d'exécution d'un service Ainsi tout le code de l interface d interaction avec les services de l application est généré et mis en cache puis renvoyé à l utilisateur. A chaque changement du contexte qui induit des modifications sur l interface, l utilisateur est averti pour mettre à jour son code sur son terminal. 4. Synthèse sur l adaptation de présentation dans SECAS Dans le paragraphe III de ce chapitre, nous avons présenté le module d adaptation de présentation de SECAS. Ce module garantit la génération automatique et complète d interfaces utilisateur adaptées au contexte d utilisation des applications. Ce module s appuie sur le modèle fonctionnel des applications pour générer le code de l interface utilisateur permettant d interagir avec les services de ces applications. Les interfaces générées fournissent des facilités de navigation pour pouvoir parcourir les services décrits dans le modèle fonctionnel de l application. Nous avons élaboré un environnement d exécution abstrait qui décrit les composants d interaction nécessaires pour réaliser ces interfaces. Le générateur d interfaces utilise une librairie qui implémente ces composants dans le contexte Tarak CHAARI - 137 - Thèse de doctorat

Chapitre IV Contributions : Stratégie d adaptation au contexte actuel d utilisation de l application. Cette librairie est référencée dans la description du contexte. V. CONCLUSION Dans ce chapitre, nous avons présenté notre stratégie d adaptation d applications à de nouveaux contextes d utilisation. Notre plateforme SECAS prend en entrée le modèle fonctionnel de l application. Ce modèle contient la description de tous les services de l application ainsi que leurs dépendances d exécution. Une fois ce modèle déployé, le module d adaptation de comportement de services de SECAS applique une liste de règles d adaptation fonctionnelle. Elles sont stockées dans une base de règles d adaptation qui peut être enrichie par l administrateur de la plateforme. Le module d adaptation de comportement génère un modèle fonctionnel avec un comportement adapté au contexte d utilisation. Ce modèle est repris par le module d adaptation de contenu pour assurer l adaptation de toutes les entrées et les sorties des services du modèle fonctionnel. Ce dernier est mis à jour avec les formats et les types de données adaptés ; ensuite il est passé au module d adaptation de présentation. Ce dernier génère des interfaces utilisateurs adaptées à l environnement de leur utilisation. Lorsque le contexte d utilisation change, les règles du module d adaptation fonctionnelle sont réévaluées. S il y a des modifications sur le modèle fonctionnel de l application, tous les processus d adaptation fonctionnelle, de contenu et de présentation sont réinitialisés. Afin de valider notre approche d adaptation, nous avons développé un prototype de la couche d adaptation et de la couche de déploiement d applications de SECAS. Nous présentons la conception et l utilisation de ce prototype dans le chapitre suivant. Tarak CHAARI - 138 - Thèse de doctorat

CHAPIITRE R V - CONTRIIBUTIIONS : IIMPLANTATIION ET UTIILISATIION I DE NOTRE PLATEFORME D ADAPTATIION T " L'espoir n'est pas une formule mais une pratique" (Nicole Notat)

Chapitre V Contributions : Implantation et utilisation de SECAS TABLE DES MATIERES I. INTRODUCTION 141 II. CONCEPTION DE L ARCHITECTURE SECAS 141 1. Modélisation fonctionnelle 141 2. Modélisation dynamique 145 3. Modélisation statique 149 4. Déploiement de la plateforme 156 5. Scénario générique d utilisation de SECAS 157 III. DEVELOPPEMENT DE LA PLATEFORME SECAS 159 1. Implantation de la couche d adaptation fonctionnelle 159 2. Implantation de la couche d adaptation de contenu 160 3. Implantation de la couche d adaptation de présentation 161 4. Statistiques 161 IV. UTILISATION DE SECAS DANS LE PROJET SICOM 161 1. Déploiement de SICOM avec l interface d administration de SECAS 162 2. Adaptation de l application «SICOM» 163 V. UTILISATION D UN NOUVEAU MODELE DE CONTEXTE DANS SECAS 168 VI. CONCLUSION 170 Tarak CHAARI - 140 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS I. INTRODUCTION Pour valider notre approche d adaptation, nous avons développé un prototype de la plateforme SECAS. Nous nous sommes spécialement intéressés à la couche de déploiement d applications et à la couche d adaptation de l architecture de SECAS. Nous avons intégré une application médicale dans notre plateforme pour l adapter à de nouveaux contextes d utilisation. Cette intégration nous a permis de valider notre architecture et notre approche d adaptation. Dans ce chapitre, nous présentons la conception et la réalisation de notre prototype et nous montrons comment nous l avons utilisé pour adapter l application médicale à de nouveaux contextes d utilisation. Avant de conclure nous validons l objectif de la généricité de notre approche d adaptation en intégrant un nouveau modèle de contexte dans notre plateforme. II. CONCEPTION DE L ARCHITECTURE SECAS 1. Modélisation fonctionnelle Dans cette section, nous identifions les acteurs qui interagissent avec SECAS et nous spécifions ses cas d'utilisation. 1.1 IDENTIFICATION DES ACTEURS DU SYSTEME Nous avons identifié 3 acteurs principaux qui peuvent intervenir dans SECAS. Administrateur SECAS (SECAS Administrator): il gère les comptes utilisateurs et les modules de SECAS Concepteur d applications (Designer): il déploie des applications dans SECAS pour les adapter à de nouveaux contextes d utilisation Utilisateur (User): il utilise une application adaptée 1.2 IDENTIFICATION DES CAS D UTILISATION DU SYSTEME 1.2.1 Déployer une application dans SECAS Le déploiement d une application dans SECAS permet au concepteur (designer) d applications d ajouter des nouvelles applications afin de les adapter à de nouveaux contextes d utilisation. À travers l interface graphique de SECAS (Figure 92), le concepteur lance le processus d'ajout d'une nouvelle application en déployant son modèle fonctionnel (deployfunctionalmodel) et en fournissant la liste des règles d adaptation fonctionnelle qui vont être appliquée à cette application (deployrules). Tarak CHAARI - 141 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS Le concepteur d applications peut modifier la liste des règles d adaptation des applications qu il a déployées (upadterules). Il peut aussi mettre à jour ses applications (updateapplication) en leur ajoutant ou supprimant des services ou en fournissant directement un nouveau modèle fonctionnel (updatefunctionalmodel). La figure 65 présente les cas d utilisation du concepteur d applications SECAS. Figure 65 - Diagramme de cas d utilisation : déploiement d une application 1.2.2 Utiliser une application adaptée Après avoir passé la phase d authentification dans notre plateforme, l utilisateur peut obtenir la liste des applications qui lui sont accessibles (cas d utilisation listapplications). Il peut aussi sélectionner une application (selectaplication) parmi cette liste. L utilisateur peut ensuite invoquer les services (invokeservices) de cette application en respectant leurs dépendances d exécution dans le modèle fonctionnel. La figure 66 illustre le diagramme UML du cas d utilisation des applications déployées dans notre plateforme. Tarak CHAARI - 142 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS Figure 66 - Diagramme de cas d utilisation : utilisation d une application adaptée 1.2.3 Gérer les comptes des utilisateurs Après la phase d authentification (cas d utilisation connect), l administrateur de la plateforme SECAS peut ajouter ou supprimer des utilisateurs. Il peut aussi modifier les droits d accès des utilisateurs aux applications déployées ou à un ensemble de ses services (cas d utilisation UserManagement). La figure 67 présente le diagramme des cas d utilisation de la gestion des comptes des utilisateurs de SECAS. SecasApplicationManager <<include>> connect authentication Administrator UserManagement adduser removeuser modifyuser Figure 67 - Diagramme de cas d utilisation : gestion des comptes des utilisateurs de SECAS 1.2.4 Gérer les modules de SECAS Pour assurer l évolutivité de notre plate-forme, l administrateur peut ajouter de nouveaux opérateurs d adaptation (cas d utilisation addadaptoperator dans la figure 68). Ceci peut nécessiter l ajout de nouveaux paramètres nécessaires pour ces opérateurs (addadaptparameter dans la figure 68). Il peut aussi enrichir les expressions logiques utilisées pour l élaboration des règles d adaptation en ajoutant de nouveaux opérateurs Tarak CHAARI - 143 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS logiques sur les paramètres des services (addbooleanoperator dans la figure 68). Figure 68 - Diagramme de cas d utilisation : gestion des modules de SECAS L ajout d un nouvel opérateur ou d un paramètre d adaptation nécessite le déploiement d un descripteur XML pour identifier la classe qui implémente l élément ajouté et l ensemble de ses propriétés. La figure 69 présente le descripteur d un paramètre d adaptation modélisant un paramètre de sortie d un service. La figure 70 détaille le descripteur de l opérateur d adaptation projection qui utilise le paramètre serviceoutput de la figure 69. <parameter name="serviceoutput"> <description>an output parameter of a service</description> <class>secas.application.service.parameter</class> </parameter> Figure 69 - Descripteur d'un paramètre d'adaptation de type "serviceoutput" <AdaptationOperator name="projection"> <description>this operator is applied to service output vector to project the result on a subset of its components</description> <class>secas.adaptation.services.sactions.projectoutput</class> <parameters> <parameter occurrence= many name="outputparameter" type="serviceoutput"/> </parameters> </AdaptationOperaor> Figure 70 - Descripteur de l opérateur d'adaptation fonctionnelle "projection" Dans la suite de cette section, nous nous intéressons essentiellement aux deux cas d utilisation correspondant au déploiement des applications dans SECAS et à leur adaptation. Nous présentons le fonctionnement dynamique des entités principales de ces deux couches dans le paragraphe 2 et nous détaillons leur conception statique dans le paragraphe 3. Tarak CHAARI - 144 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS 2. Modélisation dynamique Dans cette section, nous détaillons le fonctionnement du gestionnaire de déploiement d applications, du gestionnaire d adaptation de services, du gestionnaire d adaptation de contenu et du gestionnaire d adaptation de présentation de notre plateforme. 2.1 GESTIONNAIRE DE DEPLOIEMENT D APPLICATIONS Le gestionnaire de déploiement d applications assure l intégration de nouvelles applications à adapter dans notre plateforme. Quand un concepteur se connecte (action connect dans la figure 71) et demande l ajout d une nouvelle application dans SECAS, le gestionnaire demande son modèle fonctionnel et la liste des règles d adaptation correspondantes (état requesting de la figure 71). S il y a des erreurs dans les fichiers fournis, le gestionnaire renvoie un message d erreur (état Cancel de la figure 71). Dans le cas où le déploiement se déroule bien, le gestionnaire d applications entre dans un état configuring et passe la main au gestionnaire d adaptation de services (service adaptation manager) afin de lancer le processus d adaptation fonctionnelle de l application déployée. Figure 71 - Diagramme d état transition : gestionnaire de déploiement d applications 2.2 GESTIONNAIRE D ADAPTATION DE SERVICES Le gestionnaire d adaptation de services assure l adaptation fonctionnelle de l application au contexte d utilisation. Lorsqu un concepteur déploie une application (événement Functional Model deployed dans la figure 72), le gestionnaire d adaptation de services commence par instancier un adaptateur de services pour chaque service de l application (activité Deploy adapter for each service dans la figure 72). Ensuite, il met à jour le modèle fonctionnel de l application (update service references) pour que l utilisateur final puisse interagir avec les adaptateurs à la place des services originaux. Le gestionnaire d adaptation Tarak CHAARI - 145 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS de services évalue les règles d adaptation (evaluate rules) et affecte à chaque adaptateur une liste d actions d adaptation selon les règles fournies lors du déploiement de l application (configure adapters). Ces actions modifient la structure du modèle fonctionnel de l application (Update Functional Model). Après cette modification, le gestionnaire d adaptation de services notifie le gestionnaire d adaptation de contenu (Notify Service Adaptation End). Enfin, ce gestionnaire entre dans un état (waiting for context change) pour attendre les éventuels changements de contexte et réévaluer les règles d adaptation. Figure 72 - Diagramme d activités du gestionnaire d adaptation de services 2.3 GESTIONNAIRE D ADAPTATION DE CONTENU Le gestionnaire d adaptation de contenu assure l adaptation des données renvoyées par les services de l application. Dès que le module d adaptation de services envoie une notification signalant la fin du processus de préparation de l adaptation fonctionnelle (évènement service adaptation end dans la figure 73), le gestionnaire d adaptation de contenu instancie et déploie un adaptateur de contenu pour chaque service de l application (activité deploy content adapter for each service dans la figure 73). Le modèle fonctionnel est ainsi mis à jour pour que l utilisateur puisse interagir avec les adaptateurs de contenu à la place des adaptateurs de services (update service references). Ensuite, ce gestionnaire calcule le plan d adaptation de contenu (calculate adaptation plan) et met à jour les descripteurs des entrées et des sorties des services du modèle fonctionnel (update service parameters). Les adaptateurs de contenu s appuient sur les adaptateurs de services afin de récupérer les données à adapter. Enfin, le gestionnaire d adaptation de contenu envoie une notification de fin de préparation de l adaptation de contenu et revient en attente d autres notifications du gestionnaire d adaptation de services (état waiting for service adaptation manager notification). Tarak CHAARI - 146 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS Figure 73 - Diagramme d activités du gestionnaire d adaptation de contenu 2.4 ADAPTATEUR DE SERVICES L adaptateur de services invoque le service original, adapte son comportement et passe sa sortie à l adaptateur de contenu qui lui a été associé. Avant l invocation du service, l adaptateur de services active une version du service si l opérateur d activation de versions est utilisé dans les règles d adaptation (activité "select version" de la figure 74). Après l invocation du service d origine (activité "invoke service"), cet adaptateur applique les actions d adaptation qui lui ont été affectées (activité "apply adaptation action") et renvoie le résultat adapté (activité "return adapted result"). Un message d erreur est retourné si le temps d attente de l invocation du service d origine est supérieur à celui qui a été spécifié dans le modèle fonctionnel (événement "after delay"). Figure 74 - Diagramme d activités de l adaptateur de services 2.5 ADAPTATEUR DE CONTENU Un adaptateur de contenu assure l adaptation des données renvoyées par un service de l application. Lorsque l utilisateur invoque un adaptateur de contenu (action "user request" dans la figure 75), ce dernier sollicite l adaptateur de services associé pour récupérer ses données de sortie (activité "get service adapter result"). Pour chaque paramètre de sortie de ces données, l adaptateur de contenu exécute la liste des opérateurs d adaptation identifiée Tarak CHAARI - 147 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS dans la phase de calcul du plan d adaptation (activité "run adaptation plan"). Enfin cet adaptateur renvoie les données adaptées. Dans le cas où il y a un problème d exécution du plan d adaptation (événement "content adaptation error"), l adaptateur de contenu renvoie les données originales obtenues après l invocation de l adaptateur de services. Par exemple, ce cas peut avoir lieu quand l un des services du plan d adaptation ne répond pas à cause d un problème de connexion. Figure 75 - Diagramme d activités de l adaptateur de contenu 2.6 GESTIONNAIRE D ADAPTATION DE PRESENTATION Le gestionnaire d adaptation de présentation assure la génération automatique d interfaces homme - machine adaptées à leur contexte d utilisation. Dès que le module d adaptation de contenu envoie une notification signalant la fin du processus de préparation de l adaptation de contenu, le gestionnaire d adaptation de présentation génère une fenêtre graphique pour chaque service du modèle fonctionnel adapté (generate window for each service dans la figure 76). Cette fenêtre assure la saisie des valeurs d entrée du service, son invocation, et l affichage du résultat de son exécution. Ensuite, le gestionnaire d adaptation de présentation ajoute des facilités de navigation pour les fenêtres générées afin de garantir l utilisation correcte des différents services de l application adaptée (generate navigation facilities dans la figure 76). Le code généré est mis en cache pour une réutilisation ultérieure de l application dans le même contexte. Enfin, le gestionnaire d application de SECAS est notifié de la fin du processus de génération de l interface utilisateur adaptée (notify presentation adaptation end dans la figure 76). Figure 76 - Diagramme d activités du gestionnaire d adaptation de présentation Tarak CHAARI - 148 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS 3. Modélisation statique Dans cette partie, nous divisons notre plateforme SECAS en paquetages et nous détaillons les diagrammes de classes des paquetages principaux. La figure 77 présente le diagramme des paquetages principaux de SECAS. Notre prototype comprend cinq paquetages principaux : secas.adaptation, secas.application, secas.context, secas.util et secas.administration. Nous détaillons le rôle et le contenu de ces paquetages dans la suite de cette section. secas adaptation application presentation content services ui services data context util administration Figure 77 - Diagramme des paquetages de SECAS 3.1 PAQUETAGE «SECAS.APPLICATION» Ce paquetage modélise une application et gére son intégration dans la plateforme SECAS. Nous retrouvons dans ce paquetage le gestionnaire d applications de SECAS (SecasApplicationManager) qui permet de déployer des applications (SecasApplication) à l aide d une classe ApplicationDeployer. Nous associons une session (UserSession) dès la connexion d un utilisateur à une application adaptée (représentée par une instance de SecasApplication). Ce paquetage comprend aussi une structure d échange (exchangestructure) qui garantit le passage de paramètres entre les services de l application. Tarak CHAARI - 149 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS Figure 78 - Diagramme de classes du paquetage "secas.application" 3.2 PAQUETAGE «SECAS.APPLICATION.SERVICES» Le paquetage «secas.application.services» décrit l aspect fonctionnel d une application. On trouve dans ce paquetage la classe FunctionalModel qui représente le modèle fonctionnel d une application, composé d un ensemble de services décrits par un descripteur de service (ServiceDescriptor). Nous avons aussi dédié une classe Parameter à la description des paramètres d entrée et de sortie de chaque service. Nous associons une instance du modèle fonctionnel à chaque session utilisateur dès qu il se connecte à une application déployée dans SECAS. Figure 79 - Diagramme de classes du paquetage "secas.application.services" 3.3 PAQUETAGE «SECAS.APPLICATION.DATA» Le paquetage «secas.application.data» décrit les données renvoyées par les services de l application. On retrouve dans ce paquetage, la classe MediaObjectDescriptor qui décrit la donnée encapsulée par un paramètre de sortie ou d entrée d un service. Cette classe maintient Tarak CHAARI - 150 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS les différentes propriétés des données comme la taille, le format, le type, le nombre de couleurs, la description MPEG7... Figure 80 - Diagramme de classes du paquetage "secas.application.data" 3.4 PAQUETAGE «SECAS.APPLICATION.UI» Le paquetage «secas.application.ui» concerne l interface utilisateur des applications déployées dans SECAS. Nous avons défini l ensemble des entités graphiques nécessaires pour assurer l interaction avec les services et les données adaptés de l application. Ces entités sont définies d une façon abstraite indépendante du contexte d utilisation de l application. Elles constituent l environnement d exécution abstrait de l interface utilisateur de l application (Abstract Interface Runtime Environment). Notons que le concepteur de l application doit fournir une implémentation de ces entités pour chaque plateforme cible (API graphique disponible sur le terminal utilisé). Nous retrouvons dans ce paquetage : (i) la classe MainWindow qui représente l écran principal de l application, (ii) la classe Window qui représente une fenêtre graphique associée à un service de l application, (iii) la classe Panel qui représente le panneau d entrée ou de sortie d un service, (vi) la classe Component qui représente les composants d interaction qui encapsulent les paramètres d entrée et de sortie des services et (v) la classe Command qui encapsule les actions qu un utilisateur peut effectuer sur l interface d interaction avec l application. Chaque commande doit être associée à un gestionnaire d évènement EventManager qui exécute le code nécessaire pour réagir aux actions de l utilisateur. Tarak CHAARI - 151 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS Figure 81 - Diagramme de classes du paquetage "secas.application.ui" 3.5 PAQUETAGE «SECAS.ADMINISTRATION» Figure 82 - Diagramme de classes du paquetage "secas.administration" Le paquetage «secas.administration» offre à l administrateur et aux concepteurs les interfaces graphiques qui permettent le déploiement des applications et l administration des modules de la plate-forme SECAS. Nous avons dédié une classe à chaque cas d utilisation pour l administration de la plateforme. Par exemple, UsersManageInternalFrame pour la gestion des utilisateurs, ApplicationsInternalFrame pour lister les applications déployées dans la plateforme et ConfigurationInternalFrame pour la configuration et la gestion de ces applications. Une fenêtre principale MainWindow, assure l accès à ces classes. Tarak CHAARI - 152 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS 3.6 PAQUETAGE «SECAS.UTIL» Ce paquetage offre un ensemble d'outils utilisés par les classes des autres paquetages. Ces outils offrent des fonctions génériques comme l accès aux fichiers XML, l évaluation des expressions logiques et le chargement des fichiers de configuration de la plateforme. Figure 83 - Diagramme de classes du paquetage "util" 3.7 PAQUETAGE «SECAS.CONTEXT» Le paquetage context assure la communication de la couche d adaptation avec la couche de gestion de contexte. Il s appuie sur une classe principale contextconsumer qui offre les fonctions nécessaires pour récupérer les valeurs des paramètres du contexte. Dans notre prototype nous avons simulé cette communication par des accès à un fichier XML local contenant un profil de contexte (LocalContextConsumer). Nous avons simulé le changement des valeurs de contexte par des modifications directes sur des paramètres de contexte dans ce fichier. ContextConsumer conection : Connection producer : MessageProducer session : Session getcontextvalues() : Hashtable getcontext() getcontextvalue() context dependson LocalContextConsumer root : Element contexthaschanged : boolean getcontext() : void getcontextvalues() : Hashtable getcontextvalue() : String Figure 84 - Diagramme de classes du paquetage "context" 3.8 PAQUETAGE «SECAS.ADAPTATION.SERVICES» Ce paquetage contient les classes qui réalisent l adaptation fonctionnelle des applications déployées. Nous y retrouvons le gestionnaire d adaptation de services (ServiceAdaptationManager) qui permet de lancer le processus d adaptation fonctionnelle. Ce Tarak CHAARI - 153 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS gestionnaire utilise la classe (Rule) pour appliquer les règles d adaptation spécifiées pour l application. Cette classe permet d évaluer les conditions des règles et d appliquer leurs actions d adaptation. Cette classe n applique que les actions inter-services (Faction) et délègue les actions intra-services (VAction et SAction) à l adaptateur (adapter). Dans ce paquetage, nous avons défini aussi la classe ParameterHolder qui représente les paramètres des actions d adaptation. Nous nous basons sur un fichier de configuration écrit en XML qui détaille le nom de classe de chaque action d adaptation et ses différents paramètres (voir figure 69 et figure 70). Ceci garantit l évolutivité de notre stratégie d adaptation en l enrichissant avec de nouvelles actions d adaptation sans modifier le code de la plateforme. La figure 85 illustre le diagramme de classes du paquetage d adaptation de services. Figure 85 - Diagramme de classes du paquetage d adaptation de services 3.9 PAQUETAGE «SECAS.ADAPTATION.CONTENT» Ce paquetage contient les classes nécessaires pour réaliser l adaptation des données renvoyées par les services de l application. Nous y retrouvons le gestionnaire d adaptation de contenu (ContentAdaptationManager) qui permet de lancer le processus d adaptation des données renvoyées par les adaptateurs de services. Ce gestionnaire utilise le proxy local d adaptation de contenu (LocalAdaptationProxy) pour déterminer les plans d adaptation (AdaptationPlan) optimaux de chaque paramètre de sortie des différents services de l application. Le proxy s appuie sur le composant de planification de l adaptation de contenu (AdaptationPlanificationComponent) pour calculer ces plans d adaptation. Ce composant utilise l annuaire des services d adaptations de contenu (AdaptationServiceRegistry) pour Tarak CHAARI - 154 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS construire les différentes séquences possibles de services qui peuvent fournir un résultat adapté au contexte d utilisation. La figure 86 illustre le diagramme de classes du paquetage d adaptation de contenu. Figure 86 - Diagramme de classes du paquetage d adaptation de contenu 3.10 PAQUETAGE «SECAS.ADAPTATION.PRESENTATION» Ce paquetage contient les classes nécessaires pour réaliser la génération automatique du code des interfaces utilisateur qui garantissent l interaction avec les services et les données adaptées grâce aux deux paquetages précédents. Nous y retrouvons le gestionnaire d adaptation de présentation (PresentationAdaptationManager) qui permet de lancer le processus de génération des interfaces utilisateur. Pour chaque service du modèle fonctionnel, le générateur d interfaces utilisateur (UserInterfaceGenerator) construit une fenêtre adaptée à son contexte d utilisation en se basant sur la librairie des composants graphiques disponibles dans la plateforme cible (currenttargetplatform). Cette fenêtre assure l interaction avec le service en question. Nous avons utilisé le modèle MVC [Krasner88] pour organiser le code des fenêtres générées. Ainsi, le générateur utilise les classes VueGenerator, ModelGenerator et ControllerGenerator pour produire respectivement la vue, le modèle et le contrôleur de chaque fenêtre. La figure 87 illustre le diagramme de classes du paquetage d adaptation de présentation. Tarak CHAARI - 155 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS Figure 87 - Diagramme de classes du paquetage d adaptation de présentation 4. Déploiement de la plateforme Dans cette section, nous illustrons l organisation du code de la plateforme SECAS en présentant un diagramme de composants et un diagramme de déploiement UML. 4.1 DIAGRAMME DE COMPOSANTS La figure 88 présente un diagramme de composants de notre plateforme. Elle illustre l organisation logique du prototype que nous avons développé. Le code de ce prototype est essentiellement archivé dans un fichier (SECAS.jar). Cette application offre deux fonctionnalités principales à l utilisateur final : lister les applications disponibles (IListApps) et invoquer leurs services adaptés (IAdapt). Elle offre aussi une interface d administration (IConfiguration) aux concepteurs afin de pouvoir déployer et gérer des applications à adapter (ApplicationToAdapt). Le prototype que nous avons développé utilise principalement quatre ressources XML : "configuration.xml" pour décrire les différents opérateurs d adaptation fonctionnelle que SECAS utilise, "context.xml" pour décrire des contextes d utilisation, "FunctionalModel.xml" pour décrire les modèles fonctionnels des applications et "rules.xml" pour décrire les règles d adaptation fonctionnelle. Tarak CHAARI - 156 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS Figure 88 - Diagramme de composants de SECAS 4.2 DIAGRAMME DE DEPLOIEMENT Pour déployer notre plateforme, nous avons utilisé le conteneur OSGI oscar [OSGi03]. Ce conteneur offre un développement modulaire et dynamique d applications. En effet, OSGI garantit l ajout de nouveaux modules et de nouvelles fonctionnalités à une application sans la redémarrer ou la recompiler. OSGI nous a été très utile surtout pour le déploiement dynamique des adaptateurs de services et des adaptateurs de contenu sous formes de services XML-RPC [UserLand99]. Les tests que nous avons réalisés ont montré que ce protocole est beaucoup plus léger et plus efficace que le protocole SOAP [Scribner00] surtout pour les terminaux mobiles à faible capacité. La figure 89 présente le diagramme de déploiement de la plateforme SECAS. Ce diagramme illustre la distribution des différents modules de SECAS sur la configuration matérielle de notre prototype. Figure 89 - Diagramme de déploiement de SECAS 5. Scénario générique d utilisation de SECAS Pour rappeler notre stratégie d adaptation, nous décrivons dans cette section, le scénario générique d adaptation d une application à de nouveaux contextes d utilisation grâce à notre plateforme SECAS. Ce scénario est basé sur onze étapes principales : Tarak CHAARI - 157 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS 1- Un concepteur utilise le gestionnaire d applications pour déployer le modèle fonctionnel de l application. 2- SECAS prépare la couche d adaptation en instanciant et déployant un adaptateur pour chaque service de l application. Le modèle fonctionnel est ainsi mis à jour pour utiliser les adaptateurs à la place des services d origine. 3- Le concepteur fournit le descripteur des règles d adaptation fonctionnelle nécessaires pour réaliser l adaptation de services. 4- Le gestionnaire d adaptation de services instancie ces règles et les abonne aux paramètres du contexte qui les concernent auprès du courtier de contexte. 5- Le gestionnaire d adaptation de services configure les adaptateurs selon les règles d adaptation fournies et selon le contexte d utilisation de l application. 6- Ce même gestionnaire notifie le gestionnaire d applications de SECAS pour lancer le processus de préparation de l adaptation de contenu. 7- Le gestionnaire d adaptation de contenu instancie un adaptateur de contenu pour chaque service du modèle fonctionnel et calcule les transformations nécessaires pour adapter les données renvoyées par les services de l application. 8- Le gestionnaire d adaptation de contenu met à jour le modèle fonctionnel de l application pour utiliser les adaptateurs de contenu à la place des adaptateurs de services. Les types de données renvoyées sont aussi modifiés selon les transformations calculées dans l étape précédente. 9- Le gestionnaire d adaptation de contenu envoie une notification de fin de préparation de l adaptation des données renvoyées par les services de l application. 10- Le gestionnaire d adaptation de présentation (PresentationAdaptationManager) capture cette notification et lance le processus de génération de l interface utilisateur nécessaire pour l interaction avec les services et les données adaptées de l application. Cette interface est mise en cache pour qu elle puisse être utilisée dans le contexte actuel de l application. 11- Dès que le contexte d utilisation de l application change, le scénario d adaptation est repris à partir de l étape 5. L adaptation effective des services et des données de l application est réalisée lorsque l utilisateur final se connecte à la plateforme et interagit avec l application adaptée en invoquant ses services à travers l interface graphique générée. Nous utilisons ce scénario dans un cas concret pour l adaptation d une application médicale dans la section IV de ce chapitre. Tarak CHAARI - 158 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS III. DEVELOPPEMENT DE LA PLATEFORME SECAS Dans cette section nous détaillons quelques considérations techniques qui concernent le développement de la plateforme SECAS. 1. Implantation de la couche d adaptation fonctionnelle 1.1 REGLES D'ADAPTATION Le gestionnaire d'adaptation de services utilise un ensemble de règles d'adaptation pour effectuer le processus d'adaptation du modèle fonctionnel de l'application. Il gère aussi une base de règles génériques que la plateforme doit appliquer pour garantir l'adaptation de services. Les règles sont organisées par ordre de priorité pour définir un plan d'adaptation fonctionnel pour l'application. La définition de ces règles est réalisée par le concepteur. Ce dernier peut se contenter de choisir une liste de règles prédéfinies dans la base des règles génériques de la plateforme afin de les attacher à l application qu il veut adapter. Il peut ensuite raffiner et personnaliser le processus d adaptation de services en ajoutant des règles spécifiques à son application. Ces règles modifient le modèle fonctionnel de l application selon les mécanismes que nous présentons dans le paragraphe suivant. 1.2 ADAPTATION DU MODELE FONCTIONNEL L'adaptation du modèle fonctionnel se base sur un ensemble de mécanismes que nous détaillons dans les sous-sections suivantes: 1.2.1 Redirection des appels de services L'appel d un service est redirigé vers l'adaptateur qui est un intermédiaire entre l'utilisateur et le service d origine de l application. Pour réaliser cette redirection, nous adaptons l'url et le nom de la méthode de chaque service. La figure 90 présente un extrait de la description d un service avant son adaptation. La figure 91 représente la description de l adaptateur attaché à ce service. <url>http://sicomserver.insa-lyon.fr/xmlrpc</url> <method id="sicom.listealerte"> Figure 90 - Extrait de la description d un service avant son adaptation <url>http://secasserver.insa-lyon.fr/xmlrpc</url> <method id="sicom_listealertesadapter.adapt"> Figure 91. Extrait de la description d un adaptateur de service Tarak CHAARI - 159 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS 1.2.2 Ajout de données de contrôle Nous ajoutons un paramètre de sortie «rang» à chaque service initial de l application. Ce paramètre est nécessaire pour assurer l unicité des valeurs renvoyées par les services. Par exemple, nous pouvons décomposer un service qui retourne un tableau contenant les températures d un patient en deux services : Le premier affiche les dates de mesures de température et le deuxième retourne la valeur de la température correspondante à la date sélectionnée par l'utilisateur. Comme plusieurs mesures peuvent être prises le même jour, l'ajout d'un «rang» pour chaque ligne assurera la distinction entre les différentes valeurs sélectionnées. 1.3 IMPLEMENTATION DES ADAPTATEURS Nous avons choisi la technologie des services web pour implémenter les adaptateurs de services et les adaptateurs de contenu. Cette technologie offre des moyens d intégration faciles pour le développement distribué [Austin02]. Grâce à leur auto-description fonctionnelle par le langage WSDL, les services Web ont constitué une implémentation adéquate de la formalisation que nous avons élaborée (i) des services applicatifs, (ii) des adaptateurs de services et (iii) des adaptateurs de contenu. 1.4 CONFIGURATION DES ADAPTATEURS DE SERVICES L'exécution des règles d adaptation fonctionnelle permet de configurer les adaptateurs de services. Suite à l'application d'une règle, un service S initial peut être décomposé en un ensemble de services adaptés {S1, S2,..., Sk}. Ces services peuvent être eux aussi adaptés en appliquant les règles qui suivent. Ainsi, l'adaptateur gère une pile qui stocke la liste des opérateurs d'adaptation qui doivent être appliqués sur le service initial lors de son invocation. 2. Implantation de la couche d adaptation de contenu La couche d adaptation de contenu assure l adaptation des données renvoyées par les services au contexte de l utilisation de l application. Le gestionnaire d adaptation de contenu «ContentAdaptationManager» vérifie si les services résultant de l adaptation fonctionnelle fournissent des données adaptées au contexte. Pour chaque service, ce gestionnaire instancie un adaptateur de contenu qui assure leur adaptation. L adaptateur délègue cette tâche au mandataire local d adaptation de contenu que nous avons importé du prototype de thèse de G. Berhe [Berhe05]. Tarak CHAARI - 160 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS 3. Implantation de la couche d adaptation de présentation La couche d adaptation de présentation assure la génération automatique d interfaces utilisateur adaptées permettant d interagir avec les différents services et données de l application. Le gestionnaire d adaptation de présentation (Presentation Adaptation Manager) récupère le modèle fonctionnel adapté sollicité par l utilisateur. Pour chaque service de ce modèle, le gestionnaire génère une fenêtre graphique qui permet de communiquer avec ce service. Le processus de génération se base sur les types de données renvoyées par le service et sur la librairie des composants d interaction disponibles sur le terminal de l utilisateur. Le générateur prend aussi en compte les préférences de présentation spécifiée par l utilisateur dans son profil de contexte. Le prototype que nous avons mis en œuvre permet de générer pour une même application, une interface d interaction JAVA pour des PC standard (compatible avec J2SE [Sun07a]), des PC de poche (compatibles avec le profil CDC/PERSONNEL JAVA [Sun00]) et des téléphones mobiles (compatible avec le profil CLDC/MIDP [Sun07b]). 4. Statistiques Le prototype que nous avons développé comporte environ 80 classes et 14500 lignes de code Java. Le tableau 5 donne la répartition des ces classes dans les différents paquetages de SECAS. Paquetage Classes Lignes adaptation.services 20 4000 adaptation.content 13 2200 adaptation.presentation 9 2300 Application 16 2900 Util 6 2000 Context 2 150 Administration 13 1000 Total 79 14450 Tableau 5 - Nombre de classes et de lignes de code dans le prototype SECAS IV. UTILISATION DE SECAS DANS LE PROJET SICOM Le projet régional Systèmes d Information COMmunicants pour la Santé (SICOM) a été financé par la Région Rhône-Alpes dans le cadre des thématiques prioritaires de septembre 2000 à septembre 2003 [Flory04]. L objectif de ce projet était de définir une architecture Tarak CHAARI - 161 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS générique de système de suivi de patients à distance (prise en charge à domicile). Dans le cadre de ce projet, notre collaboration avec le service de néphrologie de l hôpital Edouard Herriot, l association de suivi de patients à domicile AURAL, la société Baxter France qui a fourni des dialyseurs, et avec France Telecoms R&D (dont la plate-forme de visioconférence permet de relier l association de suivi et le patient) a permis de définir les besoins d un suivi de qualité des patients dialysés à domicile atteints d une insuffisance rénale. Un dossier de dialyse péritonéale comporte la description du traitement prescrit, la description de chaque acte de dialyse effectué, une liste d images qui permet de voir l évolution du cathéter au besoin, des mesures médicales disponibles (températures, poids, volumes de filtration ). Le médecin de l association de suivi accède à des services supplémentaires, tels une liste d alarmes reçues au sujet de l ensemble des patients suivis (données anormales détectées par le système, demandes de patients ). Les services utiles à l infirmière de l association de suivi concernent la gestion des prescriptions et des fournitures, les prises de rendez-vous avec les acteurs devant se rendre au domicile D autres services ont été définis pour les assistantes sociales, les infirmières en charge du traitement du patient, les médecins de ville, les pharmaciens L application développée dans le cadre du projet SICOM ne permet que l utilisation de ses services sur un PC standard. Les professionnels de santé nous ont exprimé le besoin d accéder à ces mêmes services en utilisant des PDA et des téléphones mobiles. Nous avons validé l approche d adaptation que nous avons définie dans SECAS sur cette application. Nous avons vérifié le bon fonctionnement des différents modules de SECAS par les tests suivants : - Test de déploiement de SICOM. - Test de l adaptation du comportement global (services, données et présentation) de l application SICOM. - Test de la connexion/déconnexion d un utilisateur. - Test de l utilisation des services adaptés. Nous avons utilisé un micro-ordinateur Pentium 4, 2.4 GHz avec une mémoire de 512 Mo pour déployer la plateforme SECAS et un téléphone mobile de type Nokia 6230 pour le test de l application adaptée du coté de l utilisateur final. 1. Déploiement de SICOM avec l interface d administration de SECAS L interface présentée sur la figure 92 assure le déploiement et la mise à jour de nouvelles applications. La fenêtre «Configuration» permet de déployer ou de mettre à jour une Tarak CHAARI - 162 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS application à adapter. Pour déployer une nouvelle application comme SICOM, le concepteur déploie le modèle fonctionnel dans la zone «Functional Model» et les règles d adaptation dans la zone «Rules» de cette interface d administration. Le modèle fonctionnel de l application et ses règles d adaptation sont fournies sous la forme de fichiers XML. Les annexes A et B de ce mémoire illustrent le contenu de ces deux fichiers pour l application SICOM. Une fois déployée, l application apparait dans la fenêtre «Applications». Figure 92 - Interface d administration de la plate-forme SECAS 2. Adaptation de l application «SICOM» Le premier contexte d utilisation que nous avons considéré illustre un médecin qui interagit avec les différents services de SICOM sur un PC standard. Le deuxième contexte concerne l utilisation de la même application par le même médecin avec un téléphone mobile. Pour pouvoir utiliser cette application sur ce genre de terminaux à faibles capacité de calcul et de stockage, nous l avons intégré dans notre plateforme pour l adapter. Le contexte décrivant l utilisation de cette application sur un téléphone mobile est listé en annexe C de ce mémoire. Cet exemple nous a permis de valider notre architecture et notre stratégie d adaptation. Tarak CHAARI - 163 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS 2.1 UTILISATION DE SICOM SUR PC Figure 93 - Visualisation d un dossier de dialyse péritonéale sur un PC standard La présentation d un dossier de dialyse (voir Figure 93), peut être affichée en une seule fenêtre sur un grand écran. Cette figure présente une fenêtre composée de trois entités logicielles pour les terminaux standards. La première contient un service affichant la liste des alertes des patients suivis par le professionnel de santé connecté. La deuxième correspond à un service retournant des informations générales sur le dossier de dialyse et le traitement de dialyse prescrit pour ce patient. Enfin, la troisième entité présente une liste d images médicales du dossier du même patient. Un menu permet la navigation entre les différentes entités logicielles de l application. Ce menu présente le chemin parcouru dans le modèle fonctionnel initial de cette application. La figure 94 présente le modèle fonctionnel de l application SICOM avant son adaptation avec SECAS. L implémentation XML de ce modèle est fournie dans l annexe A de ce mémoire. Nous avons élaboré ce modèle après avoir identifié les services que l application SICOM offre à l utilisateur. Nous revenons sur l élaboration du modèle fonctionnel des applications dans les conclusions et les perspectives de ce mémoire. Tarak CHAARI - 164 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS Authentification UserID ListeAlerte PatientID PatientID PatientID Temperatures DossierDialyse listeimages Figure 94 - Le modèle fonctionnel de l application SICOM avant son adaptation avec SECAS 2.2 UTILISATION DE SICOM SUR TELEPHONE MOBILE La figure 99 donne l équivalent de l application de la figure 93 pour les téléphones mobiles après son adaptation avec la plateforme SECAS. Le menu de navigation entre les services est remplacé par des écrans (E1), (E4), (E6) et (E7) fournissant la liste des services accessibles dans l application grâce à la fonction getavailableservices() du module d adaptation de présentation. Le premier service de cette application (affichage des alertes) est éclaté en deux services en utilisant la règle de la figure 95. Le premier service listealertes(idalerte) récupère la liste des identifiants des alertes qui ont été déclenchées (écran E2). Le deuxième service récupère la valeur correspondant à l identifiant sélectionné par l utilisateur (écran E3). La représentation XML de cette règle est donnée dans l annexe B de ce mémoire (rule 1). {(context.terminal.hardwareplatform.memory < 10240) ( f F f.output.length > 1) firstvalues=projection(f, f.output[1]) replaceservice(f, firstvalues) selectedinstance=selection(f, f.output[1] = selected(firstvalues)) insertserviceafter(firstvalues.selectedinstance)} Figure 95 - Première règle d'adaptation de l'application SICOM Le deuxième service de l application initiale (affichage des données générales sur le traitement de dialyse) correspond à l écran E5. Les données sont affichées verticalement ; alors que sur les terminaux standards elles sont présentées horizontalement (adaptation de présentation). Le même service initial est utilisé dans le nouveau contexte (pas d adaptation Tarak CHAARI - 165 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS fonctionnelle). {(context.terminal.softwareplatform.accepteddatatypes.acceptimages) (context.terminal.type= cldc ) ( f F f.output.length > 1) ( i [0, f.output.length] f.output[i].type= secas:binaryimage ) (displaynonimage = projection( f, (f.output[i]) ) (displayimage = projection( f, f.output[i]) ) replaceservice(f,displaynonimage) insertalternativeservice(displaynonimage, displayimage) } Figure 96 - Deuxième règle d'adaptation de l'application SICOM Le troisième service affichant les images médicales est éclaté sur trois services après l application de la règle de la figure 95 suivie de la règle de la figure 96. En effet, la première règle éclate le service listeimages() en deux services : le premier listeimages(nomimage) affiche la liste des images renvoyées par le service d origine et le second renvoie les autres informations (urlimage, descriptionimage et binaireimage) correspondant à l image sélectionnée dans le premier. Ensuite, l application de la deuxième règle divise ce deuxième service en deux autres services : le premier renvoie les paramètres dont le type n est pas une image listeimages(urlimage :descriptionimage) et le deuxième renvoie l image binaire listeimages(binaireimage). Ainsi nous obtenons les trois services : listeimages(urlimage) (écran E8), listeimages(urlimage :descriptionimage) (écran E9) et listeimages(binaireimage) (écran E10). L image présentée par ce dernier service est reformatée et redimensionnée à la taille de l écran (adaptation de contenu). La représentation XML de la règle de la figure 96 est donnée dans l annexe B de ce mémoire (rule 2). { ( context.terminal.accepteddatatypes.acceptimages) ( i [0, f.output.length] f.output[i].type= secas:binaryimage ) lockservice(f) } Figure 97 - Troisième règle d'adaptation de l'application SICOM Dans le cas où le terminal utilisé ne supporte pas l affichage d images, le service listeimages(binaireimage) est verrouillé en utilisant la règle de la figure 97. La représentation XML de cette règle est donnée dans l annexe B de ce mémoire (rule 3). Le modèle fonctionnel résultant de l application des trois règles que nous venons de présenter est illustré sur la figure 98. La plateforme SECAS utilise ce modèle fonctionnel pour adapter les données renvoyées par les services définis dans ce modèle. Ainsi, SECAS fournit un nouveau modèle fonctionnel où chaque service renvoie des données directement exploitable sur le terminal de d utilisateur. Enfin, ce nouveau modèle fonctionnel est utilisé Tarak CHAARI - 166 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS pour générer automatiquement l interface utilisateur qui garantit l interaction avec les services et les données adaptés de l application SICOM. Cette interface est présentée dans la figure 99. Authentification UserID is not null ListeAlertes(id) idalerte Selected(ListeAlertes) iddossier iddossier iddossier Temperatures (dates) traitement listeimages(nom) idmesure Context:terminal:software:acceptimages idimage idimage Temperatures (value) listeimages(binaire) listeimages (description,url) Figure 98 - modèle fonctionnel adapté de l'application SICOM Pour l adaptation de l application SICOM à des environnements mobiles, nous avons utilisé des règles d ordre générique (celles de la figure 95, de la figure 96 et de la figure 97). Elles peuvent être utilisées pour d autres applications afin de les adapter pour des téléphones mobiles du même type. La base de règles d une application peut être enrichie par des règles spécifiques en ajoutant une clause logique qui référence un élément spécifique du modèle fonctionnel. Par exemple, nous pouvons ajouter la clause f.name= listealertes dans la partie expressions d une règle pour qu elle ne soit appliquée qu au service particulier listealertes. Il faut également vérifier la consistance des règles d adaptation d une application en détectant les conflits ou les erreurs d écriture de ces règles et en proposant des solutions pour les résoudre. Ce travail a été effectué durant un master de recherche dans notre équipe [Zouari07]. Tarak CHAARI - 167 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 Figure 99 - Visualisation du même dossier médical que la figure 93 sur un terminal mobile V. UTILISATION D UN NOUVEAU MODELE DE CONTEXTE DANS SECAS Afin de valider les objectifs de généricité et de réutilisation, nous avons intégré un nouveau modèle de contexte dans SECAS. Nous avons substitué notre modèle de contexte par celui de Tarak CHAARI - 168 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS Dejene Ejigu [Chaari07] sans modifier notre approche d adaptation. Ce modèle est basé sur une représentation du contexte sous la forme d une ontologie à deux niveaux : un niveau de base et un niveau spécifique au domaine de l application. Le niveau de base contient les concepts qui définissent les concepts généraux du contexte (utilisateur, terminal, localisation ). Ce niveau de base correspond aux cinq facettes du contexte définies dans notre modèle (section II du chapitre III). Le niveau spécifique contient des sous-classes des concepts définis dans le niveau de base (par exemple : médecin comme sous classe de utilisateur, PDA comme sous classe de terminal, hôpital comme sous classe de localisation ). Les concepts de cette ontologie à deux niveaux peuvent être liés par des relations représentées par des prédicats comme utilise(utilisateur, Terminal) pour désigner le terminal utilisé par un utilisateur donné. La figure 100 donne un exemple d une partie de l ontologie modélisant le contexte. Le niveau de base de cette ontologie comporte deux concepts User et Terminal. Le niveau spécifique comprend Specialist, practitioner, nurse et patient comme spécialisations de User. Il contient aussi les concepts SmartPhone, PDA et PC spécialisant le concept de base Terminal. Figure 100 - Exemple de modélisation du contexte par une ontologie Nous avons intégré ce nouveau modèle de contexte sans changer notre approche d adaptation. En effet, nous avons seulement modifié la partie expressions des règles d adaptation afin de référencer les nouveaux éléments (concepts et relations) définis dans l ontologie du contexte. Ensuite, nous avons réutilisé les mêmes opérateurs pour l adaptation de l application SICOM à des environnements mobiles. Enfin, l intégration du modèle de contexte de Dejene Ejigu dans notre plateforme nous a permis de valider la généricité de notre approche d adaptation d une part et d atteindre un Tarak CHAARI - 169 - Thèse de doctorat

Chapitre V Contributions : Implantation et utilisation de SECAS degré d expressivité sémantique plus élevé au niveau de la description du contexte d autre part. VI. CONCLUSION Dans ce chapitre, nous avons présenté le prototype réalisé pour valider notre approche d adaptation. Nous avons détaillé la conception et la réalisation technique de ce prototype. Nous avons testé notre approche d adaptation en déployant une application médicale (SICOM) et en l adaptant à de nouveaux contextes d utilisation. Cette application a été conçue et réalisée pour des professionnels de santé dans le domaine de la néphrologie dans le but de leur permettre d accéder aux dossiers médicaux de leurs patients. Dans leur première version, les services de cette application ne peuvent être exploités qu à travers des PC de bureau ou des PC portables. Après son intégration dans SECAS, l application est désormais accessible avec des terminaux mobiles qui ont des capacités matérielles et logicielles totalement différentes des PC standards. Pour l intégration de cette application, nous avons fourni son modèle fonctionnel, un fichier de règles d adaptation fonctionnelle et un fichier décrivant le nouveau contexte d utilisation de l application. Ces fichiers sont donnés respectivement dans les annexes A, B et C de ce mémoire. Pour réaliser l adaptation de présentation de cette application nous avons aussi fourni l implémentation de notre API graphique abstraite (Abstract Interface Runtime Environment) pour les types de terminaux utilisés (PCs standards, PCs de poche et téléphones mobiles). Tarak CHAARI - 170 - Thèse de doctorat

P CONCLUSIIONS ET PERSPECTIIVES Imagination is more important than knowledge (Albert Einstein)

Conclusions et perspectives PLAN I. BILAN 173 II. PERSPECTIVES 174 Tarak CHAARI - 172 - Thèse de doctorat

Conclusions et perspectives I. BILAN Lors de notre étude des travaux existants dans le domaine de la sensibilité au contexte, nous avons remarqué un grand intérêt aux étapes de capture, d interprétation, de modélisation et de dissémination du contexte. Par contre, nous avons constaté l absence d une approche générique et complète pour adapter les applications au contexte. La majorité des contributions existantes pour combler ce manque présentent des approches d adaptation ad hoc spécifiques à un domaine particulier (comme la sensibilité à la localisation de l utilisateur). Dans ce travail de thèse, nous avons conçu et développé une plateforme d adaptation d applications à de multiples contextes d utilisation. Cette plateforme nous a permis de réaliser les contributions suivantes : - Conception d une architecture générique qui offre les moyens et les outils nécessaires pour réaliser l adaptation d applications à de nouveaux contextes d utilisation. Cette architecture est basée sur trois couches principales : (i) une couche de déploiement d applications pour intégrer de nouvelles applications en vue de leur adaptation, (ii) une couche d adaptation instanciée dynamiquement au dessus des applications déployées et (iii) une couche de gestion de contexte qui permet de capturer et de disséminer le contexte vers la couche d adaptation. - Définition d une stratégie d adaptation globale au contexte sur trois volets : le comportement fonctionnel des services que l application offre à l utilisateur, les données renvoyées par ses services et l interface utilisateur qui assure l interaction avec ses services. - Facilité de l intégration et de l adaptation puisque notre approche d adaptation se base essentiellement sur une description fonctionnelle simple des services que l application d origine offre à l utilisateur. Ainsi, nous gagnons le temps considérable de développement d autres versions qui auraient été nécessaires sans SECAS pour supporter les nouveaux contextes d utilisation. - Evolutivité de notre stratégie d adaptation puisqu elle permet d ajouter facilement de nouveaux outils et de nouvelles actions d adaptations à l architecture sans devoir recompiler notre moteur d adaptation. - Implémentation de notre architecture en développant un prototype qui nous a permi de tester et de valider notre approche d adaptation. Afin de vérifier l évolutivité et l ouverture de notre approche d adaptation à d autres contributions dans le domaine de la sensibilité au contexte, nous avons testé et validé notre Tarak CHAARI - 173 - Thèse de doctorat

Conclusions et perspectives plateforme avec le modèle de contexte élaboré par Dejene Ejigu [Chaari07]. Ce modèle se base sur une ontologie pour la description du contexte d utilisation de l application. Nous pensons également que notre plateforme d adaptation n est pas restreinte au domaine de l informatique pervasive. En effet, son utilisation peut être généralisée pour garantir l évolution de tout type de système d information en fournissant la description de ses services et les opérateurs nécessaires pour réaliser son adaptation ou son extension. II. PERSPECTIVES Ce travail de thèse nous a permis de tracer plusieurs perspectives de recherche : - Pour pouvoir adapter des applications avec notre plateforme, le concepteur doit donner une description XML des services (comme l exemple en annexe A) qu elles offrent à l utilisateur. Il serait intéressant de proposer un outil qui permet d aider à la création de cette description avec des techniques de reverse engineering et/ou avec un monitoring des appels distants dans les applications client-serveur. Ceci permet de générer d une façon automatique, ou semi-automatique, la description des services offerts par ces applications. - Le modèle que nous avons établi pour décrire le noyau fonctionnel des applications est assez générique pour qu il puisse être utilisé pour la majorité des applications actuelles. Ce modèle constitue le minimum d informations qu on doit savoir sur l application pour qu elle puisse être adaptée avec notre approche. Il nous a permis de réaliser une stratégie d adaptation complète sur les services, les données et les interfaces utilisateur de ces applications. Cependant, le résultat de l adaptation et son impact sur le code interne de l application peut être raffiné et approfondi si nous disposons de plus de connaissances sur son noyau fonctionnel (architectures de l application, l ensemble des classes qui la constituent, l ensemble des services internes de l application ). Nous pensons à élaborer un modèle générique à granularité variable qui permettrait d incorporer ces connaissances supplémentaires et ainsi d approfondir l impact de l adaptation sur l application. - Pour pouvoir générer les interfaces utilisateur, notre plateforme utilise une bibliothèque de composants graphiques correspondant aux types de données renvoyées par les services de l application. Ces composants doivent être fournis pour chaque API implantée sur les terminaux utilisés. Notre plateforme supporte maintenant trois API JAVA : J2SE pour les pc standards, CDC Hotspot pour les PDA et J2ME Midp pour les téléphones mobiles. Pour intégrer d autres machines virtuelles, Tarak CHAARI - 174 - Thèse de doctorat

Conclusions et perspectives nous pensons à enrichir notre plateforme avec un générateur de composants graphiques en se basant sur la description de l API disponible sur le terminal. - Enfin, nous envisageons d intégrer l utilisateur final dans le processus d adaptation pour qu il puisse modifier des décisions actuellement prises d une façon automatique par notre plateforme. Ceci nous permettrait d avoir un retour d expérience sous la forme d une évaluation empirique du résultat produit par notre plateforme d une part et de raffiner notre processus d adaptation d autre part. Dans cette perspective, nous proposons d utiliser le paradigme de programmation par aspects afin de fournir des points d intervention de l utilisateur dans le processus d adaptation. Par ailleurs, nous pensons que l utilisation d un mécanisme d apprentissage pour mémoriser les décisions prise par l utilisateur peut être une solution intéressante pour améliorer les résultats d adaptation. Tarak CHAARI - 175 - Thèse de doctorat

BIIBLIIOGRAPHIIE

Bibliographie [Abowd97] [Abowd99] [Abrams99] [Agoston00] [Akan04] [Aksit03] [Andrade03] [Angin98] [Austin02] Abowd G. D., Atkeson, C. G., Hong et al.. Cyberguide : A mobile contextaware tour guide. ACM Wireless Networks, 1997, Vol. 5, N 3, pp. 421-433 Abowd, G. D., Dey, A. K., Brown, P. J., Davies, N., Smith, M., and Steggles, P. 1999. Towards a Better Understanding of Context and Context- Awareness. In Proceedings of the 1st international Symposium on Handheld and Ubiquitous Computing, September 27-29, 1999 Karlsruhe, Germany. H. Gellersen, Ed. (Lecture Notes In Computer Science, Vol. 1707, pp. 304-307) M. Abrams, C. Phanouriou. UIML: an XML language for building device independent user interfaces. XML99, December 1999, Philadelphia. Thomas Agoston, Tatsuro Ueda, and Yukari Nisimura, Pervasive computing in a networked world, In Proc. of INET 2000, 18-21 july 2000, Japan,. Ö B Akan and I F Akyildiz, ATL. An adaptive transport layer suite for nextgeneration wireless internet. IEEE Journal on Selected Areas in Communications, June 2004, Vol. 22, N 5, pp. 802-817 Aksit M., Choukair Z. Dynamic Adaptive and Reconfigurable Systems. In Overview and Prospective Vision. Actes des ICDCS Workshops 03, Providence, 2003, Rhode Island, USA, p. 84-92 L-F.Andrade, J-Luiz.Fiadeiro. Architecture Based Evolution of Software Systems. In the Third International School on Formal Methods for the design of Computer,communication and Software Systems: Software Architectures, SFM 2003, Italy, 2003 O. Angin, AT. Campbell, ME. Kounavis et al. The mobiware Toolkit: Programmable Support for Adaptive Mobile Networking. IEEE Personal Communication, 1998, Vol.5, No.4, pp. 32-43 D. Austin, A. Barbir, C. Ferris, S. Garg. Web Services Architecture Requirements. 19 August 2002. W3C Working Draft, http://www.w3.org/tr/2002/wd-wsa-regs20020819 (consulté le 02.07.2007) Tarak CHAARI - 178 - Thèse de doctorat

Bibliographie [Balzert96] [Baral96] [Bauer98] [Bederson95] [Beigl00] [Bennett94] [Berhe05] [Bharghavan97] [Bickmore97] [Bickmore97] H. Balzert, F. Hofmann, V. Kruschinski, C. Niemann. The Janus Application Development Environment Generating More than the User Interface. In J. Vanderdonckt (ed.): Computer-Aided Design of User Interfaces. Namur: Namur University Press, 1996, pp. 183-205 C. Baral, J. Lobo. Formal characterization of active databases. In Proceedings of the international Workshop on Logic in Databases (July 01-02, 1996). D. Pedreschi and C. Zaniolo, Eds. Lecture Notes In Computer Science, vol. 1154. Springer-Verlag, London, 175-195, 1996 Bauer M., Heiber, T., Kortuem, G. & Segall, Z. A collaborative wearable system with remote sensing. Proceedings of the 2nd International Symposium on Wearable Computers (ISWC98), CA : IEEE, 1998, Los Alamitos, pp. 10-17 Bederson, B. B. Audio Augmented Reality: A Prototype Automated Tour Guide. In Proceedings of Human Factors in Computing Systems (CHI 95) New York : ACM Press, 1995, pp. 210-211 Beigl M. MemoClip: A location based remembrance appliance. Personal Technologies, 2000, Vol. 4, N 4, pp. 230-233. F. Bennett, T. Richardson and A. Harter. Teleporting - Making Applications Mobile. Proc. In IEEE Workshop on Mobile Computing Systems and Applications, December 1994, Santa Cruz, California, pp. 82-84 Girma Berhe, Lionel Brunie, Jean-Marc Pierson. Distributed Content Adaptation for Pervasive Systems. ITCC, 2005, Vol. 2, pp. 234-241 V. Bharghavan, V. Gupta. A Framework for Application Adaptation in Mobile Computing Environments. In Proceedings of the IEEE Compsoc97, Aug 1997, Washington, D.C., USA, pp. 11-15 T. Bickmore and B. Schilit. Digestor. Device-independent Access to the World Wide Web. In Proceedings of the 6th World Wide Web Conference (WWW6), April 7-11, 1997, Santa Clara, California USA, pp. 655 663 T. Bickmore and B. Schilit. Digestor. Device-independent Access to the World Wide Web. In Proceedings of the 6th World Wide Web Conference (WWW6), April 7-11, 1997, Santa Clara, California USA, pp. 655 663 Tarak CHAARI - 179 - Thèse de doctorat

Bibliographie [Billington03] Billington J., Christensen S., Van Hee K. et al.. The Petri Net Markup Language : Concepts, Technology, and Tools. In W. van der Aalst and E. Best, editors, Application and Theory of Petri Nets 2003, 24th International Conference, Springer.(LNCS, Vol. 2679, June 2003, pp. 483 505) [Birnbaum97] Birnbaum, J. 1997. Pervasive information systems. Commun. ACM 40, 2 (Feb. 1997), 40-41. DOI= http://doi.acm.org/10.1145/253671.253695 (consulté le 02.07.2007) [Björk99] [Bodart95] [Bolot98] [Bolot98] [Booch98] [Bridges01] [Brotherton99] S. Björk, L.E. Holmquist, J. Redström et al. WEST: a Web browser for small terminals. In Proceedings of the 12th annual ACM symposium on User interface software and technology, Asheville, 07-10 November 1999, North Carolina, USA, pp.187-196 F. Bodart, A.-M. Hennebert, J.-M. Leheureux et al.. Towards a Systematic Building of Software Architectures: the TRIDENT Methodological Guide. In P. Palanque, R. Bastide (eds.): Design, Specification and Verification of Interactive Systems. Wien : Springer, 1995, pp. 262-278 J.C. Bolot, T. Turletti. Experience with rate control mechanisms for packet video in the Internet. Computer Communication Review, ACM, January 1998, Vol. 28, N 1, pp.4-15 J.C. Bolot, T. Turletti. Experience with rate control mechanisms for packet video in the Internet. Computer Communication Review, ACM, January 1998, Vol. 28, N 1; pp.4-15 Grady Booch, James Rumbaugh, and Ivar Jacobson. Unified Modeling Language User Guide. Reading (Mass.) : Adison Wesley, 1998, 482 p. (Addison Wesley Object Technology Series) P G Bridges, W K Chen, M A Hiltunen and al.. Supporting coordinated adaptation in networked systems. 8th Workshop on Hot Topics in Operating Systems (HotOS-VIII), May 2001, Elmau, Germany, pp. 162-168 Brotherton J., Abowd, G. D. & Truong, K. Supporting capture and access interfaces for informal and opportunistic meetings. In Atlanta, GA : Georgia Institute of Technology, GVU Center, (GIT-GVU-99-06), January 1999. Tarak CHAARI - 180 - Thèse de doctorat

Bibliographie [Brown96] [Brown97] P.J. Brown. The Stick-e Document: a framework for creating Context aware applications. In Electronic Publishing 96, (1996), Document Manipulation and Typography, 24-26 September 1996, Pala-Alto, California, USA, pp. 259-272 P.J. Brown, J.D. Bovey, X. Chen. Context-Aware applications : From the Laboratory to the Marketplace. IEEE Personal Communications, 1997, Vol. 4, N 5, pp. 58-64 [Calvary02] G. Calvary et J. Coutaz Plasticité des interfaces : une nécessité!, information-interaction-intelligence, Actes des deuxièmes Assises nationales du GDR I3, Nancy, décembre 2002. Toulouse : Cépaduès Editions, pp 247-261 [Cazzola99] [Chaari04] [Chaari07] [Chandra99] [Chandra99] [Chassot06] W. Cazzola, A. Sosio, A. Savigni et al. Architectural Reflection: Concepts, Design, and Evaluation. Technical Report RI-DSI 234-99. DSI. 1999, University degli Studi di Milano T. Chaari, F. Laforest Génération. Adaptation automatiques des interfaces utilisateurs pour des environnements multi-terminaux Le projet SEFAGI : Simple Environment For Adaptable Graphical Interfaces. Revue Ingénierie des systèmes d Information, n spécial systèmes d information pervasifs, 2004, Vol. 9, N 2/2004: pp. 11-38 T. Chaari, D. Ejigu, F. Laforest and V.-M. Scuturici. A Comprehensive Approach to Model and Use Context for Adapting Applications in Pervasive Environments. Int. Journal of Systems and software, 2007, 26 p. (à paraître). S. Chandra and C.S. Ellis. JPEG Compression Metric as a Quality Aware Image Transcoding. In 2nd Usenix Symposium on Internet Technologies and Systems (USITS 99), Oct. 1999, Berkeley, CA, USA, pp.81-92 S. Chandra and C.S. Ellis. JPEG Compression Metric as a Quality Aware Image Transcoding. In 2nd Usenix Symposium on Internet Technologies and Systems (USITS 99), Oct. 1999, Berkeley, CA, USA, pp.81-92 C. Chassot, K. Drira, K. Guennoun et al.. Towards autonomous management of QoS through model-driven adaptability in communication-centric systems. International Transactions on Systems Science and Applications, 2006, Vol. 2, N 3, pp. 255-264 Tarak CHAARI - 181 - Thèse de doctorat

Bibliographie [Chefrour02] [Chen03] [Chen04] [Clark99] Djalel Chefrour and Françoise André. ACEEL : modèle de composants autoadaptatifs. Application aux environnements mobiles. In Actes du colloque Systèmes à composants adaptables et extensibles, October 2002, Grenoble, France. Chen, H., et al.. An Ontology for Context-Aware Pervasive Computing Environments. In Workshop on Ontologies and Distributed Systems (IJCAI 2003), August 2003, Mexico. Chen, H. An Intelligent Broker Architecture for Pervasive Context-Aware Systems. PhD thesis. Baltimore County : Department of CSEE, University of Maryland, 2004. Clark, J. (ed.): XSL Transformations (XSLT) Version 1.0. World Wide Web Consortium. Boston 1999. Disponible sur : <http://www.w3.org/tr/xslt> (consulté le 01.06.2007) [CORBA02] CORBA overview, Object Management Group. Disponible sur :<http://www.omg.org/corba/> (consulté le 14.03.2002) [Costa03] [David05] [Davies98] [Dey00] Patricia Dockhorn Costa. Towards a services platform for context aware applications. Master thesis. Enschede, The Netherlands : University of Twente, august 2003. Pierre-Charles David and Thomas Ledoux. Une approche par aspects pour le développement de composants Fractal adaptatifs. In 2ème Journée Francophone sur le Développement de Logiciels Par Aspects (JFDLPA05), September 2005, Lille, France (L'objet, Vol. 12, N -23) Davies N., Mitchell, K., Cheverst et al.. Developing a context-sensitive tour guide. In Proceedings of the 1st Workshop on Human Computer Interaction for Mobile Devices, 1998, Glasgow, Scotland. A. K. Dey and G. D. Abowd. Towards a Better Understanding of Context and Context Awareness. In Proceedings of the Workshop on the What, Who, Where, When and How of Context-Awareness, affiliated with the CHI 2000 Conference on Human Factors in Computer Systems, The Hague, Netherlands. New York, NY : ACM Press, 2000. Tarak CHAARI - 182 - Thèse de doctorat

Bibliographie [Dey01a] [Dey01b] [Dey98] [Dey99] [Dourish00] [Dowling01] [Dubois01] [Eclipse06] [Feiner97] Dey, A.. Understanding and Using Context. Personal Ubiquitous Comput, Jan. 2001, Vol. 5, N 1, p. 4-7. DOI= http://dx.doi.org/10.1007/s007790170019 (consulté le 02.07.2007) Anind K. Dey, Daniel Salber and Gregory D. Abowd, A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context- Aware Applications. special issue on context-aware computing in the Human-Computer Interaction (HCI), 2001, Vol. 16, N 2-4, pp. 97-166 Dey A. K., Abowd, G. D. & Wood, A. CyberDesk : A framework for providing self integrating context aware services. Knowledge Based Systems, 1998, Vol.11, N 1, pp. 3-13 K. Dey, Daniel Salber, Masayasu Futakawa and Gregory D.Abowd. An Architecture To Support Context-Aware Applications. GVU Technical Report GIT-GVU-99-23. Submitted to the 12th Annual ACM Symposium on User Interface Software and Technology (UIST 99), June 1999 Dourish P., Edwards, W. K., LaMarca et al.. Extending document management systems with active properties. ACM Transactions on Information Systems, 2000, Vol.18, N 2, p. 140-170. Jim Dowling and Vinny Cahill. The K-Component Architecture Meta-Model for Self-Adaptive Software. In The Third International Conference on Metalevel Architectures and Separation of Crosscutting Concerns, September, Reflection 2001, Kyoto, Japan, p. 81-88 Dubois, E., Nigay, L., Troccaz, J. Consistency in Augmented Reality Systems. Proceedings of EHCI01, IFIP WG2.7 (13.2) Conference, May 2001, Toronto. (LNCS, 2001, Vol.2254, pp.111-122) Eclipse IDE, Disponible sur : < http://www.eclipse.org/> (consulté le 26.12.2006) Feiner S., MacIntyre, B., Hollerer, et al.. A Touring Machine : Prototyping 3D mobile augmented reality systems for exploring the urban environment. Personal Technologies, 1997, Vol. 1, N 4, pp. 208-217 Tarak CHAARI - 183 - Thèse de doctorat

Bibliographie [Fels98] [Fisher97] [Flory04] [Fox98] [Fox98] Fels S., Sumi, Y., Etani et al.. Progress of C-MAP: A context-aware mobile assistant. (1998). In Proceedings of the AAAI 1998 Spring Symposium on Intelligent Environments. Menlo Park, CA : AAAI Press, pp. 60-67 B. Fisher, G. Agelidis, J. Dill et al. CZWeb : Fish-Eye Views for Visualizing the World-Wide Web. In Proc. of the 7th Int. Conf. on Human-Computer Interaction (HCI International 97). Amsterdam : Elsevier, 1997, pp. 719-722 Flory et al, Projet SICOM : Rapport de fin de contrat, "thématiques prioritaires". Région Rhône-Alpes, 2004 A. Fox, I. Goldberg, S. Gribble et al. Experience with TopGun Wingman: A Proxy-Based Web Browser for the 3Com PalmPilot. In Proceedings of the IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing (Middleware 98), Sept. 1998, Lake District, England, pp.407-426 A. Fox, I. Goldberg, S. Gribble et al. Experience with TopGun Wingman: A Proxy-Based Web Browser for the 3Com PalmPilot. In Proceedings of the IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing (Middleware 98), 1998, Lake District, England, pp.407-426 [Granddictionnaire] Office québécois de la langue française. Le grand dictionnaire terminologique [en ligne]. Disponible sur : <http://www.granddictionnaire.com/> (consulté le 01.06.2007) [Gu04] [Hamadi03] [Harrison98] Gu T., Pung H. K., and Zhang D. Q. A middleware for building contextaware mobile services. In Proceedings of IEEE Vehicular Technology Conference (VTC), 2004, Milan, Italy Hamadi, R. and Benatallah, B. 2003. A Petri net-based model for web service composition. In Proceedings of the 14th Australasian Database Conference - Volume 17 (Adelaide, Australia). K. Schewe and X. Zhou, Eds. ACM International Conference Proceeding Series, vol. 143. Australian Computer Society, Darlinghurst, Australia, 191-200 Harrison, B. L., Fishkin, K. P., Gujar et al.. Squeeze me, hold me, tilt me! An exploration of manipulative user interfaces. In Proc. CHI 98, April 18-23, Los Angeles. New York, NY, USA : ACM, 1998, pp.17-24 Tarak CHAARI - 184 - Thèse de doctorat

Bibliographie [Healey98] [Heineman01] [Heiner99] [Held02] [Hillerson 01] Healey J. & Picard, R. W. StartleCam: A cybernetic wearable camera. In Proceedings of the 2nd International Symposium on Wearable Computers (ISWC98), Pittsburgh, Pennsylvania, 19-20 October 1998. Los Alamitos CA : IEEE,1998, p. 42-49 Heineman G. T.& Council W. T.. Component-Based Software Engineering, Putting the Pieces Together. Amsterdam : Addison Weysley, 2001. Heiner J. M., Hudson, S. E. & Tanaka, K. The Information Percolator: Ambient information display in a decorative object. In Proceedings of the 12th Annual ACM Symposium on User Interface Software and Technology (UIST96). New York, NY: ACM Press, 1999. A. Held. Modeling of Context Information for Pervasive Computing Applications. In Proc. 6th World Multiconference on Systemics, Cybernetics and Informatics (SCI2002), 2002, Orlando, FL. Gary Hillerson. Web Clipping Developer's Guide. Santa Clara, Calif. : Palm Inc., May 2001. [Hormonia06] Hormonia, Disponible sur : <http://www.harmonia.com/products/index.php>, (consulté le 26.12.2006) [Horrocks04] I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, and M. Dean. SWRL: A semantic web rule language combining OWL and RuleML. W3C Member Submission, 21 May 2004. [en ligne] http://www.w3.org/submission/2004/subm-swrl-20040521/ [Housel96] [IBM06] [IIHM] B. C. Housel and D. B. Lindquist. WebExpress: A System for Optimizing Web Browsing in a Wireless Environment. In Proceedings of ACM/IEEE of the Second Annual International Conference on Mobile Computing and Networking (MobiCom 96) November 1996, Rye, New York, pp. 108-116 Inc. Internet Transcoding for Universall Access [ en ligne ], September 2000. http://www.research.ibm.com/networked_data_systems/transcoding/index.ht ml, (consulté le 01.06.2007) Équipe Ingénierie de l'interaction Homme-Machine [en ligne]. Disponible sur : <http://iihm.imag.fr> (consulté le 02.07.2007) Tarak CHAARI - 185 - Thèse de doctorat

Bibliographie [Indulska03] Indulska, J. and Sutton, P. Location management in pervasive systems. In CRPITS 03: Proceedings of the Australasian Information Security Workshop, 2003, Adelaide, Australia, p. 143 151 [Indulska03] Indulska, J., Robinson, R., Rakotonirainy, A., and Henricksen, K. 2003. Experiences in Using CC/PP in Context-Aware Systems. In Proceedings of the 4th international Conference on Mobile Data Management, January 21-24, 2003, Melbourne, Australia. (Lecture Notes In Computer Science, 2003, Vol. 2574, pp.247-261) [Ishii97] [Janssen93] Ishii H. & Ullmer, B. Tangible Bits: Towards seamless interfaces between people, bits and atoms. In Proceedings of the CHI 97 Conference on Human Factors in Computing Systems. New York, NY: ACM Press, 1997, pp. 234-241 C. Janssen, A. Weisbecker, J. Ziegler. Generating User Interfaces from Data Models and Dialogue Net Specifications. In Proceedings InterCHI93, Amsterdam, April 1993. New York : ACM Press, 1993, pp. 418-423 [JBuilder06] Borland JBuilder. Disponible sur : <http://www.borland.com/fr/products/jbuilder> (consulté le 26.12.2006) [Johnson03] [Keeney03] [Ketfi02] [Kiciman00] Johnson, B., Skibo, C., Young, M., Inside Microsoft Visual Studio.NET. Washington : Microsoft Press, 2003. J.Keeney, V.Cahill. Chisel: A Policy-Driven, Context-Aware, Dynamic Adaptation Framework. Proceedings of the Fourth IEEE International Workshop on Policies for Distributed Systems and Networks POLICY 2003, Italy, 2003 Ketfi, A. and Belkhatir, N. and Cunin, P. Y.. Adaptation Dynamique, concepts et expérimentations. In Proceedings of the 15th International Conference on Software & Systems Engineering and their Applications ICSSEA02, December 2002, Paris, France, 8 p. Kiciman E. & Fox, A. Using dynamic mediation to integrate COTS entities in a ubiquitous computing environment. In Proceedings of the 2nd International Symposium on Handheld and Ubiquitious Computing (HUC2K). Heidelberg, Germany : Springer Verlag, 2000. Tarak CHAARI - 186 - Thèse de doctorat

Bibliographie [Kiczales01] [Kickzales97] [Kim03] [Korpipaa04] [Krasner88] [Lamming94] [Lassila99] [Layaïda99] [Lee03] [Lei01] G. Kiczales, E. Hilsdale, J. Hugunin et al. Getting started with ASPECTJ. Communications of the ACM, vol. 44, no. 10, pages 59-65, 2001 G. Kickzales, J. Lamping, A. Mendhekar et al. Aspect-Oriented Programming. Proceedings of the ECOOP'97 Conference, LNCS 1241, Finland, 220-242, 1997 J.-G. Kim, Y. Wang, and S.-F. Chang. Content-adaptive utility-based video adaptation. In Proc. of IEEE Int'l Conference on Multimedia & Expo, July 2003, pp. 281-284 Korpipaa, P., Mantyjarvi, J., Kela, J. et al.. Managing context information in mobile devices. IEEE Pervasive Computing, November/December 2004, Vol. 19, N 6, pp. 21-29 G. Krasner and S. Pope, A cookbook for using the model-view controller user interface paradigm in Smalltalk-80, Journal of Object-Oriented Programming, August /September 19881, Vol. 3, pp.26-49. Lamming M. & Flynn, M. Forget-me-not: Intimate computing in support of human memory. Proceedings of the FRIEND 21: International Symposium on Next Generation Human Interfaces, 1994, Tokyo, pp.125-128 O. Lassila and R. R. Swick. Resource description framework (rdf) model and syntax specification. W3C Recommendation 22, February 1999. N. Layaïda, Adaptabilité. Pistes d'étude pour la définition d'une infrastructure d'accès au contenu multimédia pour des machines hétérogènes. Rapport Technique. Grenoble : INRIA Rhône-Alpes, octobre 1999 D. G. Lee, D. Panigrahi, and S. Dey. Network-Aware Image Data Shaping for Low-Latency and Energy-Efficient Data Services over the Palm Wireless Network. In Proc. of World Wireless Congress (3G Wireless Conference), May 2003, San Francisco. Z. Lei and N.D. Georganas. Context-based Media Adaptation in Pervasive Computing. In Proc. of Canadian Conference on Electrical and Computer Engineering (CCECE), May 2001, Toronto Tarak CHAARI - 187 - Thèse de doctorat

Bibliographie [Lemlouma01] [Lemlouma02] [Libsie04] [Liljeberg95] [Linnhoff 04] [Maes87] [Margaritidis01] [Marmasse00] [Marriott02] T. Lemlouma, N. Layaïda. A Framework for Media Resource Manipulation in an Adaptation and Negotiation Architecture. OPERA project. Grenoble : INRIA Rhône-Alpes, august 2001. T. Lemlouma, N. Layaďda. Content Adaptation and Generation Principles for Heterogeneous Clients. In W3C Workshop on Device Independent Authoring Techniques, September 2002, St. Leon-Rot, Germany M. Libsie. Metadata Supported Content Adaptation in Distributed Multimedia Systems. PhD thesis. Austria : University Klagenfurt, defended on June 2004 M. Liljeberg, T. Alanko, M. Kojo et al. Optimizing World-Wide Web for Weakly Connected Mobile Workstations: An Indirect Approach. In Proc. 2nd International Workshop on Services in Distributed and Networked Environments (SDNE95), June 5th - 6th, 1995, Whistler, Canada. Strang and Claudia Linnhoff-Popien: A context modeling survey. In UbiComp 1st International Workshop on Advanced Context Modelling, Reasoning and Management, 2004, Nottingham, pp. 34-41 P. Maes. Concepts and experiments in computational reflection. In Conference Proceedings on Object-Oriented Programming Systems, Languages and Applications (Orlando, Florida, United States, October 04-08, 1987). N. Meyrowitz, Ed. OOPSLA '87. ACM Press, New York, NY, 147-155, 1987 M. Margaritidis and G.C. Polyzos. Adaptation Techniques for Ubiquitous Internet Multimedia. Wireless Communications and Mobile Computing, 2001, Vol. 1, N 2, pp. 141-164 Marmasse N. & Schmandt, C. Location aware information delivery with commotion. In Proceedings of the 2nd International Symposium on Handheld and Ubiquitous Computing (HUC2K). Heidelberg, Germany : Springer Verlag, 2000. K. Marriott, B. Meyer, and L. Tardif. Fast and Efficient client-side Adaptivity for SVG. In Proc. of WWW 2002Honolulu, Hawaii, USA, May 2002. New York : ACM Press, 2002, pp. 496 507 Tarak CHAARI - 188 - Thèse de doctorat

Bibliographie [Märtin96] [Matthias07] [May05] [McCarthy00] [McCarthy99] [Menkhaus02] [Merrick2004] [Mogul01] [Mohan99] C. Märtin. Software Life Cycle Automation for Interactive Applications: The AME Design Environment. In J. Vanderdonckt (ed.): Computer-Aided Design of User Interfaces. Namur: Namur University Press, 1996, pp. 57-74 Matthias Baldauf and Schahram Dustdar. A survey on context-aware systems. International Journal of Ad Hoc and Ubiquitous Computing, forthcoming, 2007, Vol.2, N 4, pp. 263-277. W. May, J. Alferes, R. Amador. Active rules in the SemanticWeb: Dealing with language heterogeneity. In Proceedings of International Conference on Rules and Rule Markup Languages for the Semantic Web (RuleML-2005), Galway, Ireland (10th - 12th November 2005), LNCS 3791, 30-44, 2005 McCarthy J. F. & Anagost, T. D. EventManager: Support for the peripheral awareness of events. In Proceedings of the 2nd International Symposium on Handheld and Ubiquitious Computing (HUC2K). Heidelberg, Germany: Springer Verlag, 2000. McCarthy J. F. & Meidel, E. S. ActiveMap: A visualization tool for location awareness to support informal interactions. In Proceedings of the 1st International Symposium on Handheld and Ubiquitous Computing (HUC 99). Heidelberg, Germany: Springer Verlag, 1999. G. Menkhaus. Adaptive User Interface Generation in a Mobile Computing Environment. PhD Thesis. Austria : Salzburg University, 2002. Roland Merrick, Brian Wood, William Krebs, ABSTRACT USER INTERFACE MARKUP LANGUAGE, In Kris Luyten, Marc Abrams, Jean Vanderdonckt, Quentin Limbourg (ED.), Proceedings of the Workshop on Developing User Interfaces with XML: Advances on User Interface Description Languages, May 2004, Gallipoli, Italy. J.C. Mogul. Server-Directed Transcoding. Computer Communications, Feb. 2001, Vol. 24, N 2, p. 155-162 R. Mohan, J.R. Smith and C.S. Li. Adapting Multimedia Internet Content for Universal Access. IEEE Trans. on Multimedia, 1999, Vol. 1, N 1, p. 104-114 Tarak CHAARI - 189 - Thèse de doctorat

Bibliographie [Mynatt98] Mynatt E. D., Back, M., Want, R., et al. Designing Audio Aura. In Proceedings of the CHI 98 Conference on Human Factors in Computing Systems.New York, NY: ACM Press, 1998, pp. 566-573 [Nagao01] K. Nagao, Y. Shirai, and K. Squire. Semantic annotation and transcoding : Making web content more accessible. IEEE Multimedia, April-June 2001, pp. 69-81 [Noble00] [Noble97] B. Noble. System Support for Mobile, Adaptive Applications. IEEE Personal Communications, February 2000, Vol. 7, N 1, pp. 44-49 B.D. Noble, M. Satyanarayanan, D. Narayanana et al. Agile application aware adaptation for mobility. In Proceedings of the 16th ACM Symposium on Operating Systems Principles, December 1997, Vol.31, N 5, pp. 276-287 [Objectweb04] ObjectWeb. (2004, Octobre) Objectweb ambition and scope, http://consortium.objectweb.org/ (consulté le 02.07.2007) [OSGi03] [Pascoe98] [Pascoe98] [Pawlak01] [Pinheiro00] OSGi Alliance, OSGi Service Platform, Release 3. Amsterdam : IOS Press, Inc., 2003. J. Pascoe. Adding generic contextual capabilities to wearable computers. In Proceedings of 2 nd International Symposium on Wearable Computers, October 1998, pp. 92-99 Pascoe J. Adding generic contextual capabilities to wearable computers. In Proceedings of the 2nd International Symposium on Wearable Computers (ISWC98). Los Alamitos CA : IEEE, 1998, 92-99 R. Pawlak, L. Seinturier, L. Duchien et al. JAC: A Flexible Solution for Aspect-Oriented Programming in Java. Proceedings of Reflection'01, volume 2192 de Lecture Notes in Computer Science, pages 1-24. Springer, 2001 P. Pinheiro da Silva and N. W. Paton. UMLi: The Unied Modeling Language for Interactive Applications. In Proceedings of UML2000, York, UK, October 2000. (LNCS, 2000, Vol. 1939, pp. 117-132) Tarak CHAARI - 190 - Thèse de doctorat

Bibliographie [Puerta02] [Puerta96] [Raj99] [Rekimoto99] [Rhodes97] [Riveill00] [Rodden98] [Rodriguez01] [Roman02] Puerta, A. and Eisenstein, J. 2002. XIML: a common representation for interaction data. In Proceedings of the 7th international Conference on intelligent User interfaces (San Francisco, California, USA, January 13-16, 2002). IUI 02. New York, NY : ACM Press, pp. 214-215. A. Puerta. Issues in Automatic Generation of User Interfaces in Model- Based Systems. 1996. In J. Vanderdonckt (ed.): Computer-Aided Design of User Interfaces. Namur: Namur University Press, p. 323-325 G. S. Raj. (1999, Octobre) The CORBA Component Model (CCM), http://my.execpc.com/ gopalan/corba/ccm.html (consulté le 02.07.2007) Rekimoto J. Time-Machine Computing : A time-centric approach for the information environment. In Proceedings of the 12th Annual ACM Symposium on User Interface Software and Technology (UIST99), Asheville, USA. New York : ACM Press, 1999, p.45-54 Rhodes B. J. The wearable remembrance agent. Los Alamitos. In Proceedings of the 1st International Symposium on Wearable Computers (ISWC97), October 13-14, 1997, Cambridge, Massachusetts. Los Alamitos, Calif. : IEEE Press, 1997, 123-128 Riveill M.et Merle P. Programmation par composants. Rapport Technique numéro H 2 759, Techniques de l'ingénieur, traité Informatique, novembre 2000. Rodden T., Cheverst, K., Davies, K. & Dix, A. Exploiting context in HCI design for mobile systems. In Proceedings of the Workshop on Human Computer Interaction with Mobile Devices, 1998, Glasgow, Scotland J. Rodriguez, B. Dakar, F. L. Marras, et al. Transcoding in WebSphere Everyplace Suite. Chapter 11. In: New Capabilities in IBM WebSphere Transcoding Publisher Version 3.5 Extending Web Applications to the Pervasive World. New York : IBM Redbooks, 30 May 2001, 446 p. ISBN 0738421545 E. Roman, S. Ambler, and T. Jewell. Mastering Enterprise JavaBeans. 2nd ed. New York : John Wiley and Sons, Inc, 2002, 639 p. Tarak CHAARI - 191 - Thèse de doctorat

Bibliographie [Ryan98] [Satyanarayanan01] [Schilit94] [Schilit94a] [Schilit94b] [Scribner00] [Shanableh00] [Shanon90] [Singh04] [Smith98] N. S. Ryan, J. Pascoe,and D.R. Morse. Enhanced reality fieldwork : the context-aware archaeological assistant. In V.Gaffney, M. van Leusen, and S. Exxon, editors, Computer Applications in Archaeology 1997. Oxford : Tempus Reparatum,, Oct. 1998. (British Archaeological Reports) M. Satyanarayanan. Pervasive Computing : Vision and challenge. IEEE Personnal Communications, August 2001, Vol.8, N 4, pp. 10-17 Schilit B., Adams, N. & Want, R. Context-aware computing applications. In Proceedings of the 1st International Workshop on Mobile Computing Systems and Applications. Los Alamitos, CA : IEEE. 1994, pp. 85-90 B.N. Schilit, M. Theimer. Disseminating Active Map Information to Mobile Hosts. Network, IEEE, September/October 1994, Vol.8, N 5, pp. 22-32. B.N. Schilit, N.I. Adams and R. Want. Context-Aware Computing Applications. In Proceedings of the IEEE Workshop on Mobile Computing Systems and Applications (WMCSA94), Santa Cruz CA, December 1994. Los Alamitos, CA : IEEE computer society press, 1995, pp 85-90 Scribner, K., Scribner, K., and Stiver, M. C. Understanding Soap: Simple Object Access Protocol. Indianapolis, Ind. : Sams, 2000, 514 p. T. Shanableh and M. Ghanbari. Heterogeneous video transcoding to lower spatio-temporal resolutions and different encoding formats. IEEE Trans. Multimedia, June 2000, Vol.2, pp. 101-110 Shanon, B. What is Context?, Journal for the Theory of Social Behavior 1990, Vol.20, pp. 157 166 A. Singh, A. Trivedi, K. Ramamritham, and P. Shenoy. PTC : Proxies that Transcode and Cache in Heterogeneous Web Client Environments. World Wide Web Journal, 2004, Vol.7, N 1, pp. 7-28. J.R Smith, R.Mohan, C.S. Li. Transcoding Internet Content for Heterogenouse Client Devices. Proceeedings IEEE International Symposium on Circuits and Systems (ISCAS), Special session on Next Generation Internet, June 1998, Monteret, California Tarak CHAARI - 192 - Thèse de doctorat

Bibliographie [Sloman94] [Strang03] [Sukaviriya93] M. Sloman. Policy driven management for distributed systems. Journal of Network and Systems Management, 2:333 360, 1994 Strang, T., et al.. Service Interoperability on Context Level in Ubiquitous Computing Environments. International Conference on Advances in Infrastructure for Electronic Business, Education, Science, Medicine, and Mobile Technologies on the Internet (SSGRR2003w), January 2003, L'Aquila/Italy P. Sukaviriya, J. Foley, T. Griffith. A Second Generation User Interface Design Environment. In S. Ashlund, et.al. (eds.): Bridges between Worlds. Proceedings InterCHI93, 1993, Amsterdam. New York : ACM Press, April 1993, p. 375-382 [Sun00] Sun Microsystems, Inc., Personal Java Application Environment Specification, Version 1.2a (Final), November 2000. [Sun07a] [Sun07b] [Szyperski02] Sun Developer Network (SDN) [en ligne]. Java 2 Platform, Standard Edition (J2SE). Inc. http: //java.sun.com/j2se (consulté le 01.06.2007) Mobile Information Device Profile (JSR 37) [en ligne], Java Community Process, Java 2 Platform Micro Edition, Sun Microsystems. Disponible sur le <http://java.sun.com/products/midp/> (consulté le 01.06.2007) Szyperski C. Component Software Beyond Object-Oriented Programming. Second Edition. London : Addison-Wesley / ACM Press, 2002, 589 p. [Szyperski97] Clements Szyperski. Component Software. New York : ACM Press, 1997, 411 p [UDDI07] UDDI, Advancing Web Services Discovery Standard. Disponible sur : <http://www.uddi.org/> (consulté le 01.06.2007) [UserLand99] UserLand Software. XML-RPC Specification, 1999. http://www.xmlrpc.com/spec (consulté le 02.07.2007) [Vetro02] A. Vetro, Y. Wang, and H. Sun. Rate-distortion optimized video coding considering frameskip. In Proc. IEEE Int'l Conference on Image Processing (ICIP2001), vol.3, Oct. 2001, Thessaloniki, Greece, pp.534-537 Tarak CHAARI - 193 - Thèse de doctorat

Bibliographie [W3C04] [Want92] W3C Recommandation. Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0, Janvier 2004 [en ligne]. Disponible sur : <http://www.w3.org/tr/2004/rec-ccpp-struct-vocab-20040115> (consulté le 01.06.2007) Want, R., Hopper, A., Falc ao, V., et al. The Active Badge Location System. ACM Transactions on Information Systems, 1992, Vol.10, N 1, pp. 91-102 [Wapforum] Open Mobile Alliance [en ligne]. Disponible sur : <http://www.wapforum.org> (consulté le 01.06.2007) [Ward97] [Wee 03] [Weiser95] [Weiser97] [Weiser99] [Widom96] [Wies95] Ward, A. Jones, A. Hopper. A New Location Technique for the Active Office. IEEE personnal Communications, 1997, Vol. 4, N 5, pp. 42-47 S. Wee and J. Apostolopoulos. Secure scalable streaming and secure transcoding with JPEG-2000. IEEE International Conference on Image Processing, September 2003, Barcelona, Spain. Weiser, M. 1995. The computer for the 21st century. In Human-Computer interaction: Toward the Year 2000, R. M. Baecker, J. Grudin, W. A. Buxton, and S. Greenberg, Eds. San Francisco, CA : Morgan Kaufmann Publishers, pp. 933-940 Weiser M. & Brown, J. S. The coming age of calm technology. In Denning, P. J. & Metcalfe, R. M. (Eds.) Beyond Calculation: The Next Fifty Years of Computing. New York : Springer Verlag, 1997. Weiser, M. 1999. Some computer science issues in ubiquitous computing. In Mobility: Processes, Computers, and Agents. New York, NY : ACM Press/Addison-Wesley Publishing Co., pp. 420-430 J. Widom, S. Ceri, editors. Active Database Systems Triggers and Rules For Advanced Database Processing. Morgan Kaufmann Publishers, 1996, 332p R. Wies, Using a Classification of Management Policies for Policy Specification and Policy Transformation. In Proceedings of the Fourth international Symposium on integrated Network Management IV A. S. Sethi, Y. Raynaud, and F. Faure-Vincent, Eds. Chapman & Hall Ltd., London, UK, 44-56, 1995 Tarak CHAARI - 194 - Thèse de doctorat

Bibliographie [Winograd01] [Yarvis01] [Yoshikawa97] [Zouari07] Winograd, Terry. Architectures for Context. Human-Computer Interaction Journal, 2001, Vol. 6, N 2-3, pp. 401-419. M. Yarvis. Conductor: Distributed Adaptation for Heterogeneous Networks. Ph.D. Dissertation. Los Angeles, CA : UCLA Department of Computer Science, November 2001. C. Yoshikawa, B. Chun, P. Eastham et al. Using smart clients to build scalable services. Proc. Winter 1997 USENIX Technical Conf, January 6-10, 1997, Anaheim, California, USA. M. Zouari, Politique d adaptation d applications dans les systèmes pervasifs : rapport de master de recherche. Lyon : INSA de Lyon, 2007, 30 p. Tarak CHAARI - 195 - Thèse de doctorat

ANNEXES

Annexes ANNEXE A MODELE FONCTIONNEL DE L APPLICATION SICOM <?xml version="1.0" encoding="iso-8859-1"?> <application name="sicom"> <!-- Last modified : 2007/05/19 11:20 --> <!-- A place (representing a service) is described by its service id, url and method. For every method, we specify its input and output parameters --> <place id="authentication"> <url>http://127.0.0.1/xmlrpc</url> <method id="sicom.identification"> <description>this method verifies the login and the password of a sicom user and returns its userid and username in the sicom database</description> <input name="sicom.login" type="secas:string" mode="user"/> <input name="sicom.password" type="secas:string" mode="user"/> <output name="sicom.userid" type="secas:int"/> <output name="sicom.username" type="secas:string"/> <output name="sicom.userfirstname" type="secas:string"/> </method> </place> <place id="listealertes"> <url>http://127.0.0.1/xmlrpc</url> <method id="sicom.listealertes"> <description>this method returns the list of alerts identified by "sicom.userid"</description> <input name="sicom.userid" type="secas:int" mode="application"/> <output name="sicom.general.idalerte" type="secas:int"/> <output name="sicom.general.iddossier" type="secas:int"/> <output name="sicom.general.date" type="secas:date"/> <output name="sicom.general.libelle" type ="secas:string"/> <output name="sicom.general.nom" type ="secas:string"/> </method> </place> <place id="descriptionalerte"> <url>http://127.0.0.1/xmlrpc</url> <method id="sicom.descriptionalerte"> <description>this method returns the list of the dialyzed patients treated by the practionner identified by "sicom.userid"</description> <input name="sicom.general.idalerte" type="secas:int" mode="application"/> <output name="sicom.general.descriptionalerte" type="secas:string"/> Tarak CHAARI - 198 - Thèse de doctorat

Annexes </method> </place> <place id="listedossierdialyse"> <url>http://127.0.0.1/xmlrpc</url> <method id="sicom.listedossierdialyse"> <description>this method returns the list of the dialyzed patients treated by the practionner identified by "sicom.userid"</description> <input name="sicom.general.iddossier" type="secas:int" mode="application"/> <output name="sicom.general.iddossier" type="secas:int"/> <output name="sicom.general.typedialyse" type="secas:string"/> <output name="sicom.general.modedialyse" type="secas:string"/> <output name="sicom.general.datecreation" type="secas:date"/> <output name="sicom.general.datemodification" type="secas:date"/> <output name="sicom.general.nom" type ="secas:string"/> <output name="sicom.general.prenom" type ="secas:string"/> </method> </place> <place id="valeurstemperature"> <url>http://127.0.0.1/xmlrpc</url> <method id="sicom.valeurstemperature"> <description>this method returns the list of the dialyzed patients treated by the practionner identified by "sicom.userid"</description> <input name="sicom.general.iddossier" type="secas:int" mode="application"/> <output name="sicom.general.abscisses" type="secas:date"/> <output name="sicom.general.ordonnées" type="secas:int"/> </method> </place> <place id="listeimages"> <url>http://127.0.0.1/xmlrpc</url> <method id="sicom.listeimages"> <description>this method returns the list of the dialyzed patients treated by the practionner identified by "sicom.userid"</description> <input name="sicom.general.iddossier" type="secas:int" mode="application"/> <output name="sicom.general.nomimage" type ="secas:string"/> <output name="sicom.general.urlimage" type ="secas:image"/> <output name="sicom.general.descriptionimage" type ="secas:string"/> <output name="sicom.general.binaireimage" type ="secas:dicom"/> </method> </place> <!-- A transition specifies at least one association between a source service and a destination service. If a service depends on n services there will be n associations in the transition. For each association we indicate its source Parameters (parameters that we gather from a source service) and its destination parameters (parameters that will be some entries for the destination service). We specify a maximum delay in seconds to the execution of all the source services of all the associations of the transition. A transition can have a condition for every entry service. The condition is represented by a logical expression involving the output parameters of the concerned entry service. --> <transition delay="100"> Tarak CHAARI - 199 - Thèse de doctorat

Annexes <generalcondition> <expression value="true"/> </generalcondition> <association sourceservice="authentication" destinationservice="listealertes"> <sourceparameter methodid="sicom.identification" inputexpression="sicom.userid" condition="sicom.userid is not null"/> <destinationparameter methodid="sicom.listealertes" parametername="sicom.userid"/> </association> </transition> <transition delay="100"> <generalcondition> <expression value="true"/> </generalcondition> <association sourceservice="listealertes" destinationservice="listedossierdialyse"> <sourceparameter methodid="sicom.identification" inputexpression="sicom.general.iddossier" condition="sicom.general.iddossier is not null"/> <destinationparameter methodid="sicom.listedossierdialyse" parametername="sicom.general.iddossier"/> </association> </transition> <transition delay="100"> <generalcondition> <expression value="true"/> </generalcondition> <association sourceservice="listealertes" destinationservice="descriptionalerte"> <sourceparameter methodid="sicom.listealertes" inputexpression="sicom.general.idalerte" condition="sicom.general.idalerte is not null"/> <destinationparameter methodid="sicom.descriptionalerte" parametername="sicom.general.idalerte"/> </association> </transition> <transition delay="100"> <generalcondition> <expression value="true"/> </generalcondition> <association sourceservice="listedossierdialyse" destinationservice="listeimages"> <sourceparameter methodid="sicom.listedossierdialyse" inputexpression="sicom.general.iddossier" condition="sicom.general.iddossier is not null"/> <destinationparameter methodid="sicom.listeimages" parametername="sicom.general.iddossier"/> </association> </transition> <transition delay="100"> <generalcondition> <expression value="true"/> </generalcondition> Tarak CHAARI - 200 - Thèse de doctorat

Annexes <association sourceservice="listedossierdialyse" destinationservice="valeurstemperature"> <sourceparameter methodid="sicom.listedossierdialyse" inputexpression="sicom.general.iddossier" condition="sicom.general.iddossier is not null"/> <destinationparameter methodid="sicom.valeurstemperature" parametername="sicom.general.iddossier"/> </association> </transition> </application> Tarak CHAARI - 201 - Thèse de doctorat

Annexes ANNEXE B REGLES D ADAPTATION UTILISEES POUR L APPLICATION SICOM <?xml version="1.0" encoding="utf-8"?> <!-- Last modified : 2007/05/19 17:30 --> <rules> <rule ID="1" mode="simple"> <expressions> <expression operator="inferior"> <parameter type="context" name="context.terminal.hardwareplatform.totalmemory" value="10240"/> </expression> <expression operator="exist"> <parameter type="secas:servicedescriptor" alias="s"> <expression operator="superior"> <parameter type="int" name="s.output.length" value="1"/> </expression> </parameter> </expression> </expressions> <actions> <action type="saaction" output="firstvalues"> <operator name="projection"> <parameter name="service" type="secas:servicedescriptor">s</parameter> <parameter name="outputparameter" type="secas:serviceoutput">s.output[0]</parameter> </operator> </action> <action type="saaction" output="selectedinstance"> <operator name="selection"> <parameter name="service" type="secas:servicedescriptor">s</parameter> <parameter name="criteria" type="secas:booleanexpression"> <expression operator="equal"> <parameter type="secas:serviceoutput" name="s.output[0]" value="selected(firstvalues.output[0])"/> </expression> </parameter> </operator> </action> <action type="faaction"> <operator name="replaceservice"> <parameter name="referenceservice" type="secas:servicedescriptor">s</parameter> <parameter name="servicetoreplace" type="secas:servicedescriptor">firstvalues</parameter> <parameter name="mode" type="string">simple</parameter> </operator> </action> Tarak CHAARI - 202 - Thèse de doctorat

Annexes <action type="faaction"> <operator name="insertserviceafter"> <parameter name="referenceservice" type="secas:servicedescriptor">firstvalues</parameter> <parameter name="servicetoinsert" type="secas:servicedescriptor">selectedinstance</parameter> </operator> </action> </actions> </rule> <rule ID="2" mode="recursive"> <expressions> <expression operator="equal"> <parameter type="context" name="context.terminal.softwareplatform.accepteddatatypes.acceptimages" value="true"/> </expression> <expression operator="equal"> <parameter type="context" name="context.terminal.type" value="cldc"/> </expression> <expression operator="exist"> <parameter type="secas:servicedescriptor" alias="s"> <expression operator="superior"> <parameter type="int" name="s.output.length" value="1"/> </expression> <expression operator="exist"> <parameter type="int" alias="i"> <expression operator="exist"> <parameter type="string" name="s.output[i].type" value="secas:binaryimage"/> </expression> </parameter> </expression> </parameter> </expression> </expressions> <actions> <action type="saaction" output="displaynonimage"> <operator name="projection"> <parameter name="service" type="secas:servicedescriptor">s</parameter> <parameter name="outputparameter" type="secas:serviceoutput">not(s.output[i])</parameter> </operator> </action> <action type="saaction" output="displayimage"> <operator name="projection"> <parameter name="service" type="secas:servicedescriptor">s</parameter> <parameter name="outputparameter" type="secas:serviceoutput">s.output[i]</parameter> </operator> </action> <action type="faaction"> Tarak CHAARI - 203 - Thèse de doctorat

Annexes <operator name="replaceservice"> <parameter name="referenceservice" type="secas:servicedescriptor">s</parameter> <parameter name="servicetoinsert" type="secas:servicedescriptor">displaynonimage</parameter> <parameter name="mode" type="secas:string">simple</parameter> </operator> </action> <action type="faaction"> <operator name="insertalternativeservice"> <parameter name="referenceservice" type="secas:servicedescriptor">displaynonimage</parameter> <parameter name="servicetoinsert" type="secas:servicedescriptor">displayimage</parameter> </operator> </action> </actions> </rule> </rules> Tarak CHAARI - 204 - Thèse de doctorat

Annexes ANNEXE C DESCRIPTION D UN CONTEXTE D UTILISATION DE L APPLICATION SICOM AVEC UN TELEPHONE MOBILE DE TYPE NOKIA 6230 <?xml version="1.0" encoding="utf-8"?> <contextprofile ID="U17T355008002783631"> <contextfacet name="terminal"> <contextparameter name="type" type="static">cldc</contextparameter> <contextparameter name="model" type="static">nokia6230</contextparameter> <contextparameter name="serialnumber" type="static">355008002783631</contextparameter> <contextcategory name="hardwareplatform"> <contextparameter name="totalmemory" type="static">6114</contextparameter> <contextparameter name="availablememory" type="dynamic">4322</contextparameter> <contextcategory name="screensize"> <contextparameter name="width" type="static">128</contextparameter> <contextparameter name="height" type="static">128</contextparameter> </contextcategory> </contextcategory> <contextcategory name="softwareplatform"> <contextcategory name="accepteddatatypes"> <contextparameter name="acceptimages" type="static">true</contextparameter> <contextparameter name="images" type="static">png, bmp</contextparameter> <contextparameter name="text" type="static">plain, String, html</contextparameter> <contextparameter name="nuemric" type="static">int, short, long</contextparameter> <contextparameter name="videos" type="static">3gp</contextparameter> <contextparameter name="applications" type="static">vnd.nokia.ringing-tone</contextparameter> <contextparameter name="audio" type="static">wav, midi, mp3, 3gp</contextParameter> <contextparameter name="other" type="static">date</contextparameter> </contextcategory> <contextcategory name="api"> <contextparameter name="virtualmachine" type="static">monty 1.0 VM</contextParameter> <contextparameter name="userinterfacevocabulary" type="static"> http://liris-7024.insa-lyon.fr/midpuilibrary.xml</contextparameter> <contextparameter name="serviceinvocationdescriptor" type="static"> http://liris-7024.insa-lyon.fr/midpserviceinvocation.xml</contextparameter> </contextcategory> </contextcategory> </contextfacet> <contextfacet name="network"> <contextparameter name="connectiontype" typse="static">gprs</contextparameter> <contextparameter name="bandwidth" type="static">236.8</contextparameter> Tarak CHAARI - 205 - Thèse de doctorat

Annexes <contextparameter name="delay" type="static">135</contextparameter> <contextparameter name="connectionstate" type="dynamic">connected</contextparameter> </contextfacet> <contextfacet name="userprofile"> <contextcategory name="basicinformation"> <contextparameter name="userid" type="static">17</contextparameter> <contextparameter name="generaldomain" type="static">medical</contextparameter> <contextparameter name="specificdomain" type="static">nephrology</contextparameter> <contextparameter name="profession" type="static">specialist</contextparameter> </contextcategory> <contextcategory name="preferences"> <contextparameter name="language" type="dynamic">fr</contextparameter> <contextcategory name="display"> <contextparameter name="numericvalues" type="static">curves</contextparameter> <contextparameter name="images" type="static">fullscreen</contextparameter> </contextcategory> </contextcategory> </contextfacet> <contextfacet name="location"> <contextcategory name="pysical"> <contextparameter name="country" type="dynamic">france</contextparameter> <contextparameter name="city" type="dynamic">villeurbanne</contextparameter> <contextparameter name="zipcode" type="dynamic">69100</contextparameter> <contextparameter name="streetname" type="dynamic">jean Capelle</contextParameter> <contextparameter name="streetnumber" type="dynamic">7</contextparameter> <contextparameter name="building" type="dynamic">501</contextparameter> <contextparameter name="room" type="dynamic">330</contextparameter> </contextcategory> <contextcategory name="logical"> <contextparameter name="ipadress" type="static">134.214.107.20</contextparameter> </contextcategory> </contextfacet> </contextprofile> Tarak CHAARI - 206 - Thèse de doctorat

Annexes ANNEXE D ALGORITHME DE GENERATION DU GRAPHE D ADAPTATION DE CONTENU MULTIMEDIA DE GIRMA BERHE [BERHE05] Algorithm: graph (SA, SZ, T, D) Input: Initial state SA, final state SZ, adaptation task list T and adaptation operators D Output: an adaptation graph G (V, E) // Global constant // Limit maximum number of neutral operators allowed in a connection // Global variables // V a set of nodes in a graph // E a set of edges in a graph // ao start node // zo end node // NO a set of neutral operators available in the system // Local variables // T a set of adaptation tasks // t an adaptation task element of T // O a set of nodes for adaptation operators realizing an adaptation task // PO a set of parent nodes // Pz a set containing the end node var V, E, T, t, O, PO, ao, zo, Pz, NO begin ao= ConstructStartNode(SA) // constructs the start node from the initial state zo= ConstructEndNode(SZ) // constructs the end node from the goal state NO= ConstructNeutralOperators( ) // returns the list of the neutral operators available in //the system V= {ao} //initialization E= Ø //initialization PO= {ao}//initialization for each t T begin Construct nodes O from D with operators realizing t //several operators can realize a task Connect(O, PO) //after the process PO holds the value of O end //T is processed Pz={zo} Connect(Pz, PO) // connects the end node return G (V, E) end // graph Tarak CHAARI - 207 - Thèse de doctorat

Annexes ----------------------------------------------------------------------------------------------------------------- // procedure Connect: connects child nodes (O) with parent nodes (PO) // O a set of nodes-input variable // PO a set of nodes-input and output variable ----------------------------------------------------------------------------------------------------------------- procedure Connect(in O, inout PO) //Local variables // CO a set of nodes-temporal variable used to store child nodes (O) // TPO a set of nodes-temporal variable used to store parent nodes (PO) // CPO a set of nodes-temporal variable used to store connected parent nodes // po a node in PO // o a node in O // UNO a set of operators-variable to store already used neutral operators // Link a Boolean variable to check if a node has a connection // Connected a Boolean variable, true if a node is connected by neutral operator // LimitC an integer- number of neutral operators in a connection //Notations // po.pre preconditions of node po // po.eff effects of node po // o.pre preconditions of node o // o.eff effects of node o var CO, TPO, CPO, UNO, o, po, LimitC, Link, Connected begin CO= Ø //initialization CPO= Ø //initialization Link = false // connect each o O with each node of the parent nodes PO for each o O begin for each po PO begin if (o.pre po. Eff) then // direct connection of node o with node po begin if(o V) then begin V= V {o} end E= E {(po, o)} Link = true // o is connected in the graph end else // for indirect connection of node o with po using neutral operators begin Tarak CHAARI - 208 - Thèse de doctorat

Annexes LimitC=0 UNO= Ø Connected=ConnectWithNeutralOperators (o, po, LimitC, UNO) Link=Link or Connected // Link is true if o has at least one connection // if po is connected add it to the connected parent nodes list if (Connected) then CPO=CPO end {po} end // PO is processed if (not Link) then // checks if o has at least one direct or indirect connection begin if(o=zo) then // it is the end node so the graph construction fails begin V= Ø E= Ø return end else O=O-{o}// o can not be connected so remove it end end // O is processed // remove parent nodes which have no connection for each po PO begin if (po CPO ) then begin V=V-{po} for each (x, po) E begin E=E-{(x, po)} Remove(x) // removes x with its ancestors end end end PO= O //child nodes become parent nodes for the next process end // end connect procedure ----------------------------------------------------------------------------------------------------------------- // function ConnectWithNeutralOperators it connects o and op using neutral operators //recursively // o a node- input variable // op a node- input variable //LimitC an integer- input variable // UNO a set of nodes- input and output variable ----------------------------------------------------------------------------------------------------------------- function Boolean ConnectWithNeutralOperators (in o, in op, in LimitC, inout UNO) Tarak CHAARI - 209 - Thèse de doctorat

Annexes //Local variables // TNO a set of operators-a temporal variable for neutral operators // TE a set of edges-a temporal variable to store connectable edges // TV a set of nodes-a temporal variable to store connectable nodes // no a node var TNO, TE, TV, no begin TNO=NeutralOperators(o, UNO)// it returns neutral operators connectable with o for each no TNO begin if (no.pre op.eff) then begin TE= TE {(op, no)} TE= TE {(no, o)} TV= TV {no} TV= TV {o} E= E TE V= V TV return true end else begin TE= TE {(no, o)} TV= TV {no} TV= TV {o} if (LimitC+ 1=Limit) or (UNO return false else {no}=no) then //terminating condition return ConnectWithNeutralOperators(no, op, LimitC+1, UNO end end // TNO is processed end // ConnectWithNeutralOperators {no}) ----------------------------------------------------------------------------------------------------------------- // function NeutralOperators returns the set of neutral operators satisfying the preconditions //of o // o a node-input variable // UNO a set of nodes- input variable ----------------------------------------------------------------------------------------------------------------- function Operators NeutralOperators(in o,in UNO) //Local variables // TNO a set of operators-temporal variable for neutral operators // no a node //Notations // o.pre preconditions of node o // no.eff effects of node no var Tarak CHAARI - 210 - Thèse de doctorat

Annexes TNO, no begin TNO= Ø for each no NO begin if (o.pre no.eff) then if (no UNO) then TNO=TNO end {no} return TNO end // NeutralOperators ----------------------------------------------------------------------------------------------------------------- // procedure Remove it removes the node x recursively until it finds a node with a branch //connection or it reaches the start node // x a node- input variable ----------------------------------------------------------------------------------------------------------------- procedure Remove(in x) //Local variables // z a node for which (z, x) is an edge in E // y a node for which (x, y) is an edge in E var z, y begin if (x=ao) then // it is the start node make V empty and return begin V= Ø return end else if ((y V) and ((x, y) E)) then // x has a branch connection begin return end else begin for each (z, x) E begin E=E-(z, x) Remove(z) end V=V-{x} end // each (z, x) is processed end //Remove Tarak CHAARI - 211 - Thèse de doctorat

FOLIO ADMINISTRATIF THESE SOUTENUE DEVANT L'INSTITUT NATIONAL DES SCIENCES APPLIQUEES DE LYON NOM : CHAARI DATE DE SOUTENANCE : 28/09/2007 Prénoms : Tarak TITRE : Adaptation d applications pervasives dans des environnements multi-contextes NATURE : Doctorat Numéro d'ordre : 07 ISAL Ecole doctorale : Ecole Doctorale Informatique, Information et société Spécialité : Informatique Cote B.I.U. - Lyon : T 50/210/19 / et bis CLASSE : RESUME : 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. MOTS-CLES : Système d information pervasifs, Sensibilité au contexte, Adaptation de services, Adaptation de contenu, Adaptation d interfaces utilisateurs LABORATOIRE (S) DE RECHERCHE : Laboratoire d'informatique en Images et Systèmes d'information (LIRIS), UMR 5205, INSA de Lyon 20, avenue Albert Einstein, 69621 Villeurbanne CEDEX DIRECTEURS DE THESE: André FLORY, Professeur à l INSA de Lyon Frédérique LAFOREST, Maître de conférences à l INSA de Lyon COMPOSITION DU JURY : Paul RUBEL, Professeur à l INSA de Lyon (Président du jury) Philippe ANIORTE, Professeur à l université de Pau (Rapporteur) Florence SEDES, Professeur à l INP de toulouse (Rapporteur) Augusto CELENTANO, Professeur à l université de Venise (Examinateur)