La Sensibilité au Contexte dans un Environnement Mobile

Transcription

1 Université Mohammed V Souissi - RABAT École Nationale Supérieure d Informatique et d Analyse des Systèmes ENSIAS UFR : Réseaux & Télécommunications 2011 THÈSE Pour obtenir le titre de DOCTEUR EN SCIENCES APPLIQUÉES Spécialité : INFORMATIQUE La Sensibilité au Contexte dans un Environnement Mobile Présentée et soutenue publiquement par Yassine EL GHAYAM Le 31/12/2011 à l École Nationale Supérieure d Informatique et d Analyse des Systèmes Devant le jury composé de : Président du Jury : Pr. Abdelaziz KRIOUILE ENSIAS, UM5S, Rabat Rapporteur : Pr. Najib NAJA INPT, Rabat Rapporteur : Pr. Boubker REGRAGUI ENSIAS, UM5S, Rabat Rapporteur : Pr. Hassan MOUNTASSIR LIFC, Université Franche-Comté, Besançon, France Directeur de thèse : Pr. Mohammed ERRADI ENSIAS, UM5S, Rabat

2 Remerciements Je tiens à exprimer ma profonde gratitude à mon directeur de thèse, le professer Mohammed ERRADI pour son suivi rigoureux, son encouragement et sa patience depuis mes premiers pas jusqu à mon intégration totale dans la recherche. Cette thèse n a pas pu être bien avancée sans ses précieux conseils et sa disponibilité. Egalement, ses qualités scientifiques et humaines qui font un bon exemple pour moi. Je remercie infiniment Mr. Abdelaziz KRIOUILE professeur à l ENSIAS d avoir honoré cette thèse en présidant cette soutenance. Mes vives expressions de remerciements à Mr. Najib NAJA professeur à l INPT, qui a pris la charge d évaluer ce travail. Je le remercie de ses valeurs humaines et scientifiques. Je remercie chaleureusement Mr Boubker REGRAGUI professeur à l ENSIAS, de prendre la peine d évaluer mon travail malgré ses occupations. Je tiens à remercie infiniment Mr Hassan MOUNTASSIR pour l accueil à LIFC (département d informatique) à l université de Franche Comté à Besançon et son soutien et disponibilité à mon arrivée. Merci d accepter de rapporter le travail de ma thèse. Mes amis du laboratoire, entre autres je cite particulièrement Younes EL BOUZEKRI, Younes TABII, Abdelalim SADIQ et Adil KENZI, trouvent aussi mes vifs remerciements pour tous les beaux moments de discussion que nous avons partagés durant cette période de thèse et aussi pour leurs généreux soutiens pendant toute cette phase de thèse. J aimerais bien présenter mes chaleureux remerciements, et au nom de tout le personnel de l ENSIAS, à Mr Hassan ISMAILI, Chef de Scolarité à l ENSIAS qui représente, d un grand sincère et d une serviabilité incomparable, le coté dynamique de l administration au sein de l ENSIAS. Enfin je remercie toutes les personnes que je n ai pas citées, famille, amis, et personnel de l ENSIAS qui m ont aidé directement ou indirectement durant ma thèse. 2

3 Résumé De nos jours, l interaction avec les applications informatiques profitent de plus en plus de technologies mobiles. L adoption de ces technologies assure plus de flexibilité et permet de créer de nouvelles formes d utilisation. Ces technologies mobiles attribuent à un environnement de travail des caractéristiques physiques et des propriétés sociales. Les propriétés sociales définissent les habitudes, les règles et les normes sociales d un environnement de travail. Les paramètres et les propriétés de cet environnement définissent les informations de contexte. Une application sensible au contexte est une application qui répond aux exigences imposées par ces informations de contexte. Une telle application doit être capable de capturer et de gérer les informations de contexte en vue d apporter des services adaptés. Cette thèse propose une nouvelle approche qui se base sur la considération de l environnement de travail. Ainsi, elle utilise un modèle de l environnement qui définit les éléments structurels nécessaires à l adaptation. Une méthodologie d adaptation au contexte est présentée en utilisant ces éléments structurels. Cette approche définit des règles d adaptation en se basant sur les arbres de décision. L adoption des arbres de décision permet de remédier à la diversité et au caractère incertain des paramètres de contexte sur lesquels sont basées les règles d adaptation. Vu la nature distribuée des applications mobiles et pour ainsi décentraliser le processus d adaptation au contexte, nous proposons l adoption des agents mobiles. Nous avons mis en œuvre ces propositions en développant un prototype d adaptation au contexte pour une application de collaboration de télédiagnostic. Nous avons utilisé les technologies J2ME et JADE-LEAP pour la réalisation. Mots Clés : Sensibilité au contexte, Règles d adaptation, Arbre de décision, Collaboration mobile, Agent mobile, Environnement mobile. 3

4 Abstract Recently, the interaction with software applications is mainly oriented towards mobile technologies. The adoption of these technologies allows providing more flexibility and creating new forms of interactions. These mobile technologies attribute to a working environment a set of physical parameters and social properties. The social properties define habits, rules and social norms of an environment. These parameters and properties constitute the context information. A context-aware application is an application that meets the requirements of the context information. Such an application must be capable of capturing and managing context information in order to provide adapted services. This thesis proposes a new approach that is based on the consideration of the working environment. It uses a model of the environment that defines the structural elements necessary for the adaptation. A methodology for context adaption is presented using these structural elements. This approach defines adaptation rules using a decision tree model. It responds well to the diversity and uncertainty of context parameters on which the rules are based. Due to the distributed nature of mobile applications, we decentralize the process of context adaptation by using mobile agents. We have implemented our approach by developing a prototype for context adaptation for a tele-diagnosis collaborative application. We developed the prototype by using J2ME technologies and JADE-LEAP. Key Words : Context-awareness, Adaptation rules, Decision tree, Mobile collaboration, Mobile agent, Mobile environment. 4

5 Table des Matières Résumé... 3 Abstract... 4 Table des Matières... 5 Liste des Figures... 8 Publications Introduction Générale Motivation Problématique Organisation du document PARTIE I: Etat De l Art Chapitre I : Etat de l Art : Définitions Définitions de contexte Définition littéraire Définition de la psychologie cognitive Définitions de l Informatique mobile Notre définition Caractéristiques de l information de contexte Catégorisation de contexte Sensibilité au Contexte Définitions existences Notre définition Architecture générale d un système sensible au contexte Capture de contexte Interprétation de contexte Gestion de contexte Adaptation au contexte Conclusion

6 Chapitre II : Etat De l Art : Tavaux Existants Introduction Systèmes Web Collaboratifs ContextUML CML (Contxet Modelling Language) Modélisation du contexte pour les environnements de l'information La sensibilité au Contexte Utilisant des Politiques Sémantiques Framework pour l adaptation du contenu Personnalisation des Applications Web Les agents mobiles sensibles au contexte CoBrA (Context Broker Architecture) Système d'adaptation de Documents Multimédias Etude comparative Eléments de comparaison Comparaison Conclusion PARTIE II: Contributions Chapitre III: La Sensibilité au Contexte, Un Modèle de l Environnement Introduction Modèle d un système sensible au contexte Modèle de l environnement Modèle d Adaptateur au Contexte Manipulation des actions Méthodologie d adaptation au contexte Conclusion Chapitre IV : Adaptation au Contexte Basée sur les Arbres de Décision Introduction Cas d étude : Un Télédiagnostic Collaboratif Analyse de cas d étude : Modèle de l arbre de décisions Adaptation au contexte Modèle de contexte Architecture

7 5.3 Construction des règles Conclusion Chapitre V : Gestion Distribuée de la Sensibilité au Contexte Introduction Exigences Modèle de l Agent Mobile Architecture d une Gestion Distribuée Basée sur l Agent Mobile Etude de cas (suite) Algorithme de gestion de ressources dans un environnement mobile Motivations Architecture de Collaboration des Agents Mobiles Algorithme de sélection sensible au contexte Conclusion Chapitre VI : Conception et Réalisation Introduction Conception d un système de collaboration de Télédiagnostic sensible au contexte Modèle UML Diagramme de composant Diagramme de Classe Réalisation Les technologies sous-jacentes Architecture du prototype Développement du prototype Conclusion Conclusion et Perspectives Bibliographie Annexes

8 Liste des Figures FIGURE I-1 ARCHITECTURE DE SYSTEMES SENSIBLES AU CONTEXTE FIGURE II-1 COMPOSITION DE DESCRIPTION DE CONTEXTE FIGURE II-2 SCHEMA UML DECRIVANT LES PROFILES GENERAUX FIGURE II-3 LE META-MODELE CONTEXTUML FIGURE II-4 EXEMPLE D UN MODELE CML FIGURE II-5 MODULES DE META-MODELE FIGURE II-6 LE MODELE CONTEXT TYPE FIGURE II-7 FUZZIFYING L INFORMATION DE CONTEXTE FIGURE II-8 L ONTOLOGIE DE POLITIQUES FIGURE II-9 FONCTION DE SATISFACTION FIGURE II-10 ALGORITHME DE SELECTION DE TRANSCODEURS APPROPRIES FIGURE II-11 EXEMPLE DE POLITIQUE FIGURE II-12 GRAPHE DE REPRESENTATION DE L ONTOLOGIE COBRA FIGURE II-13 UNE ARCHITECTURE DE FOURNITURE DE DOCUMENTS MULTIMEDIA ADAPTABLES FIGURE III-1 LES COMPOSANTS D UN SYSTEME SENSIBLE AU CONTEXTE FIGURE III-2 MODELE DE L ENVIRONNEMENT DE TRAVAIL FIGURE III-3 MODELE DE L ADAPTATEUR AU CONTEXTE FIGURE IV-1 UTILISATION DE RESSOURCES PARTAGEES LORS D UNE COLLABORATION FIGURE IV-2 LES FLUX DE CONSTRUCTION DES REGLES DE DECISIONS FIGURE IV-3 ARCHITECTURE D UN SYSTEME D ADAPTATION BASEE SUR LES ARBRES DE DECISION FIGURE IV-4 CONSTRUCTION DE L ARBRE DE DECISION FIGURE IV-1 MODELE D UN AGENT MOBILE FIGURE V-2 ARCHITECTURE DE GESTION DE COLLABORATION BASEE SUR LES AGENTS MOBILE FIGURE V-3 ARCHITECTURE D UN SYSTEME DE COLLABORATION BASEE SUR L AGENT MOBILE FIGURE V-4 SESSION COLLABORATIVE ENTRE DES AGENTS MOBILES FIGURE V-5 ALGORITHME DE COLLABORATION ENTRE LES AGENTS MOBILES FIGURE V-6 ALGORITHME DE SELECTION D UN TERMINAL FIGURE VI-1 TAXONOMIE DE DIAGRAMMES DE STRUCTURES ET DE COMPORTEMENT [59] FIGURE VI-2 UNE ARCHITECTURE A BASE DE COMPOSANTS FIGURE VI-3 DIAGRAMME DE CLASSES FIGURE VI-4 PILE DE COMPOSANTS DE J2ME FIGURE VI-5 L ENVIRONNEMENT D EXECUTION DE JADE-LEAP FIGURE VI-6 ARCHITECTURE DU PROTOTYPE

9 FIGURE VI-7 CREATION D UN AGENT MOBILE FIGURE VI-8 LA CLASSE AGENT MOBILE FIGURE VI-9 LA CLASSE CONTEXT FIGURE VI-10 ATTRIBUTION DE RESOURCES FIGURE VI-11 PROTOTYPE DE REALISATION D UNE AFFECTATION SENSIBLE AU CONTEXTE DE RESOURCES

10 Publications Le travail lors de cette thèse a abouti aux publications suivantes : - Y. Elgahyam et M. Erradi, "Distributed Context Management in Collaborative Environment", Proceeding of the Conference New Technologies of Distributed Systems, NOTERE 2011, pp. 1-8, Paris, France. - Y. Elgahyam et M. Erradi, "Decision Tree Based Context Management in a Collaborative Environment", Proceeding of the Conference New Technologies of Distributed Systems, NOTERE 2010, Tozeur, Tunisie. - Y. Elghayam, A. Hammad, M. Erradi, "A Component based Architecture for a Context- Aware Telediagnosis System", Journées Doctorales en Technologies de l Information et de la Communication, JDTIC 2009, Rabat, Maroc. - Y. Elgahyam, A. Sadiq et M. Erradi, "Arbres de Décisions pour la Gestion de la Sensibilité au Contexte", International Conference On Next Generation Networks & Services, NGNS 2009, Rabat, Maroc. - Y. Elgahyam, M. Erradi et M. Ouzzif, "An LTL Specification and Verification of a Mobile Teleconferencing System", International Workshop on Verification and Evaluation of Computer and Communication Systems, VECoS 2008, Leeds, UK. - Y. Elgahyam, M. Erradi et M. Ouzzif, "Une approche de Gestion de Déconnexion lors de Sessions de Collaboratives Mobiles", Journées d Informatique et de Mathématiques Décisionnelles, JIMD 2008, Rabat, Maroc. - Y. Elghayam, M. Ouzzif, M. Erradi, "Sensibilité au Contexte : Etat de l Art", International Conference On Next Generation Networks & Services, NGNS 2007, Fes, Maroc. - Y. Elgahyam, M. Erradi et M. Ouzzif, "Vers une Plateforme Collaborative Mobile pour le Télédiagnostic", International Conference of E-Medical Systems, E-MedSys 2007, Fes, Maroc. 10

11 INTRODUCTION GENERALE 11

12 1 Motivation La technologie mobile connaît un considérable développement ces dernières années. Ce développement est marqué par l évolution technologique des terminaux mobiles (utilisation des téléphones cellulaires intelligents, les assistants numériques personnels (PDA), etc.). L évolution de la technologie mobile se manifeste aussi par le développement des réseaux de communications sans fil (WiFi, Wimax, Bluetooth, etc.). L ensemble de ces technologies changent complètement le mode d utilisation de l Informatique. Au début, l utilisation de l Informatique prenait une forme standard. Un utilisateur d une application est associé à un ordinateur situé dans un bureau. L utilisateur est déterminé par des caractéristiques communes avec tous les autres utilisateurs de la même application. En général, il est défini par un processeur supportant un grand nombre de traitements, une connexion filaire et une alimentation continue. Ces caractéristiques ont caractérisé l environnement de travail comme étant un environnement stable. Cependant, l utilisation de l Informatique est limitée par le positionnement de l utilisateur dans son bureau. Avec l avènement des technologies mobiles, on parle de l Informatique Pervasive introduite initialement par M. Weiser [9]. L Informatique Pervasive rend l utilisation de l Informatique possible en tout moment et indépendamment de positionnement de l utilisateur. Cette nouvelle forme de l Informatique ouvre de nouvelles opportunités aux utilisateurs mobiles de s engager dans des sessions d interactions avec des applications. Parmi les applications mettant plus en valeur à cette avancée technologique, on retrouve les applications de collaboration telles que la télémédecine et le téléenseignement. Par exemple, dans le cadre de télémédecine, plusieurs utilisateurs peuvent utiliser un espace partagé des outils et des services pour atteindre un diagnostic commun. Ces utilisateurs profitent de l intégration des terminaux légers de différents types pour les utiliser dans une collaboration. Cette intégration permet d établir et d assurer la continuité de la collaboration indépendamment du positionnement des utilisateurs et de leurs activités en cours. 2 Problématique Les applications destinées à fonctionner dans des environnements mobiles présentent plusieurs défis. Un environnement mobile, en général, est caractérisé par la capacité limitée de ses ressources. Les terminaux sont caractérisés par une autonomie rétrécie et une aptitude restreinte de traitement de données. Quand aux réseaux sans fil, ces derniers sont connus par leurs états de connectivités intermittentes. Ceci est dû essentiellement de la limitation de la bande passante et du débit faible [64]. En plus des caractéristiques physiques de ces environnements, l omniprésence des terminaux utilisés, pour intervenir dans une session de collaboration dans un moment donné, implique que l utilisation de l application est confrontée par les règles et les politiques prédéfinie par ces environnements. Par exemple, dans une intervention de 12

13 collaboration de télédiagnostic, un médecin situé dans une salle de chirurgie est contraint par les règles imposées dans cet endroit. Le chirurgien ne peut pas librement manipuler les différents outils et services disponibles dans un tel endroit. L ensemble des informations caractérisant ces environnements sont dits des informations de contexte. En conséquence, la conception des applications mobiles doit être faite en considérant ces informations de contexte. Les actions fournies par ces applications doivent être dotées de mécanismes qui collectent les informations de contexte, stockent et gèrent ces informations et qui réagissent à base de ces informations. Les réactions de ces applications se font sous formes des adaptations des actions fournies selon les exigences imposées par les informations de contexte. Les applications qui intègrent ces mécanismes sont les applications sensibles au contexte (context-aware applications). L adaptation au contexte est un ensemble de règles qui prennent la forme de conditionaction. Les conditions portent sur les variables de contexte. Les actions expriment les changements à apporter à l application. Cependant, les informations de contexte, dont la construction des règles d adaptation se base, sont très nombreuses, interdépendantes et peuvent être influencées par plusieurs facteurs qui touches leurs crédibilités. Dans cette thèse, nous avons fait une étude sur les travaux existants des systèmes sensibles au contexte. Cette étude est réalisée en considérant plusieurs critères : Catégorie de contexte, Modèle de l environnement, Type d adaptation, Qualité de contexte et Gestion distribuée. L étude de ces critères a donné l objet de plusieurs contributions. Premièrement, nous avons constaté que les travaux étudiés ne proposent aucun modèle explicite de l environnement de travail. Nous considérons qu un modèle de l environnement de travail est indispensable pour la conception d une application sensible au contexte. Deuxièmement, nous avons déduit de cette étude que les approches d adaptation sont de types réactifs. Par la réaction, nous désignons l association d une perception d une information de contexte à une action d adaptation. Nous considérons que cette vision se complique dans le cas d un environnement de multiples variations de ses paramètres de contexte. Pour cela nous proposons une nouvelle approche qui se base sur l intégration d un système à un environnement de travail. Nous signifions par l intégration, d interagir en respectant et renforçant les règles et les politiques prédéfinies par cet environnement. L adaptation par intégration impose le besoin d un modèle explicite de l environnement de travail. Troisièmement, nous avons remarqué que la qualité de contexte est partiellement traitée dans ces travaux. Nous proposons un modèle technique formalisé d une approche d adaptation au contexte. Notre approche d adaptation se base sur les arbres de décisions pour la construction de règles d adaptation. Nous montrons que l adoption des arbres de décisions remédie bien à la qualité de contexte en termes de son caractère incertain, interdépendant et diverse. Quatrièmement, nous avons constaté que les processus de la sensibilité au contexte (la capture, la gestion et l adaptation) sont centralisés sur une seule entité. La sensibilité au 13

14 contexte, en général, est destinée à un environnement réparti et constitué de terminaux légers. En conséquence, ce type d environnement ne peut pas supporter des tâches supplémentaires qui concernent la gestion de l ensemble des informations de contexte et l adaptation. Pour cela, nous proposons une approche de distribution des processus de la sensibilité au contexte. Cette approche se base sur le concept des agents mobiles. Dans cette approche nous proposons aussi des algorithmes de gestion de l insuffisance des ressources de l environnement de travail au cours d une session de collaboration. 3 Organisation du document Cette thèse comporte trois parties principales : un état de l art, les contributions et l implémentation. La partie état de l art est composée de deux chapitres : Chapitre I : Etat de l art : les définitions. Ce chapitre présente le contexte scientifique de notre travail de thèse. Nous y détaillons la notion de contexte, la notion de la sensibilité au contexte et nous y présentons une architecture générale d un système sensible au contexte. Chapitre II : Etat de l art : Les travaux existants. Ce chapitre est destiné à présenter les différents travaux d adaptation que nous avons jugés intéressants pour l adaptation au contexte. Nous terminons ce chapitre par une étude comparative de ces travaux. La deuxième partie, qui regroupe l ensemble des contributions, comporte trois chapitres : Chapitre III : La sensibilité au contexte, un modèle de l environnement. Ce chapitre apporte une méthodologie d adaptation au contexte en se basant sur une étude des exigences de l environnement de travail. Chapitre IV : Adaptation au contexte basée sur les arbres de décision. Ce chapitre utilise la méthodologie définie dans le chapitre précédent et propose une adaptation basée sur les arbres de décision. Chapitre V : Gestion distribuée de la sensibilité au contexte. Ce chapitre améliore l approche du chapitre précédent en réalisant la distribution de l adaptation au contexte. La distribution est faite en utilisant les agents mobiles. La troisième partie concerne le chapitre Implémentation. Nous y présentons une conception et une implémentation de nos propositions. 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. 14

