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)
212
Embed
Adaptation d'applications pervasives dans des ...csidoc.insa-lyon.fr/these/2007/chaari/these.pdf · ce travail de thèse, nous proposons une stratégie complète, générique et évolutive
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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
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
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 IIINNNTTTRRROOODDDUUUCCCTTTIIIOOONNN GGGEEENNNEEERRRAAALLEEE
“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 21iè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
CCCHHHAAAPPPIIITTTRRREEE III --- EEETTTAAATTT DDDEEE LLL’’’AAARRRTTT ::: LLLEEESSS SSSYYYSSSTTTEEEMMMEEESSS
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.
Données
Entité logicielle
Service
Interface utilisateur
Service d’images médicales IMAGE
URL
Figure 16 - Un exemple d'une entité logicielle
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=(x1,x2,…xm) et qui renvoie un
ensemble de valeurs OUTPUT=(c1, c2… cn) où INPUT et OUTPUT sont des vecteurs de
valeurs typées. Ainsi un service peut être modélisé par une fonction f :
)(INPUTfOUTPUT = où INPUT est le vecteur d’entrée du service f et OUTPUT est son
vecteur de sortie.
Chaque composant ci de OUTPUT est une classe qui a un nom et un type (ci.name et
ci.type). Le composant ci peut être récupéré à l’aide de l’opérateur [] sur le vecteur de sortie
(ci= OUTPUT[i]). Nous associons à chaque composant ci, un vecteur ri=(ria, rib…) où ria,
rib… sont les valeurs renvoyées par le service f et associées au composant de sortie ci. les
vecteurs ri peuvent être considérées comme des instances de ci. 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.
f INPUT=(x1,x2,…xm) OUPUT=(c1, c2… cn) ci
+ name
+ type
ri
+ value
*entrée
Service sortie
Paramètre de sortie Valeur de sortie
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 mono-
opé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 f1,f2…,fn. Nous disons dans ce cas que le service f dépend de f1, f2… et/ou fn.
Nous pouvons avoir des dépendances en « et » si f dépend de f1, f2… et fn. Nous pouvons aussi
avoir des dépendances en « ou » si f dépend de f1, f2… ou fn.
Nous utilisons la notation (f1∧f2∧…∧fn) f pour modéliser la dépendance « f dépend de f1,
f2… et fn ». 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 f1, f2… et fn.
f
… f1 f2 fn
Figure 18 – Dépendance en « et » entre services
Nous utilisons aussi la notation (f1∨f2∨…∨fn) f pour modéliser la dépendance « f dépend
de f1, f2… ou fn ». Dans ce cas, le service f ne peut être offert à l’utilisateur que si au moins
l’un des services f1, f2… ou fn 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 f1, f2… fn. La
figure 19 illustre le cas de la dépendance en « ou ».
f
… fn f1 f2
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=(f0, F, T) qui
satisfait les recommandations suivantes :
1. F est un ensemble fini de services f1, f2,…, fn
2. f0 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 t1, t2,…, tm
4. Chaque transition ti 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 a1, a2, …, al entre les services.
d) ai 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 ai
représente un lien de dépendance d’exécution entre un service source ai.sourceService et un
service destination ai.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).
Temperatures
Authentication
RecordInfo RecordImages
PatientList
UserID
PatientID PatientID PatientID
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
IUA IUA MFA MFA MFA
Interpréteur de contexte
Interpréteur de contexte
Couche d’adaptation Consommateur de
contexte
Module d’adaptation des services
Module d’adaptation de présentation
Abonnement() push() pull()
Couche de gestion du contexte
stockage du contexte
Fournisseur de contexte
Gestionnaire de contexte
broker
Gestionnaire d’applications
Module d’adaptation des données
Flux de données/contrôle héritage dépendance Base de règles d’adaptation Modèle fonctionnel / adapté Interface utilisateur adaptée
Données de l’application
Services de base
Couche de déploiement d’applications
MF
BR
IUA
BR
MF/A
IUA
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
I CCCHHHAAAPPPIIITTTRRREEE IIIVVV --- CCCOOONNNTTTRRRIIBBBUUUTTTIIIOOONNNSSS ::: SSSTTTRRRAAATTTEEEGGGIIIEEE
DDD’’’AAADDDAAAPPTTTAAATTTIIIOOONNN AAAUUU CCCOOONNNTTTEEEXXXTTTEEE P
“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
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 &&
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 &&
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 = (c1, c2…cn) 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 (c1, c2…cn) 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 = (c1, c2…cm) 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.
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
R CCCHHHAAAPPPIIITTTRREEE VVV --- CCCOOONNNTTTRRRIIIBBBUUUTTTIIIOOONNNSSS ::: IIIMMMPPPLLLAAANNNTTTAAATTTIIIOOONNN EEETTT
UUUTTTIIILLLIISSSAAATTTIIIOOONNN DDDEEE NNNOOOTTTRRREEE PPPLLLAAATTTEEEFFFOOORRRMMMEEE DDD’’’AAADDDAAAPPPTTAAATTTIIIOOONNN I 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
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
addUserremoveUser
modifyUser
authenticationconnect
UserManagementAdministrator
<<include>>
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
[Want92] 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] Ward, A. Jones, A. Hopper. A New Location Technique for the Active Office.
IEEE personnal Communications, 1997, Vol. 4, N°5, pp. 42-47
[Wee 03] S. Wee and J. Apostolopoulos. Secure scalable streaming and secure
transcoding with JPEG-2000. IEEE International Conference on Image
Processing, September 2003, Barcelona, Spain.
[Weiser95] 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
[Weiser97] 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.
[Weiser99] 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
[Widom96] J. Widom, S. Ceri, editors. Active Database Systems – Triggers and Rules
For Advanced Database Processing. Morgan Kaufmann Publishers, 1996,
332p
[Wies95] 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] Winograd, Terry. Architectures for Context. Human-Computer Interaction
Journal, 2001, Vol. 6, N°2-3, pp. 401-419.
[Yarvis01] M. Yarvis. Conductor: Distributed Adaptation for Heterogeneous Networks.
Ph.D. Dissertation. Los Angeles , CA : UCLA Department of Computer
Science, November 2001.
[Yoshikawa97] 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.
[Zouari07] 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
AAANNNNNNEEEXXXEEESSS
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
</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">
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 {po} ∪end 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 {no}=NO) then //terminating condition ∪return false else return ConnectWithNeutralOperators(no, op, LimitC+1, UNO {no}) ∪end end // TNO is processed end // ConnectWithNeutralOperators ----------------------------------------------------------------------------------------------------------------- // 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 {no} ∪end 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)