15 PARTIE I: Etat De l Art 15

16 Chapitre I : ETAT DE L ART : DEFINITIONS 16

17 1 DEFINITIONS DE CONTEXTE La définition de contexte est une étape primordiale pour la construction d un système sensible au contexte. Plusieurs définitions ont été proposées selon des domaines particuliers. En générale, le contexte est défini comme un ensemble des informations qui définissent l environnement qui entourent une activité. Pourtant une définition concrète et pragmatique qui délimite et distingue les informations de contexte des autres informations de l application et qui éclaircit le rôle et l utilité de ces informations de contexte n est pas encore développée. Avant d aborder les définitions de contexte dans le domaine de l Informatique, nous commençons par la définition de ce concept dans les autres domaines y inclut le sens littéraire et psychologique de ce mot : 1.1 DEFINITION LITTERAIRE Littérairement, la définition de contexte met l accent sur l ensemble des informations (conditions, texte, circonstances) qui entourent une opération (un discours ou bien un fait) : - Larousse : (latin contextus, assemblage), ensemble des conditions naturelles, sociales, culturelles dans lesquelles se situe un énoncé, un discours. - Le Robert : ensemble du texte qui entoure un élément de la langue : un mot, une phrase ou un fragment d'énoncé ou bien un ensemble des circonstances dans lesquelles s'insère un fait. 1.2 DEFINITION DE LA PSYCHOLOGIE COGNITIVE Dans le domaine de la psychologie cognitive, le contexte a pris une considérable attention. L un des travaux qui a contribué à une définition concrète et utile de contexte est le psychologue Bert Van Oers 1. Sa définition de contexte est donnée dans le cadre de la théorie de l apprentissage chez l enfant: Le sens (meaning) d un symbole ou d un signe ne peut être établi d une façon plus ou moins précise, que si ce processus de construction de sens est supporté par une information additionnelle venue de l environnement qui entoure ce processus le champ concret de construction d un sens, dans un moment particulier, est généralement référencié par le contexte [1]. Un symbole ou un signe est considéré comme l ensemble des moyens et des outils utilisés par l apprenant pour donner un sens. Ce psychologue confirme que le contexte est l ensemble des informations servant à orienter le sens de l apprenant dans un moment donné. Cette orientation se fait en contraignant le processus cognitif de la construction de sens chez l enfant. De cette définition qui a été expérimentée dans le domaine de la psychologie, on en tire que le contexte est une information complémentaire, venant de 1 Bert van Oers est un professeur de théorie d historico-culturelle de l éducation à Free University à Amsterdam. 17

18 l entourage de l enfant, qui sert à manipuler (adapter) l une des activités de l enfant (l apprentissage) en l orientant vers le sens voulu. 1.3 DEFINITIONS DE L INFORMATIQUE MOBILE La définition de contexte dans le domaine de l Informatique est donnée selon deux périodes : la période de l énumération des éléments de contexte et la période de l abstraction et généralisation de l information de contexte. - Enumération des éléments de contexte : dans une première période de la définition de contexte, les chercheurs ont essayé de définir le contexte en énumérant tous les éléments qui peuvent être considérés comme une information de contexte. Ces éléments constituent des informations non fonctionnelles de l application qui peuvent apporter un impact sur l application. Parmi les travaux qui ont défini le contexte par énumération : - Schilit [2] considère que le contexte est la localisation de l utilisateur, les identités et les états des personnes et des objets qui l entourent. - Brown et al. [3] définissent le contexte en tant que l identité de l utilisateur, des personnes et des objets qui l entourent, sa localisation géographique, son orientation, la saison et la température où il évolue. - Rayn et al. [4] présentent le contexte par la localisation, l environnement physique, l identité et le temps de l utilisateur. Ces définitions sont considérées très restrictives. En effet, les éléments de contexte ne peuvent pas être universellement délimités ou bien valables pour toutes les applications. Par exemple, une information, tel que l endroit de l utilisateur, est considérée comme une information de contexte dans une application de télédiagnostic mais, pour une application de régulation de trafic, cette même information est considérée comme une information fonctionnelle de l application [5]. - Abstraction de la définition de contexte : dans une période ultérieure, les chercheurs tendent de plus en plus de donner une définition générique à l information de contexte en montrant son utilité et en la regroupant selon plusieurs catégories. Parmi les travaux qui définissent le contexte comme un concept abstrait : - Amara-Hachimi et al [6] considèrent que le contexte regroupe toutes les informations sur l environnement courant d exécution (d un agent mobile). Ces informations sont distribuées selon trois niveaux de contexte : contexte physique, contexte social et contexte utilisateur. - Miraoui et al. [7] définissent le contexte en tant que : toute information dont le changement de sa valeur déclenche un service ou change la qualité (forme) d un service. - Chaari et al. [5] définissent le contexte comme l ensemble des paramètres externes à l application pouvant influer sur le comportement d une application en définissant de nouvelles vues sur ses données et ses services. 18

19 L ensemble de ces définitions tournent autour la définition de Dey [8] qui considère que le contexte est: toute information qui peut être utilisée pour caractériser la situation d une entité. Une entité est une personne, un endroit ou un objet qui peut être considéré significatif à l interaction entre l utilisateur et l application, incluant l utilisateur et l application eux-mêmes". Cependant, cette définition est considérée très générale dans le sens à ne pas donner une limite entre les informations de contexte et les données de l application [5]. Dans ce dernier travail de Chaari, des caractéristiques ont donné pour distinguer des informations de contexte des données propres à l application : - Les informations de contexte ne proviennent pas d un stockage permanent de l application, alors que les données de l application font partie des constituants de l application. - Les paramètres de contexte ne sont pas toujours significatifs pour l utilisateur. 1.4 NOTRE DEFINITION De notre part, en se référant aux définitions existantes, on définit le contexte comme suit : Le contexte est toute information qui décrit, à un moment donné, l environnement dans lequel l action aura lieu. Pour ne pas rester dans les définitions générales, on complète la définition par des propriétés de contexte : - Un contexte est toujours associé à une action : un contexte n est jamais déterminé par les caractéristiques de l environnement en lui-même. Ce qui compte en tant que contexte dépend de comment l ensemble des informations de contexte (ce qui constitue une situation) est interprété en termes d actions à invoquer. - Le contexte contraigne une action : un contexte apporte un sens particulier à un environnement dans un moment donné. Ce sens se sert de contraindre la construction et/ou l exécution d une action. Par le terme environnement, on considère qu un environnement est composé d un amalgame de ressources, services et infrastructure [10]. Dans l absence de cette information de contexte, l environnement d un système définit un contexte unique, dit le contexte explicit, et ne posera aucune contrainte supplémentaire sur la construction et l exécution des actions. Ce type d environnement est défini, en général, par des entités ayant des paramètres non changeables avec le temps (le cas d un environnement de réseau filaire). 2 CARACTERISTIQUES DE L INFORMATION DE CONTEXTE Dans ce qui suit nous donnons des caractéristiques techniques de l information de contexte : 19

20 - Le contexte est changeable avec le temps : l information de contexte change continuellement de valeur avec le temps. Par exemple, le déplacement de l utilisateur implique que le contexte localisation de l utilisateur change de valeur. - L information de contexte est hétérogène : L hétérogénéité provient du fait que le contexte est capturé à partir d une variété de sources [11]. Particulièrement ce contexte peut être capturé (Sensed) directement de capteurs physiques ou récupérés à partir de composants logiciels, donné par l utilisateur (Profiled) ou bien dérivé (Derived) en synthétisant plusieurs sources ou interprété d une seule source pour obtenir un niveau levé de l abstraction de cette information - L information de contexte est imparfaite : cette caractéristique de contexte est déterminée selon la source de cette information : le contexte est ambigu si des ressources séparées fournissent une même information avec des niveaux de granularités différents, le contexte peut être imprécis ou bien le contexte peut être erroné ou même inconnu. - L information de contexte est interdépendante : l information de contexte peut être dépendante d une autre information de contexte. Le changement de valeur d une information de contexte peut influencer sur une autre valeur de contexte [12]. 3 CATEGORISATION DE CONTEXTE La catégorisation de l information de contexte facilite la collection et la présentation de cette information dans un système d adaptation. Plusieurs travaux ont proposé une catégorisation de contexte. Le travail indiqué dans [13], classifie le contexte selon un contexte physique de l utilisateur et un contexte organisationnel. Le contexte physique décrit les paramètres de l'utilisateur tels que : l emplacement, les caractéristiques du terminal et de l application. Le contexte organisationnel réfère aux informations relatives aux processus de collaboration dans lequel l utilisateur est impliqué tels que le rôle, l activité et le calendrier. Dans le travail de [6], une catégorisation de contexte est donnée selon un contexte utilisateur, un contexte physique et un contexte social. Le contexte utilisateur englobe les préférences de l utilisateur. Le contexte physique définit les caractéristiques des dispositifs physiques (la puissance du CPU, la bande passante). Le contexte social décrit les interactions entre les utilisateurs existants et les nouveaux arrivants. Ces catégorisations adressent la représentation de certains aspects de contexte de l environnement. On propose une catégorisation qui englobe tous les aspects de l environnement de travail et peut être commune aux différents domaines d applications. On considère que les informations de contexte peuvent être classifiées selon le contexte Utilisateur, le contexte Physique, le contexte Spatio-temporel et le contexte Organisationnel : 20

21 - Contexte Utilisateur : inclut les préférences de l utilisateur telles que la langue, la résolution de l écran voulu, le terminal choisi, etc. Ces informations sont souvent imposées par l utilisateur lui-même, - Contexte Physique : inclut les paramètres physiques de l environnement de travail. Cette catégorie décrit les caractéristiques du terminal (mémoire disponible, vitesse du processeur, la taille et la résolution d affichage, etc.) et du réseau de connexion (bande passante, mode de connexion, canal de connexion.). D autres paramètres physiques peuvent aussi être inclut tels que la température, le degré de la lumière, etc. - Contexte Spatio-temporel : inclut l information de l emplacement de l utilisateur et l information de sa proximité des terminaux disponibles et d autres utilisateurs. Le contexte temporel indique une référence temporelle aux actions courantes de l utilisateur et garde une trace pour les actions passées. - Contexte Organisationnel : se compose des informations relatives à la collaboration dans laquelle un utilisateur est engagé tels que le groupe auquel il appartient, le rôle, l activité en cours, les ressources partagées entre les membres du groupe, les autorisations possibles, etc. 4 SENSIBILITE AU CONTEXTE 4.1 DEFINITIONS EXISTENCES La sensibilité au contexte (Context-Awareness) est, en générale, de réagir proprement en prenant en compte l information de contexte. Le terme "Context-Awareness" est introduit pour la première fois en 1994 par Schilit et al. [2]. Ils considèrent que les applications sensibles au contexte sont des applications ayant des mécanismes de changer dynamiquement ou d adapter leurs comportements en se basant sur le contexte de l application ou de l utilisateur. Ryan et al. [4] définissent la sensibilité au contexte en tant que l aptitude de capturer, interpréter et répondre aux aspects de l environnement local de l utilisateur et de terminal. Dey et al. [8] considèrent qu un système est sensible au contexte s il utilise le contexte pour fournir une information pertinente à l utilisateur, la pertinence dépend de la tâche de l utilisateur. De sa part, Miraoui [14] considère qu un système est dit sensible au contexte s il peut changer automatiquement ses formes de services ou déclencher un service comme réponse au changement de la valeur d une information ou d un ensemble d informations qui caractérisent le service. 4.2 NOTRE DEFINITION La sensibilité au contexte est la réaction du système suite à un contexte survenu. Cette réaction se fait en réalisant une compatibilité entre le sens de l action et le sens particulier apporté par le contexte. Le sens de l action peut être défini par l objet de l action, son 21

22 objectif et les moyens disponibles pour invoquer cette action. La compatibilité est faite en contraignant le processus de construction et/ou d exécution de ces actions. Un système sensible au contexte est un ensemble de mécanismes destinés pour, d une part, la collection et la gestion des informations de contexte et, d une autre part, la gestion et le contrôle des actions du système (son comportement) en fonction de ces informations de contexte. Dans ce qui suit nous discutons l architecture générale d un système sensible au contexte. 5 ARCHITECTURE GENERALE D UN SYSTEME SENSIBLE AU CONTEXTE L architecture des applications sensibles au contexte est bien différente de celle des applications mobiles d interactions classiques. Dey [8] confirme que les applications d interactions classiques se différencient des applications sensibles au contexte au niveau des données explicites manipulées. Les données manipulées par les premières applications sont soient des variables internes de l application soient des données explicites des utilisateurs. Pour les applications sensibles au contexte, en plus des variables internes de l application et des données explicites des utilisateurs, elles traitent aussi les informations de contexte. Par conséquent, de suppléments traitements sont désignés par les systèmes sensibles au contexte. Ces traitements concernent la capture de ces informations de contexte, la gestion et l utilisation de ces informations pour fournir une sortie convenable. Plusieurs travaux ont proposé des architectures sensibles au contexte [5, 13, 14, 15]. Un accord général, dans ces travaux, sur la séparation entre la capture des informations de contexte et l utilisation de ces informations afin d assurer l extensibilité et la réutilisation du système. La figure I.1 montre l architecture générale d un système sensible au contexte. Elle est composée des couches suivantes : Capture de contexte, Interprétation de contexte, Gestion de contexte et Adaptation au contexte. FIGURE I-1 ARCHITECTURE DE SYSTEMES SENSIBLES AU CONTEXTE 22

23 5.1 CAPTURE DE CONTEXTE Les systèmes sensibles au contexte sont désignés pour être à l'écoute aux changements de l'environnement de système. La couche de capture est composée d un ensemble de capteurs. Ces capteurs peuvent être classifiés selon qu ils soient physiques ou logiques. - Capteurs physiques : ces capteurs capturent des grandeurs physiques tels que la température, la position géographique, le son, la lumière, etc. Parmi ces capteurs on trouve : le GPS (Global Posiotionning System) pour déterminer les coordonnées d un utilisateur, des caméras, des microphones, etc. - Capteurs logiques : ces capteurs peuvent rassembler des données à partir des applications et des services logiciels. Par exemple, on consulte un calendrier électronique pour déterminer la position ou l activité courante d un utilisateur. Dans le travail de Indulska [16], on donne une catégorisation des capteurs selon : physiques, virtuels et logiques. Les capteurs physiques sont pour les grandeurs physiques. Il Les capteurs virtuels sont les capteurs qui se basent sur les applications et les services et les capteurs logiques sont les combinaisons entre les capteurs physiques et virtuels. De notre part, on considère que l information produite par les capteurs logiques (selon la catégorisation de Indulska) est le résultat d une transformation de plusieurs informations de contexte capturées séparément à partir des capteurs physiques et logiques (selon notre catégorisation) pour avoir une information de haut niveau, qui est plus facile à manipuler par l application. Nous considérons que la transformation est une sorte d interprétation d informations de contexte. Afin d assurer la réutilisation de l information de contexte nous séparons séparent la couche interprétation de la couche capture de contexte. Dans le paragraphe suivant, nous expliquons la couche destinée pour l interprétation de contexte. 5.2 INTERPRETATION DE CONTEXTE Cette couche a pour but d interpréter les données contextuelles fournies par les capteurs. Elle sert à l analyse et à la transformation des données brutes, fournies par la couche de capture, d autres formats plus expressifs à l application. Les transformations effectuées sur les données brutes concernent l extraction, la quantification et l agrégation. Par exemple, les coordonnées GPS d une personne peuvent être moins significatives qu une adresse sous forme de numéro de rue et de ville. Cette couche peut aussi avoir le rôle de résolutions de conflits causés par l utilisation de plusieurs sources de contexte. Ces sources peuvent donner des résultats contradictoires ou peuvent aboutir à des situations imprécises. Cette couche doit donc avoir des moyens pour résoudre ces conflits [5]. 23

24 5.3 GESTION DE CONTEXTE A ce niveau, le contexte capturé et interprété doit être bien géré pour faciliter l utilisation. La gestion de contexte contient le stockage et la représentation formelle des informations de contexte. Le stockage peut être centralisé ou distribué. - Le stockage centralisé est le plus répandu et le plus utilisé puisqu il facilite des mises à jour et des modifications des valeurs de contexte. Pourtant, cette solution se limite avec les contraintes de la capacité des équipements mobiles utilisés dans la sensibilité au contexte. Ces équipements sont caractérisés par leurs espaces de stockage restreins. - Le stockage distribué remédie bien à la contrainte de l espace de stockage des équipements utilisés. Cependant, il inflige des fonctions additionnelles relatives à la synchronisation et à l actualisation des valeurs de contexte. La représentation de contexte est la structuration de ce contexte selon un modèle. Le choix du modèle dépend fortement de mécanismes choisis pour adapter les actions du système au contexte. Plusieurs méthodes de représentation ont été proposées dans la littérature, en invoquant les diverses technologies de modélisation et de représentation des données. Ces méthodes sont présentées selon : - Représentations à base de paire (attribut, valeur) : c est la structure des données la plus simple pour la modélisation des informations contextuelles. L attribut représente un élément de contexte tel que la localisation de l utilisateur. La valeur est la valeur actuelle de cette information. Par exemple { Localisation= La gare, Terminal= PDA, Heure= t 1 }. Cette représentation est caractérisée par sa facilité d implémentation. Cependant, elle manque d une force d expressivité et ne permet pas de présenter les relations entre les éléments de contexte. La représentation la plus connue illustrant ce modèle est le modèle ContextToolkit de Dey [17]. - Représentations basées sur XML : ces modèles utilisent une structure de données hiérarchique. Plusieurs modèles de description des informations de contexte se dérivent à partir de ce langage, à savoir UAProf (User Agent Profile) [18] et CC/PP (Composite Capabilities/Preference Profile) [19]. Le langage CC/PP est une recommandation de W3C (World Wide Web Consortium) Il est basé sur RDF (Resource Description Framework) qui est utilisé afin de créer des profils décrivant les capacités des terminaux et les préférences d un agent utilisateur. CC/PP est utilisé pour personnaliser le contenu sur la base des capacités d un terminal et les préférences de l utilisateur. Ces modèles fournissent une description des éléments de contexte (les ressources) en incluant des contraintes élémentaires et des relations entre ces éléments de contexte 24

25 pour construire un profile. Ces modèles sont plus expressifs relativement aux modèles basés sur Attributs/valeurs. - Représentations graphiques : Ces modèles consistent à modéliser les informations contextuelles selon un graphe conceptuel. Quan et al. [20] ont utilisé une représentation graphique basée sur UML (Unified Modeling Language) pour la modélisation des informations contextuelles pour la gestion des services web. Henricksen et al. [21] ont développé une approche de modélisation graphique basée sur ORM (Object Role Modeling). C est une méthode orientée "fait" pour l analyse de l information au niveau conceptuel. La modélisation dans ORM consiste à identifier les types des faits appropriés et les rôles des types d entités. Selon les auteurs, cette extension est plus formelle et plus expressive pour capturer différents types d informations contextuelles. Elle appuie le raisonnement sur le contexte, décrit les informations imparfaites et résout l ambiguïté de l information contextuelle. Cette méthode a subi des améliorations et devenue CML (Context Modeling Language) [11] et apparaît comme une extension d une représentation basée sur XML. - Représentation orientée objet : l'approche objet est utilisée pour pouvoir intégrer facilement la représentation du contexte au sein de l'application qui en dépend. Cette représentation du contexte s'appuie sur les propriétés de nommage, d encapsulation, de réutilisation et d'héritage. Parmi les travaux qui ont abordé cette méthode, le travail de Hofer et al. [22] qui ont introduit l approche "HYDROGEN ". Chaque type de contexte utilisé est composé de plusieurs objets contexte qui constitue la superclasse de plusieurs éléments du contexte, notamment : le temps, le réseau, la localisation, l utilisateur, la machine. les autres éléments peuvent être ajoutés par l héritage de la super classe. - Représentations basées sur des ontologies : Une ontologie est un ensemble structuré de concepts. Les concepts sont organisés dans un graphe dont les relations peuvent être des relations sémantiques ou des relations de composition et d'héritage. Elle fournit un vocabulaire représentatif pour un domaine donné, un ensemble de définitions et d axiomes qui contraignent le sens des termes de ce vocabulaire de manière suffisante pour permettre une interprétation consistante des données représentées au moyen de ce vocabulaire. Parmi les travaux qui ont utilisés des ontologies est le travail de Chen et al., [23]. Ils ont proposé une approche basée sur l'idée d'un courtier de contexte (Context Broker Architecture ou CoBrA). Il définit une collection d ontologies appelée COBRA-ONT pour la modélisation de contexte dans un environnement d une salle de rencontre intelligente. COBRA-ONT des concepts typiques associés avec des places, des agents et des événements. 5.4 ADAPTATION AU CONTEXTE 25

26 L adaptation au contexte est l ensemble des mécanismes de réactions prévues suites aux changements de contexte. L adaptation se base sur un ensemble de règles d adaptation. Ces règles sont implémentées selon des langages de programmations traditionnels ou bien en utilisant la logique de prédicats. Pour remédier au caractère incertain de contexte, certains travaux adoptent la logique floue ou la logique probabiliste. Plusieurs formes d adaptation peuvent être se présentées [24] : - Adaptation architecturale : désigne les changements faits, en temps réel, dans la structure des composants du système et/ou dans les interactions entre eux en utilisant un modèle architectural du système. - Adaptation compositionnelle : concerne les modifications de la structure et du comportement d une entité logiciel, en temps réel, en réponse aux changements arrivés à son environnement d exécution. - Adaptation structurelle : consiste en la mise à jour de sa structure en préservant son comportement et ses services. Une adaptation structurelle signifie le changement dynamique de type des composants de l application tel qu une signature d une méthode. - Adaptation comportementale : désigne les changements dynamiques dans la phase de l exécution d un composant logiciel d une manière non intrusive (par exemple : en changeant sa configuration ou bien en interceptant ses requêtes et réponses). - Adaptation de contenu : concerne la transformation et la manipulation des contenus en se basant sur les caractéristiques de l application et des terminaux utilisés. 6 CONCLUSION Nous avons fait un tour d horizon sur les définitions de contexte les plus utilisées et les définitions de la sensibilité au contexte. Nous avons proposé notre propre définition de contexte et de la sensibilité au contexte. A la fin de ce chapitre, nous avons montré l architecture générale d un système sensible au contexte. Dans le chapitre suivant, nous allons étudier les travaux potentiels de la sensibilité au cotexte. Cette étude se termine par une étude comparative de ces travaux. 26

27 Chapitre II : ETAT DE L ART : TAVAUX EXISTANTS 27

28 1 INTRODUCTION Ce chapitre présente la description de plusieurs travaux portant sur le développement de systèmes sensibles au contexte [61]. Les descriptions portent sur les définitions considérées de contexte, les méthodes de modélisations adoptées et les méthodes de raisonnement sur le contexte. 2 SYSTEMES WEB COLLABORATIFS Le travail présenté dans [13] décrit le travail collaboratif pour les systèmes web. Il vise à automatiser les activités des individus au sein du groupe en mettant en considération les connaissances de contexte, dites organisationnelles et physiques. La modélisation de l information de contexte s effectue à base d'une approche orientée objet. Elle se réalise en deux étapes : - Tracer les profils généraux qui indiquent les contextes potentiels caractérisant les situations habituelles de l'utilisateur, - Modéliser la situation courante de cet utilisateur. Dans la figure.ii.1 le contexte est représenté par la classe Context_Description. Cette classe apporte des descriptions (l association contextualize) à un élément de contexte (la classe Context_Element). Un élément de contexte représente tous les éléments de contexte (physique et organisationnel) tels que Device, Space, Member, etc. On considère que la classe Context_Description peut avoir plusieurs instances : divers contextes pour les applications (qu on les notera par la suite par application_contexte), c'est-à-dire qu un utilisateur peut avoir plusieurs situations dans lesquelles un profil est valide. II-1 COMPOSITION DE DESCRIPTION DE CONTEXTE 28

29 Le profil général d un utilisateur est composé de, voir la figure.ii.2 : - Un ou plusieurs contextes d application, application_contexte, à considérer (plusieurs instances correspondant à la classe Context Description), - Un ensemble des événements à sélectionner, la classe Event. Cette classe indique quel contenu informationnel considéré convenable à délivrer au propriétaire du profil. Chaque événement représente un ensemble d information utile sur un sujet. De plus chaque instance d un événement est associée à une instance d une description de contexte qui représente le contexte dans lequel l événement doit être produit. - Un ordre de propriété et un intervalle de temps à respecter (indiqués dans la classe sign up). - Un ensemble de conditions (attribut de la classe GeneralProfile) relatives au contexte dans lequel l événement est pris. FIGURE II-2 SCHEMA UML DECRIVANT LES PROFILES GENERAUX L'automatisation du travail collaboratif se fait par un processus de filtrage qui est une sorte de comparaison entre le contexte d application (application_context) des profils généraux disponibles, avec le contexte courant de l'utilisateur. A noter que ces deux types de contexte ; le contexte courant de l utilisateur et le contexte d application sont les deux, des instances de la classe Context_Description de ce modèle. A la comparaison, on teste si l un de contexte d application de chaque profil a le même contenu ou un sous ensemble de la description du contexte courant de l utilisateur. 29

30 Une fois le profil applicable est sélectionné, la deuxième étape du processus de filtrage est de prendre l événement correspondant. Ce choix s effectue en considérant les règles définies dans chaque profile sélectionné, par exemple, l ordre de priorité de ces événements. 3 CONTEXTUML Le système, ContextUML [20], est un méta-modèle qui aborde les services web sensibles au contexte (Context-Aware Services CAS). Ce sont des services dotés de conscience sur l'environnement courant de l'exécution de leurs utilisateurs afin de fournir des services sur mesure. Le développement de CAS exige deux issues : premièrement, l approvisionnement de l information de contexte, et ce en mettant des senseurs qui récupèrent ces informations et de pouvoir identifier le type utile de l information de contexte récupérée et comment la traiter. Deuxièmement, les mécanismes utilisés par le CAS pour adapter son comportement suivant le contexte sans l intervention explicite de l utilisateur. Les informations de contexte considérées sont : - Des informations décrivant l utilisateur telles que les préférences du client (la langue choisie, la résolution d affichage, etc.), la situation courante de l utilisateur (par exemple l emplacement géographique), en plus d autres informations (la liste des amis, calendrier), - Des informations décrivant les Services Web, tels que l'état du service (disponible, occupé), l endroit du service et les attributs de QoS (le coût, l efficacité), - Des informations supplémentaires spécifiques à l application, tels que l heure et les informations de climat. Le contexte est représenté par la classe Context (voir la figure II.3). Cette classe est catégorisée selon deux sous types AtomicContext et ComponentContext. La classe AtomicContext représente les éléments de bas niveau de contexte qui ne dépendent pas sur d autres éléments de contexte et qui sont fournis directement par les sources de contexte (par exemple Temperature, rainlikelihood). La classe ComponentContext rassemble des informations de contexte qui peuvent être composées (ou dérivées) de multiples éléments de contexte (par exemple harshweather). 30

31 FIGURE II-3 LE META-MODELE CONTEXTUML La capture du contexte est illustrée, comme le montre la figure II.3, par l'entité ContextSource qui modélise les ressources du contexte. Dans le modèle ContextUML, la complexité de l acquisition de contexte est cachée. En effet, la notion de service de contexte, introduite dans ce modèle, encapsule les détails de captures et fournit une information de contexte après l interprétation et la transformation de l information capturée (l information de contexte brute). Ces ressources de contexte peuvent être simples (ContextService) ou composées (ContextServiceCommunity). Un objet de la classe ContextService abstraite un fournisseur de service de contexte qui collecte, raffine et dissémine l information de contexte. La ContextServiceCommunity est désignée pour récupérer l information de contexte à partir de sources hétérogènes et dynamiques. Cette classe regroupe plusieurs services de contexte, qui permet une sélection de service appropriée selon certains paramètres de QoC (Qualité de Contexte) : i) precision : indique la précision de l information de contexte ; ii) correctnessprobability : représente la probabilité d exactitude de cette information ; et iii) refreshrate : indique de la mise à jour de contexte. La partie réaction au contexte est assimilée par l'entité CAMechanism qui englobe les mécanismes de l adaptation au contexte. Ce mécanisme est attaché à l ensemble des éléments qui représentent les objets influencés par le contexte (la classe CAObject). Cette classe est attachée au service et à ses constituants : Operation, Message et Part. Une instance de la classe Part peut être un paramètre d un Message. Chaque Operation peut avoir un ou plusieurs Messages d entrée/sortie. Et chaque Service offre une ou plusieurs Operations. La classe CAMechanism représente deux mécanismes : ContextBinding et ContextTriggering. La classe ContextBinding modélise une association directe entre l information de contexte et les objets CAObject. Par exemple, associer l information de contexte "Endroit courant de l utilisateur" au paramètre d entrée "Ville" de Operation pour un service donné. Ainsi à chaque fois que le système CAS est invoqué, il fournit automatiquement des informations correspondant à la ville associée à l endroit du demandeur en ce moment. La classe ContextTriggering modélise l adaptation contextuelle d une situation où les services peuvent être automatiquement déclenchés ou modifiés à base de l information de contexte. Elle est composée de contraintes et des actions. Les contraintes sont formalisées selon la logique des prédicats, qui consiste en un opérateur et deux ou plusieurs opérandes. Par exemple harshweather=true, rainlikhood>=80%. Le mécanisme d'adaptation ne peut déclencher des actions que si l'ensemble des contraintes de contexte correspondant à cette action est satisfait. 4 CML (CONTXET MODELLING LANGUAGE) 31

32 Ce travail [11] fait une étude sur les exigences et les caractéristiques de l information de contexte. Cette information expose une particularité temporelle. L information de contexte est jugée imparfaite du fait qu elle peut être incorrecte, inconsistante, incomplète ou même avoir des représentations alternatives. Les concepts de modélisation sont fournis à base d une représentation graphique inspirée du modèle ORM (Object-Role Modeling). Dans ce modèle l information de contexte est structurée autour d un ensemble des entités définies par des attributs, pour aboutir à un langage de modélisation de contexte (Context Modeling Language, CML). Chacune des entités décrit un objet physique ou conceptuel tels qu une personne ou un canal de communication, qui est caractérisée par un rôle joué dans cette structure. La modélisation couvre : - Les activités de l utilisateur dans une forme d un type de fait temporel qui indique les activités passées, présentes et futures, - Des associations entre les utilisateurs et les canaux de communications et les terminaux, - Les emplacements de ces utilisateurs et de leurs terminaux. Dans ce modèle, l information de contexte est évaluée à base de paramètres de qualité selon la source de l information. Il définit une information capturée (Sensed), dérivée (Derived) et l information de profile (Profiled), que chacune a ses propres caractéristiques en terme de qualité. L information capturée est celle récupérée directement de capteurs physiques ou à partir de composants logiciels. Ce type d information se change fréquemment, par conséquent il nécessite la mise à jour et il dépend de l efficacité de l outil capteur. L information dérivée peut être extraite à partir d une ou plusieurs informations. Cette information a des limitations liées au type de l information source. Un exemple de cette information est l information de proximité, qui est extraite de l information de l emplacement géographique. La troisième catégorie de l information de contexte est fournie par les utilisateurs. Cette information est plus fiable que les deux précédentes. La figure II.4 illustre la notation utilisée par le modèle CML, il représente un exemple de modélisation d une application de communication sensible au contexte : 32

33 FIGURE II-4 EXEMPLE D UN MODELE CML Chaque ellipse représente un type objet ; Communication channel, Person (avec la valeur entre parenthèse décrivant le type de représentation utilisé pour ce type d objet ; identity, name). Chaque cadre indique le rôle joué par un type objet, à l intérieur d un type de fait (fact type). Un type de fait est l association entre les types objets. Un exemple de cette association est le type de fait "has Channel" qui contient deux rôles joués respectivement par les types objets Communication Channel et Person. Un exemple d une instance d un type de fait est has_channel[michelle Willi ], où la seconde valeur dans le type de fait identifie un canal par lequel Michelle peut être joint. Une étape suivante à la modélisation de l information de contexte est de traduire le modèle graphique à une représentation relationnelle afin de renforcer la tâche de gestion de contexte et pour supporter le raisonnement. Dans cette nouvelle représentation toute association (un type de fait) de la représentation graphique est devenue une relation. Un exemple illustrant ce modèle : CanUseChannel(person, channel) : 33

34 Cet exemple montre que la situation CanUseChanel() est valide pour une personne person et un canal de communication channel, quand tous les terminaux exigés pour utiliser channel sont à la proximité de person et que celui-ci a la permission d utiliser ces terminaux. Pour renforcer le processus de décision selon le contexte, cette approche fait participer l utilisateur dans cette décision en le permettant de représenter explicitement ses préférences. Deux modèles de programmation ont été mis en œuvre pour mener à bien le processus de décision pour l action appropriée de l application et suivant les préférences de l utilisateur : le modèle Branching et le modèle Triggering. - Branching model : désigné pour aider à la décision sur des choix multiples dépendant de contexte, comme par exemple les canaux appropriés pour communiquer entre les utilisateurs. Un exemple de fonction qui aide à la décision sur un choix selon un contexte : Choice selectbest (Choice[] c, preference p, Valuation v, Context cxt); où ses parameters sont Un ensemble de choix, Une préférence, Des variables de liaison appartenant à la préférence pour les valeurs constantes en s accordant à l état courant de l application, et Un contexte. Cette méthode utilise ces valeurs pour calculer et retourner le meilleur choix. Elle est interrogée par l application au besoin. - Triggering model : orienté événement. Les actions sont invoquées en réponse au changement de contexte. Ce mécanisme suit un modèle de : événement condition action. Il définit trois états de situations (true, false et possibly true) et six transitions d état (TruetoFalse(S), TrueToPossiblyTrue(S)., etc). Un exemple de ce modèle : upon EnterFalse(Occupied("Amy Carr" )) when true do notify of recent missed calls always Où l événement, la condition et l action sont précédés par les mots clé upon, when et do respectivement. Cet exemple a pour effet de notifier l utilisateur «Amy» sur les appels manqués lorsqu il sera libre. 5 MODELISATION DU CONTEXTE POUR LES ENVIRONNEMENTS DE L'INFORMATION Dans cette approche [25], le contexte est considéré comme une propriété qui caractérise une entité de l application. Les éléments sensibles au contexte sont exprimés dans un modèle de contexte qui intègre un modèle de données. Ce modèle s opposent à d autres modèles qui considèrent le contexte comme étant une donnée additionnelle utilisée par 34

35 l application pour réaliser une certaine fonctionnalité. Cette approche est structurée sur un modèle orienté objet. L expressivité de ce modèle est enrichie par les contraintes de cardinalité et les associations entre les objets que possède un modèle orienté objet. Ce modèle est constitué de (voir la figure II.5): - Une classe qui fait l abstraction de la notion de l information de contexte (ContextDomain), utilisée pour caractériser la situation de l entité de l application (ApplicationDomain), - Une classe représentant les sources de l information contextuelle (ContextAcquisition). Ces sources couvrent des capteurs pour les propriétés simples du monde réel telles que la température, aussi bien qu un comportement social compliqué d une entité dans une situation, - Une classe de communication (ContextCommunication), qui associe l ensemble de propriétés de l environnement d exécution d un système avec les entités caractérisés par ces propriétés. FIGURE II-5 MODULES DE META-MODELE Ce modèle propose le concept "TypeSystem" à la modélisation du contexte, afin de fournir une interopérabilité entre les éléments de l application et une compatibilité à l affectation des attributs à ces éléments. Le TypeSystem contient les domaines suivants (voir la figure II.6): - Types qui définissent les entités du domaine de l application ApplTypes telles qu utilisateur, un endroit. - BaseTypes définit les types de valeurs tels qu un entier réel. De plus ce modèle offre le type Bulk, utilisé pour définir une liste des valeurs d un type donné. - ContextTypes définit l ensemble d attributs d un élément de contexte. Ces attributs ont des noms et peuvent être de type BaseTypes, BulkTypes ou même de type ApplTypes. 35

36 Les définissions de ces attributs peuvent être classifiées par l association ofsemanticctegory pour fournir une catégorisation sémantique des attributs. FIGURE II-6 LE MODELE CONTEXT TYPE Répondant à la définition du contexte, l élément de contexte, dans le modèle de la figure II.6, caractérise une entité de l application, illustré par l association hascontextproperty. La contrainte de la cardinalité (1,1) indique que chaque élément de contexte est exactement associé avec une entité application. La cohérence entre l entité de l application et l information de contexte est établie par une association entre Appltypes, et contexttypes que la première classe spécifie les entités de l application ; simples ou composées et leurs classifications sémantiques. La notion d un capteur est utilisée à la modélisation comme un concept abstrait pour représenter un capteur physique ou un composant logiciel. Aussi, le capteur peut être un fournisseur d une information de contexte simple ou composée. Les capteurs suivent le concept de Type. Chaque capteur est une instance de SensorType. La partie réaction au contexte est implémentée en utilisant le principe Subscriber/Notifer. Il consiste à faire notifier le changement de contexte de l application, auprès les entités de l application inscrites à l événement correspondant à ce contexte. 6 LA SENSIBILITE AU CONTEXTE UTILISANT DES POLITIQUES SEMANTIQUES Dans ce travail [26], l'information de contexte a un caractère incertain. La gestion des informations de contexte se fait par une modélisation sémantique du contexte, exprimée par le langage OWL. Le processus de l adaptation est réalisé sur trois étapes : fuzzifing l information de contexte, génération de politiques gouvernant le comportement du système et exécution de ces politiques. - La fuzzification signifie la transformation des éléments de contexte à base des ontologies à un ensemble de termes linguistiques sur une rangée de valeurs de contexte. 36

37 Chaque terme linguistique a une certaine fonction membership qui est utilisée à l inférence. Cette étape est réalisée par la définition de termes linguistiques par l utilisateur et la génération des fonctions memberships. Dans l exemple qui décrit la relation temporelle entre l utilisateur et son poste de bureau [26], on définit les trois termes linguistiques correspondant à cette relation ; Morning, Afternoon et Night. On représente chacun de ces termes par une fonction membership en utilisant la logique floue pour exprimer l incertitude de la situation (voir les figures III.7 a, b et c). Le premier terme, Morning, correspond à la présence d un utilisateur durant le matin entre 8:00 AM et 12 :00 PM. La fonction membership est représentée par un trapézoïde (Figure II.7.a) qui explique qu entre 9 :00 et 11 :00 AM la présence est certaine de cet utilisateur. Le deuxième terme, Afternoon, décrit une fonction triangulaire (Figure II.7.b) entre les heures 11 :00 AM jusqu à 3 :00 PM. Le troisième terme indique l absence de cet utilisateur devant son poste, représenté par la fonction membership Zéro (Figure II.7.c). <Fuzz:hasFuzzyTerm> <Fuzz:FuzzyTerm rdf:id="morning"> <Fuzz:hasMembershipFn> <Fuzz:trapezoidal> <Fuzz:hasFirstpnt>9.0</Fuzz:hasFirstpnt> <Fuzz:hasEndPoint>12.0</Fuzz:hasEndPoint> <Fuzz:hasScndpnt>11.0</Fuzz:hasScndpnt> <Fuzz:hasStartPoint>8.0</Fuzz:hasStartPoint> </Fuzz:trapezoidal> </Fuzz:hasMemberchipFn> </Fuzz:FuzzyTerm> </Fuzz:hasFuzzyTerm> a <Fuzz:hasFuzzyTerm> <Fuzz:FuzzyTerm rdf:id="night"> <Fuzz:hasMembershipFn> <Fuzz:Crip rfd:id="zero"> </Fuzz:hasMemberchipFn> </Fuzz:FuzzyTerm> </Fuzz:hasFuzzyTerm> c FIGURE II-7 FUZZIFYING L INFORMATION DE CONTEXTE <Fuzz:hasFuzzyTerm> <Fuzz:FuzzyTerm rdf:id="afternoon"> <Fuzz:hasMembershipFn> <Fuzz:triangular> <Fuzz:hasCenter>13.0</Fuzz:hasCenter> <Fuzz:hasEndPoint>15.0</Fuzz:hasEndPoint> <Fuzz:hasStartPoint>11.0</Fuzz:hasStartPoint> </Fuzz:triangular> </Fuzz:hasMemberchipFn> </Fuzz:FuzzyTerm> </Fuzz:hasFuzzyTerm> - Le deuxième processus de l adaptation est de construire l arbre de décision flou selon [27]. Cet arbre améliore l inférence, aide à la génération de classification des attributs de contexte et de déclencher des actions dans les environnements sensibles au contexte. - A partir de l arbre induit, on génère les politiques utilisées au processus de l inférence. Tout chemin dans l arbre, de la racine jusqu à la feuille est converti en une politique. Chaque chemin (politique) dans l arbre est récupéré en considérant, que la partie antécédente représente des attributs de contexte de chaque branche qui succède. Par conséquent, à la feuille on trouve la classe avec la valeur la plus élevée de la fonction b 37

38 membersip. L ensemble de ces politiques est représenté en utilisant le langage OWL. L ontologie de politiques a les classes et les propriétés suivantes (figure II.8) ; Policy(issuedBy*, appliesto*, applieswhen*, name*, applieswhere*, priority*, composedofpolicies*, policyrule*, enforcementtype*, equivalentto*, requiresotherpolicies*) o Authorization() o ContextSpecificPolicy(category*, description*) o Obligation PolicyEnforcement() o Instance Inform o instance Negative o instance Positive o instance Restricted Fuzz:Similar(degreeOfCertain*, similarin*, similarto*) o PolicySimilar() Fuzz:FuzzRule(has Antecedent*, hasconsequent*, hasinferencetype*) FIGURE II-8 L ONTOLOGIE DE POLITIQUES Les politiques sont divisées à des politiques d autorisation et d obligation. La classe générique ContextSpecificPolticy, est utilisée par les développeurs d application pour spécifier d autres types de politiques n ont pas citées par ces deux catégories. 7 FRAMEWORK POUR L ADAPTATION DU CONTENU Cette framework [28] aborde l adaptation du contenu (trans-coding) en considérant la diversité des formats du contenu des documents multimédias, les possibilités des terminaux et les préférences des utilisateurs. La tâche d'adaptation est effectuée dans un certain nombre d'étapes, et il pourrait y avoir un certain nombre de configurations possibles pour adapter le contenu de l'expéditeur pour qu il soit présentable sur le terminal du receveur. L adaptation concerne de trouver une chaîne appropriée de transcodeurs (transcoders), entre le fournisseur de service et son récepteur, pour s accorder avec les moyens du terminal utilisateur et en maximisant la satisfaction de l utilisateur par le contenu final du document délivré. La fonction de la satisfaction de l utilisateur est considérée comme un critère décisif à la sélection de l algorithme de QoS. La satisfaction de l utilisateur pour chaque valeur de qualité est exprimée comme une fonction de satisfaction S i (x i ) (voire la figure II.9). Toutes les fonctions ont une gamme de [0..1[ qui correspond à la valeur minimale acceptable (M) et l idéale (I) de x i. La fonction de satisfaction S i (x i ) peut prendre n importe quelle forme à condition qu elle doit être de monotonie croissante sur le domaine. 38

39 FIGURE II-9 FONCTION DE SATISFACTION Après la détermination de critères de sélection, on construit le graphe acyclique direct, en tant que première étape de l algorithme de sélection. Les éléments d un graphe acyclique sont : (1) les sommets du graphe qui représentent les transcodeurs, ou bien les services d adaptation, que chacun a un nombre de liens d entrée (les formats d entrées des transcodeurs) et un nombre de liens de sorties (Les formats de sorties des transcodeurs). Le nœud envoyeur est une case spéciale d un sommet qui a seulement des liens de sorties. Le nœud récepteur est aussi une case spéciale d un sommet qui a seulement des liens d entrée. (2) les bords du graphe qui représentent la connexion du réseau de deux sommets. La construction du graphe commence par le nœud envoyeur. Ensuite connecter le lien de sortie de l envoyeur avec tous les liens d entrée de tous les autres sommets qui ont le même format. Le même processus est répété à tous les sommets. Une fois le graphe est construit, on passe à l algorithme de sélection pour trouver l enchaînement des transcodeurs le plus approprié en commençant par l envoyeur jusqu à l atteint du nœud receveur. Dans cet algorithme de sélection (voir figure II.10) on utilise deux ensembles de transcodeurs : l ensemble qui est considéré effectivement des transcodeurs, appelé VT, et l ensemble de transcodeurs candidats, appelé CS, que leurs entrées sont les sorties de transcodeurs de l ensemble VT. Au début l ensemble VT ne contient que le nœud envoyeur S, alors que CS contient tous les transcodeurs du graphe connectés au noeud S. Dans chaque étape de l algorithme on évalue la satisfaction de l utilisateur pour ajouter un nouveau transcodeur au VT, qui correspond à la plus haute satisfaction de l ensemble CS. Le CS ensuite est mis en mise à jour avec tous les transcodeurs de voisinage. L algorithme s arrête quand l ensemble CS devient vide ou bien quand le nœud receveur est sélectionné pour l ajouter à l ensemble VT Une complète description de l algorithme est donnée dans la figure II.10 : 39

40 Step 1: Let VT = {Sender} be the set of all considered transcoders. Let CS be the set of all downstream neighbors of Sender. Step 2: If CS is empty, then TERMINATE FAILURE) Step 3: Compute the perceived user s satisfaction for all the transcoders in CS. Step 4: Select the transcoder Ti that has the highest satisfaction value. Step 5: If the selected transcoder Ti is the Receiver node, then GOTO step 8 Step 6: Add to CS all the transcoders to which Ti is directly connected. Step 7: GOTO Step 2 Step 8: Print path from the Sender to Ti FIGURE II-10 ALGORITHME DE SELECTION DE TRANSCODEURS APPROPRIES [28] 8 PERSONNALISATION DES APPLICATIONS WEB Personnaliser les applications Web est l'une des pistes de sensibilité au contexte qui concerne d une part adapter la fonctionnalité des applications selon les préférences de l'utilisateur et d autre part respecter des paramètres de fonctionnement de services en terme de QoS. Dans ce travail [30], d'une vision d adaptation architecturale, on aborde l'adaptation dynamique des applications en touchant aux détails structurels et/ou comportementaux de l implémentation de l application Web en associant entre les paramètres de la qualité de service désirée par le client et les paramètres imposés par le contrat SLA (Service Level Agreement). La technologie EJB (Entreprise JavaBeans) de la plate-forme J2EE est conçue pour renforcer la politique de la séparation des préoccupations (Separation of concerns), ce qui en résulte la séparation entre un code fonctionnel décrivant les fonctionnalités du composant métier (i.e. le composant EJB) et un code non fonctionnel qui traverse le code fonctionnel pour en affecter sa performance ou sa sémantique. Pourtant la liaison entre ces deux composants est construite statiquement, ce qui rend l'adaptation dynamique des applications une tâche jugée difficile. La nouvelle architecture proposée redéfinit la liaison qui existe entre le code métier et le code non-fonctionnel des applications pour la rendre dynamiquement reconfigurable. La réalisation de cette reconfiguration dynamique se fait par l introduction de politiques d adaptation écrites en XML. Le rôle de ces politiques est de décrire quand et comment effectuer ces reconfiguration à la volée. Elles indiquent : - Les variations de l environnement qui influencent sur les applications, - Les mesures à considérer pour adapter ces applications aux nouvelles conditions. L élaboration de ces politiques se fait par : - La description des services EJB utilisés (Service.xml), - La définition des règles d adaptation de type Condition Action (Systeme.xml), et - La description de comment vont être appliquées les politiques systèmes et à quels composants (Application.xml). 40

41 A la personnalisation de l architecture, plusieurs changements ont été pris en considération. Ces changements couvrent : - Les configurations des applications liées aux moyens des clients : utilisation de quel terminal, types de réseaux, etc. - Les changements relatifs au contexte d exécution : vérifier si certaines ressources sont toujours disponibles, - Les changements initiés par le client lui-même pour imposer une configuration personnelle. Un exemple de telle politique écrite en XML, est représenté sur la figure II.11, qui a pour but de personnaliser la configuration en fonction du besoin du client : <Configuration> <Terminal type= "PDA" <parameters name="resolution"type="lcd" value "160x160"unit="pixel "/> >parameters name ="RAM" value= "2" unit="mb"/> <parameters name ="CPU" value="300 " unit="mhz"> <parameters name ="OS " value="windowsce"/> </Terminal> </Configuration> FIGURE II-11 EXEMPLE DE POLITIQUE Cette approche met en place une infrastructure d observation composée d une collection de capteurs, qui a pour mission de percevoir les paramètres de l environnement d exécution et détecter les évolutions significatives décrites dans la politique système. La partie inférence est réalisée par le concept moteur d adaptation. Cette entité consiste à appliquer des adaptations selon les politiques imposées. Et ceci en attachant, détachant ou reconfigurant dynamiquement des services EJB aux composants EJB qui constituent l application en question. 9 LES AGENTS MOBILES SENSIBLES AU CONTEXTE Ce travail [6] a l intention de mener davantage d autonomie aux applications à base d agents mobiles afin d adapter dynamiquement leurs comportements aux conditions courantes de leurs environnements. Il propose une extension de l architecture GAMA (Architecture Générique d Agents Mobiles Adaptables), GAMA context-aware. La nouvelle architecture est dotée de deux composants additionnels ; le composant Context-awareness pour raisonner sur le contexte, et le composant Reconfiguration pour la prise de décision sur l adaptation à entreprendre selon certaines politiques fixées à l avance. Cette architecture consiste en trois étapes : - Détecter les paramètres d environnement d exécution de l agent mobile en utilisant des senseurs physiques et des interfaces graphiques. 41

42 - Structurer un modèle de ces informations de contexte à base des ontologies, afin de faciliter leur exploitation par les agents. Cette modélisation est une composition de deux ontologies : - OntoContext est une ontologie qui décrit le contexte d exécution d un agent. Les concepts de l ontologie sont représentés par des classes qui peuvent être décrites en utilisant des propriétés. L ontologie OntoContxt est définit par la classe Context qui représente une abstraction du contexte de l environnement courant de l agent. Cette classe est à la racine de la hiérarchie des sous-contextes caractérisant le contexte de l agent. Cette classe distingue trois sous types de contexte : PhysicalContext, SocialContext et UserContext, pour représenter les différents aspects du contexte. Un exemple de description de CPU, qui constitue un des éléments de contexte physique de l agent : <owl : object Property RDF: ID = "Has-CPU"> <rdfs: range rdf : resource= "#ComputerCPU"/> <rdfs : domain rdf : resource= "#physicalcontext"/> </owl :objectproperty> Où ObjectProperty est une propriété qui représente des relations entre les instances de deux classes. - OntoAgent, décrit la structure propre de l agent en précisant les paramètres qu il est capable de fournir et les paramètres qui sont requis par son environnement d exécution. A la racine de la hiérarchie de cette ontologie se trouve la classe AgentProfile qui représente une abstraction des informations sur la structure de l agent. - Raisonner sur les informations de contexte en déclenchant une auto adaptation suite à une notification d incompatibilité avec le nouvel environnement d'exécution. Le processus d adaptation se compose de trois étapes : (1) instanciation des ontologies ; durant cette étape, le composant Context-awareness instancie les deux ontologies OntoContext et OntoAgent, et notifie si la configuration actuelle de l agent est compatible avec le contexte d exécution visité ou non, qui constitue la deuxième étape ; (2) matching des ontologies et production d une notification. La notification doit aussi porter les informations sur l agent qui a causé cette incompatibilité. La troisième étape : (3) prise de décision de reconfiguration en se référant aux politiques d adaptation. Une politique d adaptation est un ensemble de règles de la forme : When <event_desc> if <gard> do <action> où : <event_desc> est une description d un évènement (le type de notification), <gard> est une expression booléenne indiquant s il y a cohérence entre les attributs équivalents comparés, et <action> est une action décrivant l adaptation à mettre en œuvre tel que le remplacement d un composant existant, l ajout d un nouveau composant ou la suppression d un composant. 42

43 10 COBRA (CONTEXT BROKER ARCHITECTURE) CoBrA [23] est une architecture basée sur un courtier (broker) pour développer des applications sensibles au contexte. C'est un intermédiaire dans un espace intelligent de terminaux et des agents qui a pour rôle de : 1) acquérir et interpréter les informations de contexte ; 2) renforcer la communication entre les agents ; 3) garder les informations personnelles de l utilisateur au partage des informations de contexte et 4) assurer un support de coordination entre les agents. La modélisation de contexte s est faite à base des ontologies en utilisant le langage OWL. Elle définit une ontologie CoBrA (Context Broaker Architecture) qui décrit les relations communes et les attributs associés avec les personnes, les endroits et les activités. La Figure II.12 montre une représentation de définitions clés de l ontologie CoBrA. FIGURE II-12 GRAPHE DE REPRESENTATION DE L ONTOLOGIE COBRA Chaque ovale de ce graphe représente une classe dans le langage OWL. Les ovales avec des lignes entrecoupées indiquent le type de l information que le Context Broker recevra des autres agents et de capteurs de l environnement. Les éléments de contexte sur lesquels est basé la gestion du contexte sont «Person», «Place» et «Intention» (voir la figure II.12); 43

44 - La classe "Person" définit les propriétés générales d une personne dans un espace intelligent. Dans CoBrA, chaque personne doit avoir un nom, une adresse et une homepage URL. Parmi les sous classes qui dérivent de la classe "Person": - La classe "PersonInBuilding" qui définit une des personnes qui sont actuellement dans un bâtiment. - La classe "MeetingParticipant" qui définit un type de personnes qui sont dans une réunion. - La classe "Place" définit les propriétés indiquant l appartenance à un tel endroit ; ispartof et haspartof. Les sous-classes décrites dans cette ontologie sont : UniversityCampus, Building, Room, OtherPlaceInBuilding et MeetingPlaceInBuilding, - La classe "intention" indique la notion des intentions de l utilisateur. Par exemple l intention d un interlocuteur de donner une présentation et l intention d une assistance de recevoir une copie de diapositives de la représentation. Cette classe possède une seule sous classe, SpeakerIntention L adaptation au contexte est réalisé à partir les propriétés et les descriptions des classes et les relations entre ces classes que possède le langage OWL. 11 SYSTEME D'ADAPTATION DE DOCUMENTS MULTIMEDIAS Ce système [31] aborde la technologie P2P. Il propose une solution pour adapter, à la demande, les documents multimédias au contexte des participants d un système P2P. Les internautes accèdent aux documents multimédias proposés depuis des diverses terminaux. Ces dispositifs présentent des caractères variés à travers des réseaux d accès hétérogènes. En outre les utilisateurs exigent que leurs préférences soient prises en compte. Le système proposé, PAAM pour Architecture P2P pour la fourniture de contenus Multimédia Adaptables, fournit un moyen pour trouver les ressources d adaptation et de les composer afin de réaliser des opérations d adaptations complexes. Une description de l environnement du système se fait par des descripteurs : le descripteur de l utilisateur, le descripteur de document multimédia composé et le descripteur d adaptateur. - Le descripteur de l utilisateur comprend ses préférences, les capacités de son terminal et les caractéristiques de son réseau d accès. - Le descripteur de document multimédia contient des informations relatives à chaque média du document. - Le descripteur d adaptateur informe sur les entrées et les sorties de l adaptateur ainsi que sur les adaptations qu il réalise. L architecture du système repose aussi sur des gestionnaires qui, dans un travail collectif, mettent en ordre les données de contexte dans une structure pour faciliter le raisonnement. Ces gestionnaires se composent de : un gestionnaire de contexte, un 44

45 gestionnaire de document composé (GDC), un moteur de prise de décision (MPD) et un gestionnaire d adaptation (GA) ; - Le GC est le responsable d'assembler les informations de contexte, de les filtrer, de les agréer et de les envoyer au MPD. Ce gestionnaire supervise l environnement de l utilisateur et est informé de tout changement significatif de paramètres de l utilisateur. Par exemple : la bande passante ou la connectivité du terminal. - Le GDC est destiné à interpréter les documents composés. Ce gestionnaire peut procéder aux adaptations nécessaires afin de reconstruire le document multimédia final, en tenant compte du contexte de l utilisateur. - Le MPD implémente des algorithmes de prise de décision pour l adaptation de documents multimédia composés. Ces algorithmes utilisent les données traitées par le GC et GDC. Le MPD est définit par des politiques. Ces politiques sont adoptées durant l exécution du processus de décision pour les cas non envisagés dans l algorithme. - Le GA est le responsable de trouver les adaptateurs répondant aux critères de décision de MPD. La recherche d adaptateurs est facilitée par certains critères tels que le type du processus d adaptation, le format d entrée du média et le (les) formats de sortie autorisée du média. Guidé par les préférences de l utilisateur, telles que la connectivité de chaque fournisseur d adaptateurs, leur charge, leurs capacités CPU et la mémoire, et le prix du service offert, le GA construit un graphe d adaptation. Le graphe d adaptation est une collection d adaptateurs composés en séquence ou en parallèle. L architecture proposée est largement inspirée de celle proposée par KaZaa [32] : 45

46 FIGURE II-13 UNE ARCHITECTURE DE FOURNITURE DE DOCUMENTS MULTIMEDIA ADAPTABLES Dans la figure II.13, le flux de données transite via une boucle d adaptation initiée par le pair consommateur qui envoie une requête vers le moteur de prise de décision (MPD). Celui-ci envoie au gestionnaire de contexte (GC) ainsi qu au gestionnaire du document composé (GDC) des lies vers les descriptions des documents multimédia demandés et le contexte de l utilisateur. Par la suite, les données sont traitées par le GC et le MPD envoyées au MPD, qui, guidé par les politiques d adaptation, décide si une adaptation est nécessaire ; dans ce cas le MPD détermine les opérations d adaptations requises. Une fois cette décision est prise, le graphe d adaptation est construit et instancié par le gestionnaire d adaptation (GA). 12 ETUDE COMPARATIVE 12.1 ELEMENTS DE COMPARAISON Pour une étude sur ces systèmes sensibles au contexte une comparaison est portée sur leurs éléments fondamentaux. Particulièrement, notre comparaison porte sur : - Catégorie : une catégorie de l information de contexte est distinguée selon Utilisateur (U), Physique (P), Spatio-Temporel (ST) et Organisationnel (O). Pour chaque travail, nous vérifions les catégories de contexte considérées. - Modèle : un modèle de l environnement de travail, dans lequel est situé un système d adaptation au contexte, porte une grande importance à la conception, l analyse et la mise en marche d un système d adaptation. Dans cette étude on vérifie, si un modèle de l environnement est pris en compte et comment il est présenté. 46

47 - Type adaptation : une adaptation au contexte peut être différenciée selon une réaction et une intégration. Nous examinons quel type d adaptation adopté pour ces travaux. - Qualité : une comparaison des travaux précédents est portée aussi sur la qualité de l information de contexte. - Gestion : nous comparons aussi est ce que la gestion de l adaptation au contexte est centralisée ou bien distribuée. Catégorie Modèle Type adaptation Qualité Gestion Filtrage [13] U et O réaction -- Centralisée ContextUML [20] U, P et ST -- réaction Centralisée CML [11] U, P et ST réaction Centralisée SystemType [22] U, P et ST -- réaction Centralisée Fuzzy [26] ST -- intégration Centralisée Framework [28] U, P -- réaction -- Centralisée Personnalisation [30] U et P -- réaction -- Centralisée GAMA context-aware [6] U, P et O réaction -- Centralisée Cobra [23] U, P et ST réaction -- Distribuée M21 [31] U et P réaction -- Centralisée TABLEAU II.1. COMPARAISON DE SYSTEMES SENSIBLES AU CONTEXTE 12.2 COMPARAISON Ce tableau présente une comparaison de plusieurs travaux qui abordent les systèmes sensibles au contexte, (voir le tableau II.1) : Catégorie : à part le travail indiqué dans [26], qui ne se limite que sur le contexte spatio-temporel, les autres travaux étudiés couvrent les différentes catégories de contexte. Ces travaux utilisent le contexte utilisateur, physique et spatio-temporel. Le contexte social est défini dans [13 et 6]. Il est définit essentiellement par le rôle et le groupe de l utilisateur. Pour la plupart de ces travaux, le contexte est considéré comme une information universelle et non pas dépendante de l environnement de travail étudié. De notre part, nous considérons que l information de contexte peut être définie à partir d une étude sur des exigences de l environnement de travail. Modèle : les travaux présentés dans [20, 22, 26, 28, 30] considèrent que le contexte est une description de l environnement de travail. Pourtant, ils ne proposent aucun modèle de cet environnement. Dans le travail [13], un modèle de l environnement de travail est implicitement défini dans un modèle de contexte. Cet environnement est donné par un ensemble d entités telles que l utilisateur, le terminal, l activité, etc. Cependant, l environnement est considéré comme une entité passive. Il ne définit pas des données telles que des propriétés et des règles qui gèrent les interactions dans cet environnement. Ces données sont définies comme des données internes de l application elle-même et non pas comme des informations définies à partir de l environnement. 47

48 Dans le travail donné dans [11], un modèle de l environnement est aussi confondu dans un modèle de contexte. L environnement est représenté par un ensemble des entités (canal, utilisateur, endroit, etc.) et la relation entre ces entités. Cependant, dans ce travail [11], un modèle de l environnement définissant les points de structure de l environnement n est pas présenté. Les travaux [6 et 23] décrivent un modèle de l environnement à base des ontologies. Une ontologie définit un ensemble des classes qui représentent des entités de l environnement et la relation entre ces entités. Pourtant, un modèle explicite et indépendant de l application n est pas donné. Dans le travail [31], il définit, dans un modèle de contexte, le modèle de l environnement qui est représenté par l utilisateur, les documents supportés et leurs descriptions. Dans ce travail [31], l environnement de travail est aussi considéré comme une partie passive de système d adaptation qui est composé d un ensemble de ressources à exploiter. A partir de ces travaux étudiés, on constate qu un modèle de l environnement qui définit une structure et des responsabilités manque encore pour aboutir à un système d adaptation généralisé et réutilisable. Type adaptation : la plupart des travaux [13, 20, 11, 22, 23, 28, 30, 6, 31] considèrent l adaptation au contexte comme une réaction à l aspect dynamique de l environnement. Ce type d adaptation est considéré comme une adaptation adhoc. Elle associe directement une perception d une information de contexte à une action d adaptation. Ce type d adaptation a une telle efficacité à la sensibilité au contexte. Cependant, ce type d adaptation ne garantit pas une méthodologie généralisée d adaptation au contexte. En outre, une adaptation réactive ne possède pas une représentation interne du modèle de l environnement. Le travail [10] confirme qu une adaptation autonome sans l utilisation d un modèle interne de l environnement de travail est toujours une adaptation extrêmement limitée. Le travail [26] utilise une représentation interne d un modèle de l environnement en montrant la structure des interactions dans un environnement donné. L adaptation décrite dans ce travail [26] concerne l intégration d un système d interactions dans un environnement de travail. Cependant ce travail ne propose aucune méthodologie pour une utilisation généralisée. Dans notre travail, nous adoptons l adaptation par intégration. Ce type d adaptation concerne l analyse de l environnement de travail pour définir les règles et les propriétés qui gouvernent cet environnement. Le processus d adaptation se réalise en imposant des actions qui respectent ces règles et ces propriétés. Dans ce travail, nous proposons une méthodologie d adaptation qui se base sur l intégration. Qualité : la qualité de contexte n est pas traité par les travaux [13,26,28,30,6,23 et 31]. La qualité de contexte concerne deux aspects : la qualité par rapport à la source de cette information de contexte et la qualité par rapport à son utilisation dans l application. La qualité par rapport à la source vérifie la crédibilité des sources et si le contexte est actualisé ou non. Ces travaux [20,11 et 22] ont traité cet aspect. La qualité par rapport à l application vérifie la pertinence de l information de contexte en termes de son utilité dans l application [7]. Dans un environnement mobile, le nombre 48

49 des informations de contexte est grand alors que ce n est pas toute information de contexte est utilisée dans l adaptation. Aucun des travaux étudiés ne proposent un mécanisme de vérification de pertinence de l information de contexte. Gestion : seul le travail indiqué dans [23] assure une gestion distribuée de la capture et de la manipulation des informations de contexte. Pourtant, l utilisation de contexte pour l adaptation est toujours centralisée. Les autres travaux se basent sur une capture et gestion centralisée de contexte. En générale, dans les environnements mobiles, les terminaux mobiles ont des capacités limités de traitements des informations. Par conséquent, la gestion et l adaptation centralisées deviennent un fardeau sur le système sensible au contexte et particulièrement sur un système distribué. Dans notre travail, nous proposons une approche de capture et de gestion distribuée de la sensibilité au contexte. 13 CONCLUSION Les travaux étudiés révèlent une multiplicité de modèles et méthodes pour développer des systèmes sensibles au contexte. Ces travaux sont dits orientés-système. Ils se basent sur des technologies et des méthodes de capture de contexte et de gestion des actions et des services du système suite aux changements de ce contexte. Pourtant, ces travaux représentent des cas d utilisations limitées à des applications particulières. Dans ce travail, nous proposons une approche orientée-environnement de travail. Un système sensible au contexte est destiné à répondre aux besoins de l environnement de travail. Un environnement de travail est une partie indépendante et active ayant des rôles considérables sur le système. En conséquence, l adaptation concernée est considérée comme une intégration de l environnement et non pas comme une sorte de réaction. Dans le chapitre suivant, nous abordons une approche d adaptation basée sur un modèle de l environnement de travail. Ce chapitre fait l objet du travail suivant : - Y. Elghayam, M. Ouzzif, M. Erradi, "Sensibilité au Contexte : Etat de l Art", International Conference On Next Generation Networks & services, NGNS, Fes, Maroc,

50 PARTIE II: Contributions 50

51 Chapitre III : LA SENSIBILITE AU CONTEXTE, UN MODELE DE L ENVIRONNEMENT 51

52 1 INTRODUCTION Une application sensible au contexte est une application qui réagit par un comportement convenable en considérant les informations de contexte de l environnement de travail de l application. L environnement de travail joue un rôle important pour la sensibilité au contexte. Dans les travaux étudiés précédemment, l environnement de travail est considéré comme une partie passive constituée d un ensemble de ressources à exploiter par l application. L adaptation au contexte pour ces applications est une réaction à l aspect dynamique de l environnement. Elle associe directement une perception d une information de contexte à une action d adaptation. Ce type d adaptation permet une réaction en temps réel suite à un changement de l environnement. Cependant, une adaptation réactive n utilise pas un modèle interne de l environnement de travail. Une telle adaptation est considérée extrêmement limitée [10]. Cette vision se complique dans le cas d un environnement de multiples variations de ses paramètres. Par opposition à une adaptation réactive, nous considérons qu une application sensible au contexte doive avoir un rôle intégratif dans un environnement de travail. En conséquence, nous assimilons un environnement de travail à un système qui détient un ensemble de caractéristiques et de propriétés physiques et de règles sociales définissant les conditions de son utilisation. Par une adaptation intégrative, nous désignons qu une application est dite sensible au contexte si ses actions ont pour rôle de respecter et de renforcer les caractéristiques et les règles de l environnement de travail. Le travail de [35] confirme qu un système sensible au contexte a pour but d intégrer un système social. Par l intégration, ce travail désigne, que les possibilités offertes par un système, telles que les actions et les services, doivent respecter et renforcer les propriétés et les politiques d interactions d un environnement de travail (une société). Par exemple, dans le cas d un environnement de travail tel que le théâtre, cet environnement impose le silence. Les services d une application destinés à cet environnement doivent respecter les politiques imposées par cet environnement. En conséquence, l adaptation de service de réception des appels se fait par la réception des appels en mode silencieux. Cependant, ce travail limite le contexte dans l emplacement de l utilisateur. De notre part, on considère qu un contexte peut avoir plusieurs aspects, à savoir un contexte utilisateur, physique, organisationnel et spatio-temporel. La réalisation d une adaptation au contexte qui intègre un environnement de travail se base sur l utilisation d un modèle explicite de cet environnement. D une part, un modèle de l environnement de travail distingue le système social qui indique les principes et les structures d interactions. D une autre part, un environnement de travail est constitué de composants physiques définissant les caractéristiques qui y contraignent les interactions. En conséquence, l adaptation apportée à une application pour réaliser l intégration, concerne deux volets : une adaptation sociale et une adaptation physique. L adaptation 52

53 sociale concerne la considération des règles sociales de l environnement. Par exemple, les exigences imposées par le rôle (social) de l utilisateur. L adaptation physique concerne la considération des ressources et des caractéristiques physiques de l environnement de travail. Dans ce qui suit nous proposons une approche d adaptation au contexte qui se base sur un modèle explicite de l environnement de travail. Ensuite nous proposons comment réaliser l adaptation au contexte par l intégration. 2 MODELE D UN SYSTEME SENSIBLE AU CONTEXTE Un système sensible au contexte est présenté par les éléments suivants : un environnement de travail, des éléments de contexte, un ensemble des actions et un adaptateur au contexte (voir la figure III.1). Tourne dans Système Conscient de Description de l environnement Action Manipule Adaptateur au Contexte Utilise Contexte FIGURE III-1 LES COMPOSANTS D UN SYSTEME SENSIBLE AU CONTEXTE Une action est une abstraction de différents types des réactions de système. Elle peut être - un service dans le domaine des services web, - une simple action d une application telle que désactiver le son lors d un appel téléphonique. - une information à fournir à un utilisateur ou à une autre action. Le contexte, selon la figure III.1, représente l ensemble des informations décrivant l environnement de travail à un moment donné. L environnement de travail et l adaptateur au contexte sont décrits dans les sections suivantes. 3 MODELE DE L ENVIRONNEMENT On désigne par un environnement de travail, l ensemble des entités telles que l infrastructure, les services et les ressources constituant cet environnement. A l environnement de travail, on associe aussi l utilisateur, qui est représenté par des caractéristiques telles que son identité et ses préférences. La définition de l environnement est donné dans [41] par : un environnement fournit les conditions sous lesquelles une entité 53

54 (un objet, un agent) existe. Un environnement de travail est constitué d une part d un système social qui fournit les principes et les structures permettant de régulariser les interactions du système. D autre part, un environnement de travail est composé d un environnement physique fournissant les caractéristiques qui contraignent ces interactions. Par conséquent, on peut en déduire que l environnement est une partie active d un système sensible au contexte et qui a la responsabilité de définir les propriétés et les conditions dans lesquelles un système peut fonctionner. Selon Wynes [10], l environnement définit plusieurs responsabilités : - L environnement impose une structure : l environnement est un espace partagé qui structure des interactions entre des "agents", des ressources et des services. La structuration imposée par un environnement peut être distinguée selon : - Structure physique : réfère à la structure spatiale et topologique. - Structure de la communication: définit l infrastructure d échange de messages. - Structure sociale : réfère à la structure organisationnelle de l environnement en termes de rôles, groupes et sociétés, etc. - L environnement impose des règles : les interactions dans un environnement donné sont soumises à des règles par un domaine particulier (par exemple, la mobilité dans un réseau), ou bien respecter les lois imposées par le constructeur (par exemple, limitation d accès aux nœuds voisins dans un réseau pour une raison de performance). Ces règles peuvent aussi être décrites par les habitudes et la culture associées à des endroits particuliers tels qu un hôpital ou un théâtre [35]. Environnement du Système Elément de l environnement Description de l Environnement service ressource Espace Infrastructure Description Explicite Description Implicite Règles Politiques Interactionnelle Non- Interactionnelle Habitudes Cultures FIGURE III-2 MODELE DE L ENVIRONNEMENT DE TRAVAIL En conséquence, on distingue la description de l environnement selon une description explicite et une description implicite (voir la figure III.2) : 54

55 - La description explicite définit les règles et les politiques régularisant le fonctionnement du système indépendamment de l information de contexte. - La description implicite définit des éléments qui contraignent la description explicite. Elle est distinguée selon une description non-interactionnelle et interactionnelle : - La description non-interactionnelle contient la description des paramètres des infrastructures de réseaux tels que le débit et les paramètres des dispositifs utilisés dans cet environnement tels que la largeur de l écran, la résolution, la puissance de CPU, etc. - La description interactionnelle définit les habitudes, les pratiques et la culture d un groupe de personnes dans un domaine particulier. Dans ce qui suit, nous expliquons comment utiliser la description de l environnement de travail pour définir l adaptation au contexte. 4 MODELE D ADAPTATEUR AU CONTEXTE Selon la figure IV.1, un adaptateur au contexte est une entité d un système sensible au contexte qui a pour rôle de : - Etre conscient de l environnement de travail. - Utiliser le contexte. - Manipuler les actions du système. Premièrement, une conscience de l environnement regroupe la conscience sur les connaissances qui régularisent l environnement de travail. Ces connaissances apportent des exigences sur les interactions du système dans cet environnement [35] ou bien imposent des contraintes physiques sur le système [30, 31]. La conscience de l environnement de travail englobe la description explicite et implicite de cet environnement. Cette conscience constitue le modèle interne de l environnement de travail qu un adaptateur au contexte peut détenir. Le modèle interne contient particulièrement des connaissances sur : - Des régularités : l ensemble des conditions, des normes, des valeurs et des pratiques d un environnement de travail constituent des régularités de cet environnement. Ces régularités y limitent les interactions d une application [35]. Par exemple, dans un environnement de travail, tel qu un hôpital. Une régularité définie par cet environnement est qu un médecin dans une salle de chirurgie ne peut pas utiliser l outil de message instantané pour communiquer avec les autres, vu sa situation qui limite ses mouvements et qui a besoin de plus de concentration sur son travail en cours. - Des références : la description des paramètres physiques des ressources composant un environnement de travail constitue les paramètres de références. Le niveau de batterie d un terminal et le type d images supporté peuvent être des exemples des références 55

56 physiques. A noter que les paramètres de références d un environnement de travail ne sont pas nécessairement fixes, ils peuvent changer continuellement de valeurs. - Des préférences : les préférences de l utilisateur regroupent un ensemble des options imposées par l utilisateur lui-même, telles que la langue, etc. Des connaissances concernant les régularités, les références et les préférences constituent des points d adaptations. Les points d adaptations représentent les connaissances qu un adaptateur doit considérer pour réaliser l adaptation. Une conscience sur ces points d adaptation permet bien de déterminer les objectifs d adaptation. Par exemple, être conscient des régularités de l environnement a pour but d établir une compatibilité des actions de l application avec les exigences décrites par ces régularités. Selon l étude faite dans la partie Etat de l Art : Travaux existants, les objectives d adaptation peuvent être résumés en deux points, la Compatibilité et la Rentabilité : - La Compatibilité : un système sensible au contexte a pour but d établir une compatibilité de ses actions avec les règles sociales et physiques définies dans un environnement de travail [6, 26]. Par exemple, dans un environnement de travail tel que une salle de réunion, la compatibilité est assurée par l activation du silencieux pour recevoir des appels [7]. La compatibilité désigne aussi les caractéristiques physiques de l environnement. Une compatibilité physique peut être représentée, par exemple, par l adaptation de contenu des documents aux caractéristiques physiques d un terminal [31]. En général, la compatibilité peut être réalisée en respectant les régularités de l environnement de travail [26] et les préférences de l utilisateur [13, 11, 28]. - La Rentabilité : la sensibilité au contexte est aussi destinée pour maximiser la rentabilité d un système dans un environnement de travail. Ceci est fait en optimisant l utilisation des ressources de l environnement [37, 38, 39] et en évitant les situations de blocage du système [40]. La rentabilité concerne essentiellement les paramètres de références des ressources de l environnement de travail. La détermination des objectifs d adaptation au contexte permet d invoquer la question pourquoi adapter. La réponse à cette question permet de déterminer, en plus des éléments structurels de l application sensible au contexte, de définir aussi les éléments fonctionnels de l application pour réaliser la phase adaptation au contexte. Deuxièmement, l utilisation de contexte se fait par l identification des éléments pertinents de contexte. Un élément pertinent est celui qui décrit les points d adaptations : qui fait partie des descriptions des régularités de l environnement ou bien qui décrit l un des paramètres des références ou des préférences. Les points d adaptation définissent les paramètres que sans un ajustement de la fonctionnalité de base du système, les objectifs de l adaptateur au contexte, tels que la compatibilité et la rentabilité, ne peuvent pas être réalisés. En conséquence, les points d adaptation représentent les éléments déterminant les informations de contexte. 56

57 Troisièmement, la manipulation des actions du système définit l adaptation désignée par un système sensible au contexte. Dans le paragraphe suivant nous détaillons la manipulation concernée. 4.1 MANIPULATION DES ACTIONS Une adaptation est définie dans [42] par : un ensemble de changements du système pour remédier aux changements de l environnement. Pour un système sensible au contexte, les changements du système regroupent toutes les opérations qui peuvent être subites aux actions du système. Un environnement de travail définit les propriétés dans lesquelles une entité logicielle existe et fournit les principes et les règles qui gouvernent et supportent les interactions dans cet environnement. Dans le travail présenté dans [43], les actions du système sont définies par des préconditions et un effet. Cette définition peut facilement automatiser l intégration des actions dans un environnement de travail. Une pré-condition représente les conditions qui doivent être valides pour l exécution de l action. Ces conditions sont exprimées en fonction des paramètres de l environnement. Un effet d une action peut concerner des données de sortie telle qu une image ou bien un changement d état d une entité de l environnement. On considère que la manipulation d une action se fait par la redéfinition des préconditions ou bien par la modification de l effet de l action. Une redéfinition des préconditions est une manipulation au niveau de la construction alors que la redéfinition de l effet est une manipulation au niveau de l exécution de l action. La manipulation des actions désigne un ensemble des opérations qui peuvent être regroupées selon (voir la figure IV.3): - Sélection : l adaptation d un système peut être effectuée par la sélection d une action parmi plusieurs autres formes d une même action [13,11,22,26,28 et 23]. La sélection concerne la sélection de l action qui a un effet qui répond le mieux à une exigence définie par une description donnée de l environnement. Une description est définie par les paramètres de contexte. - Composition : l adaptation peut être effectuée par la composition de plusieurs actions simples pour construire une action composée [28]. - Redéfinition : la redéfinition concerne le changement de définition des pré-conditions d une action [20,30 et 6]. - Transformation : La transformation concerne la modification des types et des valeurs des informations délivrées à l utilisateur [31]. 57

58 Redéfinition Pré-condition Effet Sélection Composition Changements Appliqués sur Action Transformation Règles Renforcer Relation Compatibilité Rentabilité Extraites de Environnement Caractérise Contexte FIGURE III-3 MODELE DE L ADAPTATEUR AU CONTEXTE Les changements tels que la redéfinition constitue une adaptation au niveau de la construction de l action, alors que la sélection, la composition et la transformation manipulent l action au niveau de l exécution. La figure III.3 montre qu un adaptateur au contexte est un ensemble de changements appliqués sur les actions du système. Ces changements constituent un ensemble de règles extraites de l environnement de travail. Les règles sont désignées pour renforcer la relation entre les actions du système et le contexte : assurer la compatibilité et la rentabilité. Les actions sont manipulées à partir de ses composants : les pré-conditions et l effet. Dans le paragraphe suivant, nous utilisons l ensemble des concepts détaillés ultérieurement pour définir une méthodologie d adaptation au contexte. 5 METHODOLOGIE D ADAPTATION AU CONTEXTE Il y a un grand accord qu un environnement de travail, dans lequel un système sensible au contexte se situe, joue un rôle important dans l analyse, la conception et la mise en opération de ce système. Cependant, ils ne sont pas nombreux les méthodologies d adaptation au contexte qui considèrent l environnement de travail comme point de départ pour l adaptation du système. Une première étape d adaptation au contexte est de définir les éléments instituant cet environnement. Ces éléments, dites points d adaptation, définissent les connaissances régularisant un environnement de travail (les régularités) et les points seuils de cet environnement (les paramètres de références et les préférences de l utilisateur). La méthodologie de la réalisation d un système sensible au contexte passe par les étapes suivantes : - Identifier toutes les actions du système. Ces actions représentent la fonctionnalité minimale du système. Elles sont supposées disponibles et indépendantes du contexte de l environnement de travail. 58

59 - Définir les points d adaptations de l environnement de travail : les régularités, les préférences et les paramètres de références. - A partir de ces points d adaptation, définir les éléments pertinents de contexte. - Trouver pour chaque ensemble de contexte, une configuration de contexte donnée, l ensemble des actions qui répondent aux objectives d adaptation. - Construire les règles d adaptation. A base des configurations extraites et des actions déterminées, construire les règles d adaptations. - Manipuler les actions selon ces règles d adaptation. La manipulation se fait au niveau de la construction ou bien au niveau de l exécution. Cette méthodologie réalise l adaptation d un système dans un environnement de travail. Ceci est fait en définissant les actions du système selon les caractéristiques et les particularités de l environnement de travail. 6 CONCLUSION Dans ce chapitre, nous avons définit une approche de système sensible au contexte. Cette approche se base sur l étude de l environnement de travail dans lequel se situe le système. L étude de l environnement se fait en définissant les points d adaptation. Les points d adaptation constituent les éléments qui instituent les interactions de cet environnement. Les informations de contexte sont des éléments variables définies à partir de ces points d adaptation. Un système est dite sensible au contexte s il détient une représentation interne de l environnement de travail pour réaliser la compatibilité et la rentabilité de ses interactions avec cet environnement. Un adaptateur au contexte constitue un élément fondamental d un système sensible au contexte. L adaptateur au contexte définit un ensemble de changements qui sont décrits à partir d un ensemble de règles. Ces règles sont définies à partir de la description de l environnement. Cependant, La construction des règles d adaptation constitue un grand défi. Ces règles se basent sur un énorme nombre de paramètres décrivant l environnement de travail. Dans ce qui suit nous proposons une approche de construction des règles d adaptation à partir de la description de l environnement de travail en utilisant les arbres de décision. 59

60 Chapitre IV : ADAPTATION AU CONTEXTE BASEE SUR LES ARBRES DE DECISION 60

61 1 INTRODUCTION D après le chapitre précédent, un système sensible au contexte est un système qui est destiné à intégrer un environnement de travail. Par l intégration, nous désignons l ensemble des changements des actions du système pour maintenir les politiques et les propriétés de cet environnement. Maintenir ces politiques et ces propriétés est réalisé par la définition des points d adaptation de l environnement de travail. La définition de ces points d adaptation mène à l identification de plusieurs paramètres de contexte. Nous considérons que l adaptation au contexte est un ensemble de règles pour répondre aux exigences de ces points d adaptation. Les méthodes de construction des règles d adaptation mènent à plusieurs approches [14,44, 45,46]. En général, ces règles sont sous forme de conditions-actions. Les conditions expriment les différentes situations définies par des éléments de contexte et les actions forment les adaptations apportées au système. Dans un environnement mobile, le nombre des éléments de contexte est grand, ce qui pourrait générer plusieurs situations de contexte à considérer. Par conséquent, plusieurs règles d adaptation à construire. Selon Guan [46], pour la plupart des travaux, la distinction de l information de contexte la plus utile pour l utiliser dans la construction des règles ne subit aucune vérification. L absence d une méthode de vérification mène à des effets moins favorables et parfois alourdissent le traitement et le stockage de ces informations de contexte [14]. En outre, ces règles sont, en général, définies par l utilisateur lui-même (user-defined rules). Un utilisateur énumère, intuitivement, toutes les situations possibles pour la construction des règles d adaptation. Cependant, dû au large nombre des éléments de contexte, les règles définies par l utilisateur sont qualifiées par incomplètes et erronées [46]. Comparée avec les règles définies par l utilisateur, la construction des règles basées sur les méthodes d apprentissage a montré une meilleure performance [46]. L adaptation basée sur les méthodes d apprentissage consiste en la déduction, à partir d un large nombre des éléments de contexte, des régularités exprimées sous forme de règles générales. Ce qui permet de remédier au problème d utilisation des éléments inutiles de contexte. Parmi les méthodes d apprentissage les plus utilisées on trouve les réseaux de neurones [47] et les arbres de décisions [48]. Dans le travail cité dans [49], il considère que les arbres de décision sont plus efficaces et plus faciles à manipuler. Dans ce qui suit, nous proposons une méthode d adaptation au contexte basée sur les arbres de décision. Nous commençons par montrer un cas d étude, qui explicite l utilisation de notre approche. Nous montrons un modèle de construction des arbres de décision, puis nous détaillons l utilisation de ce modèle pour la construction des règles d adaptation. 61

62 2 CAS D ETUDE : UN TELEDIAGNOSTIC COLLABORATIF Dans un centre hospitalier, des médecins (professeur, résident ou interne) peuvent intervenir dans des sessions de collaborations. Un médecin peut solliciter l avis des autres médecins participants dans la même session à propos d un patient ou bien faire part de ses propres expériences pour un malade d un autre médecin. Les médecins peuvent communiquer depuis leurs postes de travail de leurs bureaux, aussi bien que depuis leurs terminaux mobiles (PDA, Laptop) en se déplaçant dans les différents endroits de l hôpital (voir la figure IV.1) : le bureau, la salle de chirurgie, la salle de consultation, etc. Supposons qu aux urgences, un patient diabétique qui se présente avec une hypertension artérielle (HTA), un malaise, une glycémie, une insuffisance rénale (IR) et des douleurs abdominales de type chirurgical. L interne de garde est devant un problème de diagnostic ; pourquoi la glycémie est élevée? La douleur abdominale, s agit il d une nécrose intestinale (une partie morte de l intestin)? Qui est la cause de l IR? Et comment expliquer l HTA? L interne de garde se trouve dans l obligation d interpeller les médecins dont les spécialités sont relatives au cas de ce patient. L interne de garde appelle le chirurgien. Le chirurgien arrive après un certain délai pour examiner le patient et décide que la suspicion n est pas solide et que les douleurs peuvent être en rapport avec le taux élevé de potassium (k+). L interne appelle le néphrologue. Après l examen, ce dernier juge que ce patient ne nécessite pas l hémodialyse et que le problème de l HTA doit être réglé en urgence pour ne pas aggraver son IR. L interne se trouve obligé de convoquer le cardiologue pour lui demander, de son côté, son intervention relativement à l HTA. Ce patient représente un cas complexe que chacun des médecins ne peut pas assumer la responsabilité de la décision de diagnostic tout seul. Ce qui perdra considérablement un temps déterminant pour la vie du malade. Cependant, si on utilise les différents outils de communication possibles, en profitant des technologies de l environnement mobile, on peut réaliser une collaboration entre tous les médecins des différentes spécialités (voire la figure IV.1). Cette collaboration permet de discuter les diagnostics probables de ce malade, les priorités de prise de décision et les attitudes thérapeutiques adéquates. En outre, la réalisation de cette collaboration permet de : - Eviter l évolution défavorable de sa maladie, due aux pertes de temps relatifs à l attente de chaque spécialiste séparément. - Un délai de séjour dans le service des urgences très abrégé, - Aboutir à une attitude optimale acceptée par tous les médecins et qui serait la plus bénéfique pour le patient. 62

63 FIGURE IV-1 UTILISATION DE RESSOURCES PARTAGEES LORS D UNE COLLABORATION Nous faisons plusieurs remarques sur ce scenario. L environnement médical est un environnement critique qui touche la vie des être humains. Par conséquent, pour un système de télédiagnostic collaboratif, il exige : - Une forte disponibilité des médecins. Un médecin doit être joignable à n importe quel moment et à n importe quel endroit en se disposant de tous les outils possibles : la vidéo, l audio, les messages instantanés et les s vocaux. - La concentration des médecins sur leurs interventions médicales ne doit pas être gênée par la configuration des terminaux et des outils utilisés. 3 ANALYSE DE CAS D ETUDE : A partir de ce scénario, on peut en extraire les points d adaptation suivants : - Références : les propriétés physiques de cet environnement de travail sont principalement extraites de caractéristiques de type de terminal utilisé (laptop, PDA, etc.) et de type de connexion (filaire ou non filaire). - Préférences : l utilisateur peut lui-même préciser sa disponibilité indépendamment de son endroit ou de son activité en cours. - Régularités de l environnement : Régularité1 : la salle de chirurgie est un endroit critique. Le degré de liberté, pour des activités de collaboration, d un médecin dans une salle de chirurgie est plus limité qu un médecin dans une salle de consultation ou dans son bureau. Régularité2 : un médecin en cours d effectuer une opération chirurgicale ne peut pas être interrompu mais peut être intervenu discrètement (utiliser une 63

64 communication vocale au cas d urgence ou bien des s vocaux au lieu des messages instantanés). De ces points d adaptation, on peut bien définir les éléments de contexte suivants : - Localité : cet élément de contexte joue un rôle primordial dans ce scénario de télédiagnostique. Il est définit à partir des régularités de l environnement. Il peut prendre comme valeurs : salle de chirurgie, salle de consultation et bureau. - Disponibilité : cet élément de contexte peut être défini soit à partir les préférences de l utilisateur soit à partir des régularités de l environnement. Il prend comme valeur : Oui ou Non. - Connectivité : cet élément de contexte est l élément principal défini à partir les paramètres de références de l environnement de travail. Il prend comme valeur : Oui ou Non. Dans ce qui suit, nous décrivons l algorithme de la construction de l arbre de décisions. 4 MODELE DE L ARBRE DE DECISIONS L algorithme de construction de l arbre de décision se base sur les concepts : variable discriminante, classe et ensemble des échantillons. Une variable discriminante est une variable à plusieurs valeurs constituant les nœuds de l arbre. Dans notre cas, les variables discriminantes représentent les éléments de contexte. Une classe représente la décision prédite par l arbre, elle se situe aux feuilles de l arbre. Dans notre contexte, les classes représentent les décisions d adaptation à faire. Ces décisions incluent des règles tracées par l arbre. Chaque branche de l arbre, de la racine à une feuille constitue une règle. L ensemble des échantillons représentent des observations faites sur le domaine étudié. Ces échantillons sont construits par l énumération de toutes les combinaisons possibles des différentes valeurs de variables discriminantes et les classes. L ensemble des échantillons est itérativement partitionné, basés sur les valeurs des discriminants, jusqu à arriver à un sous ensemble menant à une seule classe. Dans la figure suivante, la figure IV.2, nous montrons le flux de données pour la construction des règles de décisions basées sur l arbre de décisions. Un algorithme de construction d arbre de décision prend à l entrée l ensemble des variables discriminantes (Attributes) et les classes. Chaque variable a plusieurs valeurs (Attributes values). Initialement, l ensemble des échantillons (data samples) est construit à base de la combinaison des variables et des classes. Puis, cet ensemble est utilisé par l algorithme de l arbre de décision (DT algorithm) pour fournir des règles (Decision Tree rules). 64

65 Attributes values Attributes Data Samples Decision tree rules Classes Figure IV-2 Les flux de construction des règles de décisions Formellement, étant donné D l ensemble des échantillons constitués de M échantillons et N classes étiquetées par C i, 1<=i <=N. Soit m i le nombre des échantillons de D menant à la classe C i. La classification de ces m i est définie par N I( C) pi log pi (1) i 1 I(C) mésure l homogénéité des échantillons. p i est la probabilité des échantillons appartenant à la i éme classe. p i est estimé par p i = m i / M. Les décisions sont dépendantes de A, l ensemble des variables discriminantes, tel que A=( A 1, A 2,,A N ). Chaque variable A q, 1<=q<=N, contient k distinctes valeurs (A q1, A q2,..., A qk ). Ces valeurs partitionnent l ensemble D à des sous-ensembles (D 1, D 2,..., D k ) où D j, 1<=j<=k, est le sous-ensemble des échantillons contenant les valeurs A qj de A q. Soit m ij est le nombre des échantillons de la i ème classe appartenant au sous ensemble D j. Le gain d entropie est calculé pour mesurer l impureté après le partitionnement de D à D j par A. Pour une variable donnée V q : Gain( Aq) I( C) ( Aqj Valeurs ( Aq)) mij I( C A D q Aqj ) (2) L algorithme de base pour induire l arbre de décision à partir d un ensemble des échantillons : - Initialement l arbre de décision est considéré comme un seul nœud représentant tout l ensemble des échantillons. - Si tous les échantillons appartiennent à la même classe, ce nœud devient une feuille et étiqueté par cette classe. - Sinon, une entropie de gain est calculée pour sélectionner la variable discriminante qui sépare bien les échantillons à des classes individuelles. Cette variable correspond au gain calculé le plus élevé. - Une branche est crée pour chaque valeur de cette variable de gain supérieur et les échantillons sont partitionnés selon ces valeurs. 65

66 - L algorithme construit, récursivement, les autres nœuds en utilisant les sous-ensembles de chaque partition. Une fois une variable utilisée, elle n est pas considérée dans les nœuds descendants. - L algorithme s arrête quand tous échantillons d un nœud donné appartiennent à la même classe ou bien il ne reste plus d échantillons. Dans les paragraphes suivants, nous détaillons l utilisation de ce modèle de l arbre de décisions dans la construction des règles d adaptation. 5 ADAPTATION AU CONTEXTE 5.1 MODELE DE CONTEXTE Selon la méthodologie proposée dans le chapitre précédent, les éléments de contexte sont définis à partir les points d adaptation de l environnement de travail. Dans l environnement de travail donné dans le cas d étude, L ensemble des éléments de contexte est une conjonction de plusieurs sous ensembles : Utilisateur, Physique, Organisationnel et Spatio-temporel. Pour chaque sous-ensemble de contexte C x (x є (U, P, O, ST)), nous définissons un ensemble des éléments de contexte : C x = (C X1, C X2,..., C Xn ). Par exemple, le sousensemble de contexte spatio-temporel est définie par : C ST = (C ST1, C ST2 ) tels que C ST1 = Location et C ST2 = Time. Dans le cas d une application de télédiagnostic, le contexte Location peut avoir plusieurs valeurs C ST1 =( CHIRURGICAL_ROOM, CONSULTATION_ROOM, OFFICE ). La fonction V permet d avoir k-uplet valeurs pour un contexte C xn dans un moment donné : V(C xn, t) = <v 1 (t), v 2 (t),, v k (t) > / v i (t) = 1, 0 (3) - la valeur 1 correspond à la valeur de contexte valide à l instant t. - la valeur 0 signifie que la valeur de contexte n est pas utilisé à l instant t. Après que chaque valeur d un élément de contexte est enregistrée, l ensemble des attributs représentant la situation de l utilisateur u à l instant t est : S(u, t) = i V(C kij, t) (4) k : représente la catégorie de contexte i : représente l élément de contexte. j : représente l une des valeurs de l élément de contexte. 5.2 ARCHITECTURE Une architecture d un système sensible au contexte est composée de deux parties (voire la figure IV.3) : la partie environnement du système (System Environment) et la partie gestion de contexte (Context Management) ; la première partie est contient les éléments de base de fonctionnement d un système d interactions, il est composé de : 66

67 - Fonctionnalité de Système (System Functionality): ce composant contient les actions et les services fournis par le système. Il représente le business logic du système. Ces actions et ces services sont indépendants de contexte et sont supposés toujours disponibles. Pour le cas du scenario indiqué précédemment, la fonctionnalité du système représente les actions et les services qui assurent la gestion et le contrôle des sessions de collaboration. Cette fonctionnalité peut être fournie par deux composants : le composant de gestion de groupe et le composant de gestion de ressources. Le composant de gestion de groupe permet la gestion des membres participants dans une session de collaboration. Ce composant traite les services de création/terminaison d une session et les services de jointure/départ d un participant. Le composant de gestion de ressources assure les services de gestion de ressources pendant une session de collaboration tels que donner, retirer, mettre en attente et rejeter une la permission d utilisation d une ressource. Les ressources utilisées concernent la vidéo, l audio, les messages instantanées et les s vocaux. - Gestion de la fonctionnalité du système (System Functionality Management) : ce composant contrôle et manipule les services fournis par le système. Ce contrôle réalise les adaptations indiquées par l engin d adaptation. Ce gestionnaire est considéré comme un réalisateur de l adaptation. La réalisation de l adaptation peut être faite par la redéfinition de l action/service, la sélection entre plusieurs formes disponibles, la composition de plusieurs éléments de base ou bien la transformation d un service pour le cas des données multimédias. FIGURE IV-3 ARCHITECTURE D UN SYSTEME D ADAPTATION BASEE SUR LES ARBRES DE DECISION 67

68 La partie Gestionnaire de contexte (Context Management) est composé de : - Construction des règles (rules Construction): ce composant sert à construire les règles d adaptation à base de l algorithme des arbres de décision. La construction se base sur le rassemblement de l ensemble des situations potentielles de l environnement de travail. Ces informations sont stockées dans le composant Observed Facts. - Capteurs (Monitoring Framework) : ce composant est constitué de plusieurs capteurs physiques et logiques pour capturer les informations de contexte de l environnement de travail en tout moment. - Modèle de contexte (Context Model): ce composant donne une structure normalisée de l information de contexte et des situations de contexte afin de faciliter leurs manipulations. La structure adoptée dans ce travail est la structure selon le schéma XML. - Engin d adaptation au contexte (Context Adapter Engin): ce composant prend en entrée l information de contexte capturée à un moment donné et les règles de l arbre de décision. Il fournit à la sortie l action appropriée en positionnant la situation de contexte de l environnement de travail dans l arbre de décision. 5.3 CONSTRUCTION DES REGLES Pour utiliser l arbre de décision, nous avons besoin d un ensemble D des échantillons extraits de l environnement de travail. Chaque échantillon est une combinaison de plusieurs valeurs des variables de contexte. Un échantillon contient aussi une des décisions qui s accorde avec les valeurs de contexte. Reprenons le scénario décrit précédemment, on considère que pour établir la collaboration entre les différents médecins, le système dispose d un ensemble de ressources : vidéo, audio, message instantané et vocal. L environnement de travail est contrarié aux éléments de contexte suivants : la connectivité, la disponibilité et la localité. L attribution de ressources appropriées est considérée comme la décision (l adaptation) à prendre selon ces éléments de contexte. Par exemple, un utilisateur dans une salle de chirurgie ne peut pas collaborer en utilisant les messages instantanés, puisque sa localisation (son contexte) l oblige. Pour chacun des éléments de contexte, on détermine les valeurs suivantes : - Connectivité : Oui Non - Disponibilité : Oui Non - Localité : Salle de chirurgie Salle de consultation Bureau. L une des combinaisons de ces valeurs de contexte donne une situation de l utilisateur à un instant t. Une situation de l utilisateur est obtenue à partir de la relation (4). Par exemple, quand un utilisateur u i (un médecin), à un instant t, est connecté à l application, disponible et localisé dans la salle de chirurgie, la ressource considérée la plus appropriée à lui attribué est l audio. Donc, selon la relation (3), nous avons V(Connectivité, t) = <1,0>, 68

69 V(Disponibilité, t)=<1, 0> et V(Localité, t)=<1,0,0>. D où la situation de l utilisateur u i à l instant t selon la relation (4) est définie comme suit : S(u i, t)= V(Connectivité,t) V(Disponibilité,t) V(Localité,t)=( Oui, Non, Salle de chirurgie ). Si on attribue la ressource audio à cette situation de contexte, nous complétons un échantillon d j є D tel que d j = (S(u ij, t), c k ), c k correspond à l une des ressources à attribuer. c k є C= (Video, Audio, et Message instantané). Dans l annexe I, nous présentons les différents échantillons. Par analogie, nous avons construit trente huit échantillons [36, 63]. L algorithme de l arbre de décisions a pour but de classifier les sous ensembles des échantillons qui appartiennent à la même classe. Pour cela, initialement, nous calculons la valeur de gain en entropie pour chaque élément de contexte afin de sélectionner celui qui classifie au mieux les échantillons selon les classes. On a trouvé que l élément de contexte Connectivité correspond à la plus grande valeur de gain en entropie (voir la figure IV.4). Pour cet élément de contexte, les échantillons sont distribués selon (7,6,6,13,6). Ceci signifie que le numéro 7 représente sept échantillons d j de l ensemble des trente huit échantillons qui incluent le contexte Connectivité indépendamment des autres valeurs des éléments de contexte et qui mènent à la classe audio. De même pour le numéro 6, il signifie que six échantillons d j de l ensemble des trente huit échantillons incluent le contexte Connectivité et mènent à la ressource vidéo. De même pour les autres numéros, ils signifient le nombre des échantillons contenant le contexte Connectivité et menant, respectivement, aux ressources Image, vocal et Message instantané. En outre, pour chaque valeur de contexte Connectivité (l élément de contexte ayant la plus grande valeur de gain en entropie), une branche est crée qui correspond aux valeurs de ce contexte : Oui et Non. L algorithme de l arbre de décisions partitionne les échantillons en deux sous ensemble selon les valeurs oui et Non. Selon la figure IV.4, on a : (7,6,6,13,6)= (7,6,6,6,6) + (0,0,0,7,0). Ceci montre une nouvelle distribution des échantillons selon les valeurs de ce contexte. Par exemple dans le cas où la valeur de contexte Connectivité prend la valeur Non, nous avons seulement sept échantillons menant à la ressource vocal. Le calcul de gain en entropie est une procédure répétitive pour construire les autres nœuds de l arbre. Pour cela à chaque branche, la valeur de gain en entropie est recalculée pour les autres éléments de contexte en ne considérant que les échantillons qui figurent sur cette branche. Par exemple, sur la figure IV.4, entre les niveaux deux et trois : les échantillons appartenant à la valeur Oui pour le contexte Connectivité sont divisés selon les valeurs de contexte Disponibilité ( Oui et Non ) : (7,6,6,6,6)= : (7,6,6,0,0)+ : (0,0,0,6,6) (A noter que le contexte Disponibilité correspond à la valeur de gain en entropie la plus grande pour les échantillons appartenant à la valeur Oui pour le contexte Connectivité ). La construction des sous-arbres s arrête lorsque tous les échantillons d un nœud appartiennent à la même classe. Par exemple la valeur Non pour le contexte 69

70 Connectivité menant à la classe vocal (première branche à droite). La construction de l arbre s arrête aussi lorsqu il y a plus des éléments de contexte qui ne sont pas encore utilisés. FIGURE IV-4 CONSTRUCTION DE L ARBRE DE DECISION L arbre de décision construit est transformé à un ensemble de règles. Chaque branche, venant de la racine à la feuille, représente une règle. Par exemple, sur la première branche à droite, si un utilisateur n est pas connecté alors seule la ressource vocal peut être utilisée pour communiquer avec cet utilisateur. Alors que sur la première branche gauche, si un docteur est connecté, disponible et qui est dans la Salle de chirurgie, cet utilisateur peut avoir seulement la ressource audio pour la communication. 6 CONCLUSION Dans ce chapitre nous avons décrit une approche de construction des règles d adaptation en se basent sur les arbres de décisions. Au cours de ce chapitre nous avons aussi présenté, respectivement, les modèles de l arbre de décision et de contexte. Une architecture d un système sensible au contexte est aussi présentée. Cette architecture est désignée, dans un premier lieu, pour être centralisée. La gestion et l adaptation au contexte sont focalisées dans une seule entité dans l architecture. Dans le chapitre suivant, nous améliorerons notre approche par l introduction d une gestion distribuée. Les résultats de ce chapitre font l objet des publications suivantes : - Y. Elgahyam, et M. Erradi, "Decision Tree Based Context Management in a Collaborative Environment", Proceedings of New Technologies of Distributed Systems (NOTERE), pp , Tozeur, Tunis,

71 - Y. Elgahyam, M. Erradi et M. Ouzzif, "An LTL Specification and Verification of a Mobile Teleconferencing System", International Workshop onverification and Evaluation of Computer and Communication Systems, VECoS, Leeds, UK, Y. Elgahyam, M. Erradi et M. Ouzzif, "Vers une Plateforme Collaborative Mobile pour le Télédiagnostic", First International Conference of E-medical systems, E-MedSys, Fes, Maroc,

72 Chapitre V : GESTION DISTRIBUEE DE LA SENSIBILITE AU CONTEXTE 72

73 1 INTRODUCTION La sensibilité au contexte est un besoin imposé, à priori, par l avènement de l environnement mobile. Cet environnement favorise la création de nouvelles formes d applications mobiles. Les applications mobiles permettent aux utilisateurs de se déplacer en maintenant les interactions avec l application. Dans le cas, par exemple, des applications de télémédecine, un médecin peut maintenir sa session de collaboration active tout en se déplaçant dans les endroits du centre de l hôpital et en s engagent dans d autres activités. Cependant, dans ce genre d applications, les équipements utilisés (utilisation des terminaux mobiles légers avec des réseaux sans fils) sont caractérisés par leurs fragilités en termes de nombre de données à traiter ou à transmettre. Dans le cas d un système sensible au contexte, d autres traitements sont ajoutés à la logique de l application. Ces traitements, qui concernent les processus de la sensibilité au contexte, sont constitués particulièrement de la capture, la gestion et l adaptation. Par conséquent, pour la plupart des applications, ces traitements deviennent un fardeau sur l application. L une des visions universelles pour la bonne gestion dans de tels cas est la division des tâches pour mieux gérer. Par diviser les tâches nous désignons la division des traitements concernés par la sensibilité au contexte sur plusieurs entités à la place de garder les traitements centrés sur une seule entité. Pour réaliser la distribution des tâches nous adoptons le concept de l agent mobile. Un agent mobile gagne sa force du fait qu il est caractérisé par une autonomie de décision. Telle caractéristique permet à un agent mobile d avoir l autonomie de détecter le changement de contexte associé à un utilisateur et de décider indépendamment sur l adaptation appropriée. Cette autonomie permet d assurer la distribution des tâches de la sensibilité au contexte sur plusieurs entités de l application et par la suite atténuer la charge de traitements sur l application. Les agents mobiles sont aussi caractérisés par leurs dispositions de se déplacer entre les terminaux. Cet avantage peut bien être utilisé pour assurer la continuité de services. Dans le cas d un terminal de ressources épuisées, l agent mobile peut changer de terminal vers un autre qui est plus qualifié tout en gardant le même état d exécution. Le déplacement d un agent peut se faire soit en migrant ou bien en effectuant un clonage. Au cours de ce chapitre, nous commençons par détailler les exigences imposées par un environnement mobile. Nous présentons un modèle de l agent mobile. Nous montrons ensuite l architecture de gestion distribuée de la sensibilité au contexte et l algorithme de gestion de ressources de l environnement de travail. 2 EXIGENCES Dans ce qui suit, nous citons certaines exigences relatives à un environnement mobile et distribué: - Un code léger : dans les environnements mobiles, les terminaux utilisés sont, en général, de type PDA, Smartphone ou Laptop. Ces dispositifs sont caractérisés par leurs capacités limitées. Généralement, ces terminaux sont équipés par une autonomie restreinte. De 73

74 plus, dans ces environnements les réseaux de connections utilisés sont les réseaux sans fil tels que le WLAN et le Bluetooth dans les PAN. Ces types de réseaux sont caractérisés par leurs basses bandes passantes. Par conséquent, les applications mobiles supportées par ce genre d environnements doivent être conscient de ce manque de ressources en utilisant un code léger. Ceci peut être réalisé par la division de la charge de travail (workload) sur plusieurs entités. - Une mobilité et une hétérogénéité cachées : les utilisateurs dans un environnement mobiles distribués se déplacent fréquemment et peuvent utiliser des terminaux de différentes caractéristiques (en terme de caractéristiques de l écran, l OS utilisé, etc.) sur diverses réseaux de connectivités. L hétérogénéité peut concerner aussi les environnements de développements (J2ME, Android, etc.) sur lesquels tournent les applications et les services. En conséquence, les applications mobiles doivent être dotées de mécanismes capables d absorber cette hétérogénéité et traite la mobilité des utilisateurs pour garantir des interactions plus efficaces. - Indépendance des entités (loosely coupled) : dans les applications mobiles, et particulièrement pour les applications collaboratives, certaines interactions peuvent être dépendantes, voir même concurrentes (par exemple le partage des ressources de collaboration). Dans le cas d un environnement de gestion centralisée, une interruption inattendue de l une des interactions peut impliquer un état de blocage du système [50, 64]. Ces interruptions peuvent être suite à des déconnections involontaires (batterie épuisée, zone non couverte, etc.). Par conséquent, telles applications exigent de permettre une gestion distribuée en assurant des autonomies aux entités [51] pour réaliser l indépendance des entités et par conséquent éviter les situations de blocage du système. Il y a des questions ouvertes, parmi autres, qui ont besoin de réponses ; comment remédier aux caractéristiques physiques de l environnement mobile (le terminal et le réseau de connexion) ; comment répondre à l hétérogénéité de l environnement et comment réaliser l indépendance des entités. Dans ce qui suit nous répondons aux questions relatives aux caractéristiques des terminaux limitées et à l indépendance des entités. Cependant répondre à la question de l hétérogénéité est considéré comme l une des perspectives de ce travail. Dans le paragraphe suivant, nous détaillons le modèle de l agent mobile utilisé, et comment le concept d un agent mobile pourrait remédier aux exigences de l environnement mobile. 3 MODELE DE L AGENT MOBILE Un agent mobile est une entité autonome capable de communiquer, disposant des informations de ce qui l'entoure et d'un comportement privé, ainsi que d'une capacité d'exécution propre. Un agent peut réagir et interagir avec d'autres agents. Un agent mobile peut se déplacer d'un site à un autre en cours d'exécution pour accéder à des données ou à des ressources. Il se déplace avec son code et ses données propres, mais aussi avec son état d'exécution. L'agent mobile décide lui-même et de manière autonome de ses mouvements. Ainsi, la mobilité est contrôlée par l'application elle-même, et non pas par le système 74

75 d'exécution comme dans le cas de la migration de processus dans les systèmes opératoires [52]. Vue les caractéristiques du concept de l agent mobile (mobilité et autonomie), il est bien bénéfique pour les systèmes sensibles au contexte. Il assure l efficacité et la flexibilité des interactions dans un environnement mobile. Un agent mobile peut bien réduire la complexité d un environnement distribué en se basant sur la délégation et en partagent les tâches. Cependant, la plupart des travaux qui adoptant les agents mobiles ne profitent pas des propres caractéristiques de ces agents mobiles pour incorporer les mécanismes de la sensibilité au contexte, tels que la capture, la gestion et l adaptation de contexte [53, 54]. Ils se limitent seulement à utiliser ces caractéristiques pour assurer la distribution du processus métier de l application. Dans ce travail, voir la figure V.1, un modèle d un agent mobile est défini par deux composants : le composant fonctionnalité de la sensibilité au contexte (Context-awareness functionality) et le composant fonctionnalité de base de l agent mobile (MA basic funtionality). Le premier composant est destiné pour assurer les processus de la sensibilité au contexte. Il capture les informations de contexte de l utilisateur associé à l agent mobile, gère et adapte les actions de l utilisateur selon ces informations de contexte. Le deuxième composant assure les fonctionnalités de base de sa création, son déplacement et pour les interactions avec son environnement. User1 Mobile Agent1 Context-awareness functionality MA basic functionality User2 Mobile Agent2 MA basic functionality Environment System Context-awareness functionality FIGURE V-1 MODELE D UN AGENT MOBILE Dans le paragraphe suivant, nous décrivons l utilisation du modèle de l agent mobile pour assurer la gestion distribuée de la sensibilité au contexte. 4 ARCHITECTURE D UNE GESTION DISTRIBUEE BASEE SUR L AGENT MOBILE Nous proposons une architecture autour les agents mobiles. Cette architecture, comme c est montré sur la figure V.2, est structurée à partir les composants suivants : le composant session utilisateur (User Session), le composant agent mobile (Mobile Agent (MA) component), le composant gestionnaire d agent mobile (MA Manager) et le 75

76 composant système collaborative (Collaborative System). Ces composants sont décrits comme suit : - User Session: représente l ensemble des fonctions et outils disponibles à l utilisateur pour interagir avec les fonctionnalités du système. - Mobile agent: il détecte les éléments de contexte (connectivité, disponibilité et localisation de l utilisateur) à partir de l environnement de système durant une session de collaboration afin de permettre des services adaptés au contexte de l utilisateur. Pour ceci, un agent mobile utilise un ensemble des capteurs physiques et logiques. Par exemple, la localisation de l utilisateur peut être détectée en utilisant l une des technologies suivantes : Active badge, RFID, GPS. La disponibilité de l utilisateur est déterminée à partir de l interface de la session utilisateur (User Session). Ce paramètre est spécifié par l utilisateur lui même. L agent mobile permet la gestion des informations de contexte et l adaptation des actions du système collaboratif selon ces informations de contexte. User1 User Session Context parameters Mobile Agent1 Context-awareness functionality MA basic functionality Mobile Agent Manager System Functionality Management Collaborative System System Functionality MA basic functionality Mobile Agent2 Context-awareness functionality User2 User Session FIGURE V-2 ARCHITECTURE DE GESTION DE COLLABORATION BASEE SUR LES AGENTS MOBILE - Gestionnaire de l agent mobile (MAM) : représente le composant responsable de la création et de la suppression d un agent mobile. Il maintient des informations sur les agents crées tels que leurs identités et leurs localités. Le MAM peut à tout moment 76

77 envoyer à un agent la liste des agents joints pour la création d une collaboration entre ces agents mobiles. - Système collaboratif (Collaborative System) : il contient Les composants fonctionnalité du système (System funtionality) et gestionnaire de la fonctionnalité du système (System Funtionality Managemement). Ces deux composants gardent les mêmes fonctions que dans un système centralisé. La différence entre les deux architectures c est que la gestion et le stockage des informations de contexte sont distribués par l utilisation des agents mobiles. Au niveau de chaque agent mobile, il y a une gestion locale des informations de contexte de l utilisateur associé à cet agent mobile. Alors que pour la première architecture l ensemble des informations de contexte de tous les utilisateurs sont rassemblées dans le composant gestionnaire de la fonctionnalité du système. 5 ETUDE DE CAS (SUITE) Reprenons le cas d étude décrit précédemment. Nous décrivons, dans ce qui suit, comment les composants de l architecture distribuée peuvent interagir dans le cas d un télé-diagnostique collaboratif. Le composant Système Collaboratif décrit dans la figure V.2 contient les services et les outils de gestion d une collaboration. Ces services sont regroupés selon deux composants, voir la figure V.3: le composant gestion de groupe et le composant gestion de ressources tels que : - Gestion de groupe : contient les services de contrôle et de gestion des utilisateurs tels que l initiation et la création d une session de collaboration, la jointure d une session crée, l invitation d un utilisateur à la session courate et la terminaison d une session de collaboration. - Gestion de ressources : permet les services d exploiter les ressources partagées dans une session de collaboration (vidéo, audio, message instantané, vocal, etc.). Ces services sont définis selon : donner une permission d utilisation de ressources, refuser une permission, mettre en attente une permission et retirer une permission précédemment donnée. 77

78 User1 User Session Context parameters Mobile Agent1 Location Connexion Availability Client Side Probes : Context Adapter DT Construction Mobile Agent Manager Resources Manager Collaborative Session Group Manager Context Adapter Shared Resources Mobile Agent2 Client Side Probes : Location Connexion Availability User2 User Session FIGURE V-3 ARCHITECTURE D UN SYSTEME DE COLLABORATION BASEE SUR L AGENT MOBILE L agent mobile contient un composant d adaptation au contexte (Context Adapter) qui prend en entrée les paramètres de contexte et les règles de l arbre de décision, et fournit en sortie les actions adaptées. Initialement, une session de collaboration est crée par un médecin, éventuellement par le médecin de garde. Le composant session utilisateur (User Session) envoie au composant gestionnaire de groupe (Group Manager) le message Creer_Collaboration incluant l identité de l utilisateur. Le gestionnaire de groupe, de sa part, notifie le gestionnaire des agents mobiles (MAM) de l identité de cet utilisateur dans le but de lui affecter un agent mobile. Ce processus se répète à chaque fois un nouvel utilisateur est ajouté à la session de collaboration (joint ou invité). Un utilisateur peut inviter d autres utilisateurs pour collaborer. Pour faire rejoindre des utilisateurs, ils peuvent envoyer la requête Joint au gestionnaire de groupe. Ce dernier peut accepter ou refuser le nouvel utilisateur à rejoindre la session de collaboration. Après l établissement d une session de collaboration, si un utilisateur demande une permission d utilisation de ressources, le composant session utilisateur contacte l agent mobile associé. L agent mobile utilise l algorithme intégré de l arbre de décision pour décider sur les ressources appropriées pour cet utilisateur en respectant ses informations de contexte détectées. Puis, l agent mobile envoie le message ask_ressource au gestionnaire de ressources, le message inclut seulement la ressource appropriée (adaptée). 78

79 Par conséquence, le gestionnaire de ressources répond l utilisateur en utilisant Give_resource ou bien Refuse_Resource messages. Dans ce qui suit, nous expliquons comment profiter des agents mobiles pour assurer une gestion équitable de ressources de l environnement de travail. 6 ALGORITHME DE GESTION DE RESSOURCES DANS UN ENVIRONNEMENT MOBILE 6.1 MOTIVATIONS Dans un environnement mobile, les activités de collaboration sont opposées à de multiples interruptions dues aux ressources insuffisantes (CPU, batterie et mémoire) pour un terminal mobile. Pour remédier à ce problème, nous partons d une vision générale en considérant l ensemble des ressources des terminaux disponibles sur l environnement de travail. Séparément, les ressources sur un terminal ne peuvent pas être suffisantes pour effectuer un traitement donné, mais l ensemble des ressources permet largement de supporter ce traitement. En conséquence, remédier aux telles interruptions durant une active session, peut être fait en établissant une distribution équitable de la charge de traitement entre les ressources disponibles sur l ensemble des terminaux mobiles disponibles d une session de collaboration. La gestion d équité de distribution de la charge peut être établie en faisant transférer le traitement d un agent mobile vers un terminal plus qualifié. En conséquence, un agent mobile doit être conscient de l état de ses ressources locales et peut décider si le terminal local peut supporter la charge des ses propres tâches ou non. Les tâches effectués par un agent mobile sont constituées principalement par : - Collecter les informations de contexte de l utilisateur en utilisant les capteurs résidant sur le terminal local. - Utiliser l algorithme de l arbre de décision pour décider sur les ressources appropriées. Le processus de la décision basée sur les informations de contexte ne peut pas consommer de considérable quantité de l énergie. Pourtant, ce processus en conjonction avec de suppléments tâches tels que la capture périodique de l information de contexte peut influencer sur l état des ressources du terminal. Dans de telle situation, l agent mobile peut migrer ou effectuer un clone vers le terminal le plus riche en termes de ressources. Cependant, comment les agents mobiles peuvent établir une collaboration pour choisir le terminal le plus convenable? A base de quel critère un agent mobile peut décider de choisir un terminal parmi plusieurs? Dans ce qui suit nous répondons à ces questions en commençant par comment établir une collaboration entre les agents mobiles. 79

80 6.2 ARCHITECTURE DE COLLABORATION DES AGENTS MOBILES Les opérations de migration ou de clonage se font par l établissement d une session de collaboration entre les agents mobiles, voir la figure V.4. Cette collaboration a pour but d établir une conscience partagée entre ces agents mobiles. Chaque agent est supposé conscient des états des ressources de son terminal associé. Par conséquent, quand un agent mobile est dans une situation critique, il peut décider de migrer ou de faire un clone de son état d exécution sur un autre terminal. Une situation critique est atteinte si l un des paramètres de ses ressources telles que la batterie, la mémoire ou le CPU est sous un certain seuil. Par exemple, selon Phung [55], le seuil de la batterie sous lequel l agent mobile nécessite de migrer est de 30%. MA1 MA2 MA3 Mobile Agents S1 MAs Collaborative Sessions S3 S2 Mobile Agent Manager FIGURE V-4 SESSION COLLABORATIVE ENTRE DES AGENTS MOBILES Dans de tel cas, l agent mobile concerné peut établir une session collaborative avec les autres agents mobiles existant pour décider sur le terminal distant approprié à lequel l opération de la migration ou de clonage peut effectuer. Pour cela, l agent mobile contacte le gestionnaire des agents mobiles pour récupérer la liste des agents mobiles joints. Cette liste contient les identités et les localisations de ces agents mobiles. En se basant sur cette liste, l agent mobile concerné communique avec les autres agents mobiles pour choisir le terminal convenable qui a des états de ressources qualifiées. Le choix de ce terminal se fait selon plusieurs critères. Dans ce qui suit, nous proposons l algorithme de sélection d un terminal qualifié de riches ressources pour réaliser la mobilité autonome des agents mobiles. 6.3 ALGORITHME DE SELECTION SENSIBLE AU CONTEXTE Un agent mobile doit être continuellement conscient des états des ressources locales de son terminal associé tels que le niveau de la batterie, la mémoire restante et le CPU utilisé. En conséquence, le terminal local est doté d un ensemble de capteurs pour obtenir périodiquement le statut des ressources du terminal. Dans le cas où l agent mobile détecte que le statut d une ressource est sous le seuil spécifié, il compare les exigences de ses propres tâches avec les caractéristiques des autres machines. 80

81 Dans ce cas, l agent mobile concerné (MA c ) contacte le gestionnaire des agents mobiles MAM pour obtenir la liste des agents mobiles disponibles (le tableau MA av ), voir la figure V.5. Puis le MA c envoie une requête à chacun de ces agents mobiles appartenant à l ensemble MA av. Nous supposons que la communication entre les agents mobiles est infaillible. La requête contient l identité de l agent mobile et le type de la ressource concernés (Rsc). Rsc : resource variable MA c :concerned MA MA av =NULL: array of the available MAs MA res =NULL: array of the MAs responders T sel =NULL: the selected terminal IF (Rsc < threshold) THEN MA av = Available MAs from MAM For each MA from MA av send_request(ma, Rsc) end For MA res = receive(rsc_status, MA) MA sel = selectbestresources(ma res, Rsc) T sel = select_trminal(ma sel ) Clone(MA c, T sel ) END IF FIGURE V-5 ALGORITHME DE COLLABORATION ENTRE LES AGENTS MOBILES Nous considérons qu un agent mobile peut vérifier d une façon autonome si ses ressources peuvent supporter de suppléments tâches [66]. On suppose que l ensemble des agents mobiles déclarent effectivement ce qu ils détiennent de ressources dans la réalité et que ces agents mobiles sont tous prédisposés à collaborer. On suppose qu il y a pas le problème de free rider ou de selfishness [56]. En conséquence, seuls les agents mobiles qui ont suffisamment de ressources peuvent envoyer une réponse (le tableau MA res ). La réponse contient le statut des ressources de leurs terminaux (Rsc_status). En utilisant la fonction selectbestresources, le MA c sélectionne le terminal qui a les meilleures ressources (nous supposons que tous les agents mobiles répondeurs ont des ressources supérieures de seuil spécifié). La sélection du terminal se base sur les priorités des ressources. Principalement, la priorité considérée est comme suit [66] : le niveau de la batterie, le pourcentage de la de l utilisation de CPU et la mémoire restante. Cependant, dans le cas où la ressource défaillante est le CPU, la priorité devient : CPU, Batterie et mémoire et dans le cas où la ressource défaillante est la mémoire, la priorité sur laquelle est basé l algorithme de sélection devient : Mémoire, Batterie et CPU. Par ailleurs, l algorithme a, comme entrées, un tableau bidimensionnel Rsc[nb_MA][3] qui représente les statuts des ressources des agents mobiles répondeurs tels que, le nombre nb_ma est le nombre des répondeurs et le nombre 3 représente les trois types de ressources considérées, voire la figure V.6. Ces ressources sont triées selon la priorité indiquée précédemment. Initialement, en respectant la première priorité des ressources, l algorithme cherche le terminal qui possède le meilleur statut de cette ressource. Pour 81

82 cela, l algorithme prend la première ressource (Rsc[i=0][0]) comme la ressource de meilleur statut (bestrsc), puis il compare le statut de cette ressource aux autres ressources Rsc[i>0][0] (currentrsc). Au cours de la comparaison de tous les éléments de la première colonne, l algorithme cherche le terminal qui se distingue des autres par une différence de 10% supplémentaire. Cette différence est considérée comme la marge pour supporter les tâches d un agent mobile supplémentaire. int i=0, j=0, selectedindex=0 float currentrsc=0, bestrsc=0, diff=0 boolean choice=false while (j<3) And (choice=false) Do { bestrsc = Rsc[i][j] while (i < nb_ma) Do { i = i+1 currentrsc = Rsc[i][j] diff = compare(bestrsc, currentrsc) if (diff > 10%) then { bestrsc = currentrsc selectedindex = i choice = true } } j = j+1 i = 0 } FIGURE V-6 ALGORITHME DE SELECTION D UN TERMINAL Si l algorithme ne trouve pas le terminal qui se distingue de 10% des autres, il passe à l autre colonne et effectue la même procédure en considérant la ressource suivante. L algorithme se termine par la sélection du terminal approprié. Dans ce cas une migration ou un clonage est effectué au terminal sélectionné. Dans le cas où aucun terminal n est sélectionné, un message d erreur est envoyé à l interface de l utilisateur. L agent mobile cloné effectue ses tâches désignées d une façon transparente à l agent mobile d origine. Un agent mobile cloné est considéré comme une nouvelle instance de l agent mobile d origine en gardant le même état d exécution sur le terminal distant. Après le clonage, l agent mobile cloné fournit les mêmes services en coopérant avec l agent d origine. Principalement, un agent mobile capture les informations de contexte de l utilisateur et de son terminal (connectivité, disponibilité et localisation) et attribue à l utilisateur la ressource convenable en utilisant l algorithme de l arbre de décision. En effectuant le clonage, l agent mobile d origine met à jour, en permanence, l agent mobile cloné des informations de contexte. Quand à l agent mobile clone, il exécute les tâches d adaptation. 82

83 7 CONCLUSION Dans ce chapitre, nous avons proposé une approche de gestion distribuée de la sensibilité au contexte en se basant sur les agents mobiles. L utilisation des agents mobiles nous a permis d optimiser la réalisation de la collaboration dans un environnement mobile. Basé sur les agents mobiles, un algorithme est proposé pour sélectionner un terminal qui détient des ressources plus qualifiées. Cet algorithme permet à un agent mobile de migrer d un terminal à un autre pour maintenir la continuité de la collaboration. Dans la partie suivante, nous montrerons l implémentation des agents mobiles et l utilisation de l algorithme de sélection d un terminal dans un prototype d un système de collaboration de télédiagnostic sensible au contexte. Ce chapitre fait l objet de la publication suivante : - Y. Elgahyam, et M. Erradi, "Distributed Context Management in Collaborative Environment", New Technologies of Distributed Systems, NOTERE, Paris, France,

84 Chapitre VI : CONCEPTION ET REALISATION 84

85 1 INTRODUCTION Pour valider notre approche d adaptation, nous avons développé un prototype d un système de collaboration de télédiagnostic sensible au contexte. Le système assure les outils et les services de gestion et de contrôle de sessions de collaboration. Dans ce chapitre, nous présentons la conception et la réalisation de notre prototype et nous montrons comment gérer les services de collaboration en intégrant des informations de contexte. La conception est faite à base des composants définis dans UML 2. Pour la réalisation de prototype nous utilisons le framework J2ME (Java 2 Micro Edition) et la plateforme de JADE-LEAP pour utiliser les agents mobiles. 2 CONCEPTION D UN SYSTEME DE COLLABORATION DE TELEDIAGNOSTIC SENSIBLE AU CONTEXTE 2.1 MODELE UML 2 UML 2.0 [59] offre de nouveaux concepts pour définir l architecture d une application donnée. Ces concepts sont définis par des composants, des interfaces requises (required interfaces), des interfaces fournies (provided interfaces), des ports, des structures composites et des connecteurs. Le concept composant, défini par UML 2.0, est considéré comme une unité autonome. Il possède une ou plusieurs interfaces. Ces interfaces sont exposées par des ports. La fonctionnalité interne du composant est cachée et inaccessible que par ses interfaces (requises et fournies). Les interfaces requises représentent les services dont le composant a besoin et les interfaces fournies définissent les services offerts par le composant à ses clients. L adoption de la notation UML 2.0, qui est basée sur des composants, facilite bien la tâche de la conception. Elle permet de décomposer le système étudié aux plusieurs constituants indépendants et par la suite connecter ces constituants par des interfaces et des ports. Cette vision assure la réutilisation et l extensibilité. Un composant peut être substitué par un autre si et seulement si les deux composants sont conformes. La conformité est définie par les sémantiques de leurs interfaces. Par conséquent, un composant peut être vu comme un black-box qui encapsule les états et le comportement de sa structure interne. Le diagramme indiqué dans la figure VI.1 montre l ensemble des aspects constituant cette modélisation. La partie droite spécifie l aspect dynamique. Elle est composée de diagramme d activités, le diagramme de séquence, le diagramme de machine à états. La partie gauche représente l aspect structurel. Elle est composée de diagramme de classes, le diagramme de composant et le diagramme de déploiement. 85

86 FIGURE VI-1 TAXONOMIE DE DIAGRAMMES DE STRUCTURES ET DE COMPORTEMENT [59] Dans la suite nous montrons le diagramme de composant et le diagramme de classe de notre prototype en utilisant les notations de UML DIAGRAMME DE COMPOSANT En se basant sur la notation de UML 2.0, nous avons fait une modélisation de notre prototype [65]. L architecture de notre application collaborative mobile de télédiagnostic peut être vue comme un ensemble de composants. Chaque composant représente une cohérente partie qui peut être traitée indépendamment et qui peut être réutilisée ou changée. Notre architecture est une décomposition de trois composants : le composant Hospital_Staff, le composant Collaboration_System et le composant Adapter, voire la figure VI.2 : 86

87 FIGURE VI-2 UNE ARCHITECTURE A BASE DE COMPOSANTS Le composant "Hospital_Staff" : représente des médecins qui collaborent entre eux pour fournir un diagnostic commun. Il inclut quatre interfaces pour communiquer avec son environnement : l interface Session, l interface Floor, l interface Capture et l interface Diagnosis. L interface "Session" permet des opérations de jointure et de départ des utilisateurs d une session de collaboration. L interface "Floor" définit les méthodes d exploitation des outils et des ressources d une session. L interface "Sensor_Capture" permet un canal de récupération des informations de contexte au profil du composant Adapter. L interface "Diagnosis" assure la communication entre les médecins et le patient. Le composant "Collaboration_System" intègre les fonctionnalités de control et de gestion d un télédiagnostic collaboratif. Le comportement de ce composant est composé de quatre interfaces : l'interface session, l interface Floor, l interface Session_Adaptation et l interface Floor_Adaptation. Les deux premières interfaces fournissent des canaux pour l interaction entre le système et les médecins. Les deux autres interfaces font suivre les opérations des utilisateurs au composant Adapter pour avoir des services adaptés aux utilisateurs. Le composant Adapter fournit l interface Sensor_Capture pour capturer les informations de contexte de l utilisateur. Ce composant utilise aussi l interface "Session_Adaptation" et l interface "Floor_Adaptation" pour fournir des services adaptés au composant "Collaboration_System". L interconnexion entre ces composants est faite en respectant la compatibilité entre les services requises et fournies. 2.3 DIAGRAMME DE CLASSE Un diagramme de classe est une réalisation (implémentation) d une modélisation basée sur des composants. Une modélisation à base de composants peut supporter plusieurs types de réalisation. Dans ce travail, nous définissons l une des réalisations possibles d une 87

88 architecture basée sur les composants, montrée sur la figure VI.2. Le diagramme de classes détaille les différentes classes du système et les relations entre ces classes. Dans la figure VI.3, nous identifions plusieurs classes et interfaces. La classe Session_Manager offre les méthodes d interactions entre les médecins, la classe "Doctor". Ces interactions sont faites par l échange des messages envoyés par les médecins, tels que create_session(), invite(), etc. Les réponses du système sont traitées par l interface Session_Mngr, par l envoi des réponses telles que SCCP_session_created(), SCCP_accept(), etc. Une deuxième classe qui assure la communication entre les médecins et le système est la classe Floor_Manager. Cette classe réalise l interface "Floor_Mngr" en fournissant les méthodes de contrôle des ressources partagées, telles que give_floor(), grab_floor(), etc. Cette interface échange des messages avec l interface "Doc_Floor" qui est réalisée, elle aussi, par la classe "Doctor". La classe Floor_Manager est attachée à la classe "Session_Manager" via les interfaces "Collab" et "Collaborators", pour être à jour des collaborateurs présents. Les deux classes destinées pour la collaboration ("Session_Manager" et "Floor_Manager") réalisent respectivement les interfaces Session_Adpt and Floor_Adpt pour fournir des services adaptés. Ces deux interfaces sont connectées à la classe "Adapter" via les interfaces "Session_Adaptation" et "Floor_Adaptation". La classe "Adapter" fournit les services adaptés dependant sur le contexte de l utilisateur. La classe "Sensor" communique avec la classe "Context" pour capturer les informations de contexte. L opération de capture se fait par la relation entre les interfaces Context_Capture et Sensor_Capture qui sont réalisées respectivement par les classes Context et Sensor. La classe Gestionnaire_Contexte structure ces informations de contexte pour être utilisées par la classe "Adapter". 88

89 FIGURE VI-3 DIAGRAMME DE CLASSES 3 REALISATION Notre réalisation d un système de collaboration dans un environnement mobile se fait en utilisant les agents mobiles. Dans cette réalisation, on bénéficie de la mobilité, l autonomie et la collaboration de l agent mobile pour assurer l adaptabilité et la flexibilité de l application. 3.1 LES TECHNOLOGIES SOUS-JACENTES J2ME Java 2 Micro Edition (J2ME) est un environnement extensible pour les applications destinées aux petits supports (Smartphone, PDA, etc.). J2ME peut être divisé en trois parties, voire la figure VI.4 : une configuration, un profil et des APIs optionnelles. Une configuration est conçue pour un type spécifique de support. Elle permet de spécifier une machine virtuelle Java pour ce support, par exemple KVM (Kilobyte Virtual Machine). Deux configurations sont définies : la configuration CDC (Connected Device Configuration), qui est destinée pour des terminaux ayant au minimum 2MB de mémoire disponible. La configuration CLDC (Connected Limited Device Configuration) qui est destinée pour des terminaux de configurations limitées, par exemple des terminaux ne dépassant pas 512 KB de mémoires disponibles. 89

90 Un profil est plus spécifique qu'une configuration. Il est basé sur une configuration et procure des APIs additionnels comme l interface utilisateur. Deux profiles principaux sont définis : Le profil Foundation : destiné à la configuration CDC. L utilisation de ce profil permet l accès à une implémentation complète des fonctionnalités de J2SE (Java 2 Standart Edition). Le profil MIDP (Mobile Information Device Profile): destiné à la configuration CLDC. Il prend en charge un nombre limité des classes de J2SE et définit des classes d'entrée/sortie et d'interface spécialisées pour une configuration CLDC. Dans cette réalisation nous utilisons la configuration CLDC et le profile MIDP JADE-LEAP FIGURE VI-4 PILE DE COMPOSANTS DE J2ME JADE (Java Agent DEvelopment Framework) [58] est un framework implémenté en Java. Il est open-source et distribué sous la licence LGPL (GNU Lesser General Public License). Son but est de permettre le développement de système multi-agents en mettant à disposition un middleware et des outils graphiques. JADE est conforme aux spécifications FIPA (Foundations of Intelligent Physical Agents) [60] pour l'interopérabilité des systèmes multi-agents intelligents. LEAP (Lightweight Extensible Agent Plateforme) [67] est une librairie de classes pour supporter des agents sur des terminaux mobiles légers. Il est compatible avec FIPA. Il est léger et extensible en taille et en fonctionnalité. JADE-LEAP est la combinaison des deux plateformes pour supporter des agents qui tournent sur des terminaux légers. Il peut être déployé sur différents types de terminaux, des réseaux et des JVMs. La figure VI.5 montre l environnement de travail de JADE- LEAP. Il offre une diversité des APIs qui permet le déploiement des applications et des services à bases des agents. 90

91 FIGURE VI-5 L ENVIRONNEMENT D EXECUTION DE JADE-LEAP 3.2 ARCHITECTURE DU PROTOTYPE L architecture de notre prototype de télédiagnostic de collaboration mobile est désignée par trois principaux couches, voire figure VI.6 : la couche frontale (Front Layer), la couche intermédiaire (Middle Layer) et la couche arrière (Back Layer). La couche frontale est principalement utilisée pour la présentation. CLDC définit la base pour des interfaces de programmation. La couche intermédiaire est composée de Java Socket et les agents mobiles. Java Sockets établissent les communications entre les utilisateurs et le programme de gestion de la collaboration. Une fois un utilisateur est connecté, un agent JADE-LEAP est affecté à cet utilisateur. La couche arrière représente les processus de gestion et de contrôle de la collaboration. FIGURE VI-6 ARCHITECTURE DU PROTOTYPE 91

92 3.3 DEVELOPPEMENT DU PROTOTYPE Dans ce qui suit nous montrons comment un agent mobile est utilisé pour gérer les informations de contexte de l utilisateur et permettre d intervenir dans une session de collaboration. Quand un utilisateur joint une session de collaboration, le gestionnaire de groupe contacte le gestionnaire des agents mobiles (MAM) pour le notifier du nouveau participant. Le MAM crée un agent mobile et l affecte à cet utilisateur. L agent mobile, nouvellement crée est intégré par l algorithme de l arbre de décision. Par la suite, quand un utilisateur veut participer aux activités de la collaboration (envoi de message Ask Resource), l agent mobile correspondant fait suivre la demande, voire la figure VI.7. Dans le cas d une favorable réponse (réception de message Give Resource), l agent mobile, qui est précédemment détecté le contexte de l utilisateur (Read Context sur la figure VI.7), peut activer les ressources (message activate resource) suivant le contexte détecté et en respectant l algorithme de l arbre de décision. LCM Group Manager Resource Manager MAM New User Mobile Agent Ask Resource New Mobile Agent Give Resource Read Context Activate Resource FIGURE VI-7 CREATION D UN AGENT MOBILE La création d un agent UserA se fait par l extension de la classe Agent. Cette classe contient, entre autres, les méthodes setup() et addbehavior() qui peuvent être redéfinies. La méthode setup() est invoquée dès la création de l agent mobile. Elle permet d effectuer les initialisations nécessaires à la création de l agent mobile. Dans notre cas d étude, à la création, l identité et le contexte de l utilisateur sont affectés à l agent en question. La méthode addbehavior() définit le comportement de l agent mobile désigné durant son cycle de vie. Parmi les comportements définis dans la plateforme JADE il y a le comportement TickerBehaviour qui assure une exécution cyclique des actions. Dans la classe de comportement, on désigne les adaptations à effectuer selon les informations de contexte 92

93 détectées. Dans la figure VI.8, on montre un extrait de la création d un agent mobile et l affectation du comportement. Les détails de créations des autres agents et de communication entre ces agents sont désignés dans l Annexe II. import jade.core.agent; import jade.core.behaviours.*; public class UserA extends Agent{ Context CtxtA; String Agent_Id ; DemandeRessource DR ; }} public void UserA(String Identite){ User_Id = Identite ; SB = new DemandeRessource (this); } protected void setup (){ Agent_Id= this.getaid ();// récupération de l identité de l agent addbehaviour(dr) ; // ajout du comportement demande // de ressources CtxtA = new Context(Agent_Id); // instancie la classe Context classe DemandeRessource extends SimpleBehaviour { protected void action(){ // Les décisions à prendre basées sur les éléments de contexte } FIGURE VI-8 LA CLASSE AGENT MOBILE La figure VI.9 montre la création de la classe Context. Elle contient les méthodes qui manipulent et écoute aux changements des valeurs de contexte. Public class Context { boolean Connexion; boolean Availability; String Location; String User_id; } public void Context(String Id){ User_Id = Id; } public void setconexion(boolean c){ Connexion=c; } public void setavailability(boolean a){ Availability=a; } public void setlocation(string l){ Location=l; } public boolean getconnexion(){ return Connexion; } public boolean getavailability(){ return Availability; } public String getlocation(){ return Location; } FIGURE VI-9 LA CLASSE CONTEXT Pour la décision sur la ressource appropriée, la classe Adapter définie une la méthode 93

94 assignresource (voire la figure VI.10). Cette méthode implémente l algorithme de l arbre de décision. Cette méthode est invoquée par la méthode action définie dans la classe UserA. public void assignresource (boolean cxn, boolean dispo, String loc ) { if (cxn == false) { activateresource( _vocal ) else if (dispo == false ) { activateresource( IM ) activateresource( ) } else if (loc== surgery_room ) activateresource( audio ) else { activateresource( video ) activateresource( audio ) activateresource( IM ) activateresource( ) } } } } FIGURE VI-10 ATTRIBUTION DE RESOURCES Pour récupérer les informations de contexte, chaque utilisateur connecté doit spécifier son état de disponibilité (availability) (Yes/no), voire la figure VI.11.a. Ensuite l application affiche les utilisateurs disponibles dans la même session (voire figure VI.11.b). Dotée par des capteurs de positionnement géographique, tel que RFID, l application peut détecter le positionnement de l utilisateur (salle de chirurgie, salle de consultation ou bureau). Par conséquence, en se basant sur les informations de contexte collectées (connectivité, disponibilité et positionnement) l application peut décider sur les ressources partagées appropriées pour affecter au demandeur de ressources. Comme c est montré sur la figure VI.11.c, suivant l algorithme de l arbre de décision, seulement la ressource audio est affectée à cet utilisateur. (a) (b) (c) FIGURE VI-11 PROTOTYPE DE REALISATION D UNE AFFECTATION SENSIBLE AU CONTEXTE DE RESOURCES 94