Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
Collaboration
Les travaux de recherche dans le domaine du travail collaboratif assisté par ordinateur (Computer Supported Collaborative Work ou CSCW en an-glais) [CS99] ont démarré dans les années 1990. Kraemer [KK88] et El-lis [EGR91], respectivement, ont proposé deux définitions générales du travail collaboratif : « Système à base d’ordinateurs qui assiste des groupes de personnes réalisant en commun une tâche ou un but, et qui fournit une interface pour accéder à un environnement commun. »
« Système informatique qui facilite la résolution de problèmes par un ensemble de décideurs travaillant en groupe. »
Dans ces définitions, le terme travail au sens large fait référence à toute tâche commune entre plusieurs personnes, dans des domaines de type jeu, enseignement, co-conception, etc. Les techniques développées dans le domaine du travail collaboratif peuvent être appliquées à toute sorte de collaboration humaine assistée par ordinateur.
Le travail collaboratif puise ses références dans quatre do-maines [Vil06] :
– les sciences sociales (plus concrètement, la sociologie et la théorie des organisations) pour étudier l’organisation des groupes de personnes, leurs rapports, l’efficacité d’un groupe, etc. ;
– les sciences cognitives et l’intelligence artificielle distribuée pour étudier la sémantique des informations, la planification de tâches, l’aide à l’exécution de ces tâches, etc. ;
– les interfaces homme-machine pour concevoir des interfaces multi-utilisateurs adaptées au travail collectif ;
– l’informatique distribuée pour la conception de systèmes répartis qui permettent le stockage, l’échange et le traitement d’informations à distance.
Le nom de collecticiel (groupware en anglais) désigne l’ensemble de pro-duits logiciels, services, plate-formes et outils qui soutiennent le travail collaboratif [Kar94].
Dans la suite de cette section, nous nous focalisons sur la notion de session de travail, autour de laquelle se structure la plupart des systèmes collaboratifs.
Sessions
Le concept de session est essentiel dans le travail collaboratif. Une session est composée d’un ensemble d’utilisateurs qui partagent des intérêts com-muns [DGLA99]. Les personnes qui participent à une session ne doivent pas forcément se trouver au même endroit ; l’utilisation de réseaux in-formatiques permet l’intervention de participants éloignés géographique-ment.
Les sessions peuvent être synchrones ou asynchrones. Dans une ses-sion synchrone, tous les participants sont présents simultanément. Les échanges entre ces participants sont interactifs, et les données sont ma-nipulées en temps réel. Un exemple de ce type de session est un ensemble de personnes qui assistent à une réunion par visioconférence.
Dans une session asynchrone, la co-présence des membres du groupe n’est pas nécessaire (mais elle reste possible). Les échanges ne se pro-duisent pas en temps réel, car ils sont basés sur des médias asynchrones tels que le courrier électronique.
Cette séparation entre sessions synchrones et asynchrones a été utilisée historiquement du fait que les technologies réseau associées étaient très différentes. Actuellement on peut trouver des outils qui combinent les deux modes : par exemple, dans l’édition collaborative d’un document, il peut y avoir des phases où les auteurs travaillent séparément de façon asynchrone, avec certaines « réunions » ponctuelles en mode synchrone pour garantir la cohérence du document produit.
Une deuxième classification des sessions est celle qui les sépare en explicites et implicites. Les sessions sont appelées explicites quand les confi-gurations possibles de la session sont définies hors-ligne, lors de la concep-tion du système. Le concepteur définit explicitement les relations entre les membres du groupe, ainsi que leur évolution dans le temps. Ensuite, lors de son exécution, le système gère des instances des sessions définies par le concepteur. En général, un utilisateur privilégié initie la session, et les autres utilisateurs peuvent la rejoindre s’ils sont invités. La plupart des modèles proposés pour la formalisation des sessions synchrones sont ba-sés sur des graphes [RPVD01]. Dans ces graphes, les nœuds représentent les utilisateurs, tandis que les arêtes représentent des flux de données que les utilisateurs s’échangent. Les étiquettes des arêtes indiquent l’outil qui gère l’envoi et la réception des données.
Les sessions implicites émergent de l’observation des actions des uti-lisateurs et de leur contexte. Quand le système détecte des situations de collaboration potentielle, en fonction par exemple de la présence des uti-lisateurs et de leurs intérêts, il crée une session implicite et il invite les utilisateurs concernés à la rejoindre. Peu de travaux ont étudié ce type de sessions en profondeur ; cependant on peut citer les travaux d’Ed-wards [Edw94] et de Texier et Plouzeau [TP03], qui proposent des mo-dèles basés sur la théorie des ensembles, ainsi que celui de Rusinkiewicz et al. [RKT+ 95], qui s’appuie sur la logique de premier ordre pour la des-cription de sessions dont la structure n’est pas fixée à priori.
Gestion des sessions et déploiement
Dans les outils collaboratifs, les modèles de session sont utilisés par des gestionnaires de session qui contrôlent le cycle de vie des sessions. Ils servent à définir les sessions, à les activer, à contrôler l’accès des utilisa-teurs et leurs droits, à activer les outils nécessaires, etc.
Un aspect important est le déploiement des outils et des composants qui gèrent les flux de données envoyés entre les utilisateurs. En effet, il est nécessaire d’installer et de configurer ces éléments sur les machines des utilisateurs afin qu’ils puissent effectuer ces échanges. Par exemple, si le modèle de session indique qu’un flux audio existe entre l’utilisateur A et l’utilisateur B, alors il est nécessaire que A et B disposent sur leurs machines d’un outil (ou d’un composant faisant partie d’un outil) capable de gérer des flux audio.
Hammami [Ham07] a fait une étude très complète des types de dé-ploiement et des systèmes de déploiement qui existent. Le déploiement peut être statique (où un administrateur désigne explicitement l’applica-tion à utiliser) ou dynamique (où le choix se fait d’une façon automatique pendant le processus de déploiement), centralisé (avec une entité princi-pale qui dirige le processus) ou décentralisé (où les nœuds de déploiement interagissent entre eux). Il existe deux stratégies de déploiement : push, dans laquelle l’initiative du déploiement est donnée à l’administrateur ou au superviseur, et pull, dans laquelle les nœuds de déploiement initialisent le processus eux-mêmes. En général, les systèmes que l’on trouve dans la littérature implantent un déploiement de type statique, en mode push, et souvent centralisé. Les systèmes automatiques ont été peu explorés, et en général ils sont peu flexibles. Ils ne permettent pas, par exemple, le dé-ploiement de composants à chaud, c’est-à-dire, sans demander un arrêt des logiciels qui s’en servent.
Collaboration et informatique ubiquitaire
Les activités collaboratives peuvent particulièrement bénéficier des possi-bilités offertes par l’informatique ubiquitaire. Notamment, le fait de dis-poser d’informations sur le contexte des utilisateurs est très intéressant pour les applications collaboratives [HL09]. De ce fait, la notion de ses-sion implicite prend tout son sens quand on la considère dans le cadre de l’informatique ubiquitaire, car l’immersion des utilisateurs dans l’environ-nement et la sensibilité au contexte donnent beaucoup d’informations qui peuvent être exploitées afin de proposer des sessions adaptées aux besoins des utilisateurs. Comme Iqbal et al. [IIS+ 08] l’ont signalé, l’informatique ubiquitaire peut à la fois améliorer les relations des humains avec l’envi-ronnement et avec d’autres humains. Pour cela, il faut avoir une connais-sance, représentée par des modèles, des tâches que les humains réalisent et de leurs intentions.
Ces dernières années, les techniques et les modèles classiques du tra-vail collaboratif que nous avons cités, comme par exemple ceux basés sur les graphes ou sur la théorie des ensembles, ont été utilisés dans les col-lecticiels de type « bureau » d’une façon satisfaisante. Néanmoins, dans le cadre de l’informatique ubiquitaire, les besoins sont différents, et les approches existantes ne sont pas complètement adaptées. Il est nécessaire de proposer de nouveaux cadres conceptuels et des modèles qui prennent en considération les aspects spécifiques de la collaboration dans ce type d’environnements.
Le principal inconvénient des systèmes collaboratifs classiques pour leur utilisation dans les environnements ubiquitaires est que la conception des sessions est assez rigide [SBVT10]. La plupart des travaux considèrent des sessions explicites. Les travaux qui prennent en compte les sessions implicites proposent une implantation limitée ; elles sont vues comme un problème d’informatique distribuée (comment faire que plusieurs utilisa-teurs accèdent de façon concurrente aux mêmes ressources) et non comme un problème d’informatique ubiquitaire (comment proposer spontanément des sessions en fonction des informations contextuelles). Les sessions sont défi-nies lors de la conception des logiciels et il n’est pas possible de les adapter en fonction du contexte de l’application et des utilisateurs.
Nous pouvons ajouter à cela le fait que les services de déploie-ment fournis dans les systèmes collaboratifs classiques ne sont pas assez flexibles. En effet, les outils et les composants sont souvent déployés au préalable et manuellement. Les systèmes de déploiement automatique se réduisent souvent à des systèmes de téléchargement et d’ajout de paque-tages qui ne peuvent pas être installés ni démarrés à chaud. Ces méthodes sont suffisantes pour les systèmes de type « bureau », mais elles ne sont pas envisageables dans un environnement ubiquitaire dans lequel on ne veut pas focaliser l’attention de l’utilisateur sur l’installation de nouveaux logiciels à chaque fois qu’il veut rejoindre une activité collaborative.
La notion de contexte
Comme nous l’avons signalé dans les sections précédentes, le concept de contexte joue un rôle clé dans les systèmes ubiquitaires. Plusieurs auteurs ont essayé de cerner ce concept au moyen de définitions et de classifica-tions, dont nous citons les plus importantes dans cette section. Nous nous intéressons également à la sensibilité au contexte, pour finalement présen-ter quelques solutions pour sa prise en compte dans les applications.
Définition
Le contexte étant une notion complexe et abstraite, il est difficile de trou-ver une définition détaillée. Les définitions générales sont les plus nom-breuses ; nous listons ici les principales [Cha07]. Parmi les premiers à essayer de définir le contexte, se trouvent Schi-lit et Theimer, pour lesquels le contexte est constitué de la localisation de l’utilisateur, ainsi que des identités et des états des personnes et des objets qui l’entourent [ST94]. Brown et al. [BBC97] ajoutent à cette définition des données telles que l’identité de l’utilisateur, son orientation ou la tempé-rature. Ryan et al. [RPM98] ajoutent la notion de temps.
Pascoe [Pas98] introduit un élément important : l’intérêt. En effet, il dé-finit le contexte comme un sous-ensemble d’états physiques et conceptuels qui ont un certain intérêt pour une entité donnée. Cette notion d’intérêt ou de pertinence est reprise par Abowd, Dey et al. [ADB+ 99] dans leur définition, qui est communément acceptée : « Le contexte couvre toutes les informations qui peuvent être utilisées pour ca-ractériser la situation d’une entité. Une entité est une personne, un endroit ou un objet que l’on considère pertinent par rapport à l’interaction entre un utilisateur et une application, y compris l’utilisateur et l’application eux-mêmes. »
Winograd [Win01] reprend cette définition pour la détailler, car il considère que, malgré le fait qu’elle couvre tous les travaux existants, elle est trop générale : tout élément peut être considéré comme faisant partie du contexte. En premier lieu, il précise que le contexte est un ensemble d’informations. Cet ensemble est structuré et partagé, et il peut évoluer dans le temps. En deuxième lieu, selon lui, l’appartenance d’une infor-mation au contexte ne dépend pas de ses propriétés inhérentes, mais de la manière dont elle est utilisée. Une information fait partie du contexte seulement si le système dépend d’elle, d’une façon ou d’une autre.
Taxonomie des données contextuelles
Dans les travaux existants, nous avons trouvé plusieurs taxonomies du contexte, qui classifient les différents types de données contextuelles. Ces classifications permettent de lister les paramètres que l’on peut prendre en compte dans un système sensible au contexte.
La première catégorisation est celle de Schilit [SAW94], qui propose de répondre aux questions où l’on se trouve, avec qui et quelles sont les ressources à proximité afin de caractériser le contexte d’une entité. Ryan et al. [RPM98] proposent les catégories de position, identité, environnement et temps. La classification la plus acceptée est celle proposée par de Abowd, Dey et al. [ADB+ 99], qui est constituée de deux niveaux, avec des paramètres primaires et secondaires. Les paramètres primaires sont les mêmes que ceux de Ryan et al., sauf que la notion d’activité (c’est-à-dire, ce qu’on est en train de faire) remplace celle d’environnement, trop générale. Les paramètres secondaires sont des attributs des entités qui se trouvent dans le contexte primaire. Ces paramètres peuvent être retrouvés en utilisant les données primaires pour les indexer. Par exemple, le numéro de téléphone d’une personne peut être retrouvé en utilisant l’identité de la personne comme index dans une base de données qui contient des numéros de téléphone.
Chen et Kotz [CK00] citent une taxonomie alternative qui divise le contexte en trois catégories principales : le contexte informatique, le contexte utilisateur et le contexte physique. Le contexte informatique contient toutes les informations relatives aux ressources matérielles qui permettent l’exé-cution de l’application. Le contexte utilisateur contient des informations relatives à l’identité de l’utilisateur, ses préférences, ses relations sociales, etc. Finalement, les données du contexte physique caractérisent l’environ-nement physique dans lequel se trouvent les personnes et les applications. Cette dernière catégorie regroupe également les données temporelles. Le Tableau 2.1 présente quelques exemples de paramètres de contexte de ces trois catégories.
Dans notre travail, nous avons utilisé une version simplifiée de cette dernière classification ; nous divisons le contexte en contexte externe et contexte des ressources. Le contexte externe regroupe le contexte utilisateur et le contexte physique de la classification de Chen et Kontz, tandis que le contexte des ressources est l’équivalent du contexte informatique. Nous avons fait cette division car nous considérons que l’influence et la façon de gérer les données pour ces deux catégories sont très différentes du point de vue des logiciels sensibles au contexte. En effet, le contexte des res-sources détermine « ce qu’il est possible de faire » pour une application donnée. Par exemple, on ne peut pas déployer quatre composants qui ont besoin de 100 Mo de mémoire chacun sur une machine qui dispose seule-ment de 300 Mo de mémoire. De son côté, le contexte externe détermine « ce qu’il est souhaitable de faire » par rapport aux attentes de l’utilisateur et à son environnement. Par exemple, si un utilisateur entre dans une pièce la nuit, on peut considérer qu’il voudra que la lumière soit allumée, tandis que s’il fait jour, cela ne sera pas souhaitable. En définitive, le contexte des ressources représente des contraintes qui sont imposées au système, tandis que le contexte externe représente les exigences ou les attentes des utilisa-teurs. Le contexte externe à prendre en compte est fortement dépendant de l’application, tandis que le contexte des ressources est commun à toutes les applications.
Sensibilité au contexte
Comme nous l’avons vu, l’idée de sensibilité au contexte émerge naturel-lement du concept d’informatique ubiquitaire. En effet, le fait de disposer d’informations contextuelles sert à adapter l’application au contexte perçu afin de mieux répondre aux attentes des utilisateurs. L’idée principale de l’informatique sensible au contexte est de sortir le plus possible les hu-mains de la boucle de contrôle des machines, en réduisant les interactions entre l’humain et la machine.
La notion de sensibilité au contexte (context-awareness en anglais) a donc été produite dans le cadre des recherches sur l’informatique ubi-quitaire. Schilit et Theimer [ST94] furent les premiers à proposer une dé-finition de la sensibilité au contexte : il s’agit de la capacité d’un système à découvrir et à réagir à des changements dans l’environnement où il se trouve. Ils signalent également l’importance de l’adaptation du système à ces changements.
Pour Abowd, Dey et al. [ADB+ 99], un système est sensible au contexte s’il utilise celui-ci pour fournir à l’utilisateur des informations et des ser-vices pertinents. Cette pertinence dépend de l’activité que l’utilisateur est en train de réaliser. Ces auteurs proposent également une classification des systèmes sensibles au contexte selon leur réponse aux changements de contexte. Cette réponse peut soit présenter des informations ou des services à l’utilisateur, soit exécuter automatiquement un service, soit sto-cker des données contextuelles.
Solutions pour la prise en compte du contexte
Comme l’a signalé Edwards [Edw05], la signification et l’utilisation du contexte changent très souvent ; c’est une notion fluide et peut-être même ambigüe. De ce fait, il est difficile de créer une infrastructure pour la prise en compte du contexte utile pour toutes les applications. Malgré cela, on peut trouver dans la littérature plusieurs travaux qui ont proposé des plate-formes pour la gestion du contexte. Bien que nous soyons encore loin d’une plate-forme unifiée et automatique pour la gestion du contexte, ces travaux ont fait des progrès remarquables. Nous citons ici les exemples les plus importants par rapport à notre étude.
Dey et al. [DAS01] ont proposé la boite à outils Java Context Toolkit, qui fournit notamment une architecture d’acquisition de données contex-tuelles basée sur des widgets. Les widgets sont des composants logiciels qui encapsulent les capteurs physiques ou logiciels qui produisent les données de contexte. Context Toolkit fournit des objets qui facilitent les communica-tions réseau entre les widgets et les serveurs ou les applications qui veulent surveiller les données de contexte que les widgets produisent. Il fournit aussi des moyens pour stocker les données capturées. Dans Context Tool-kit, les données de contexte se présentent sous la forme clé–valeur. Il est possible d’utiliser des unités pour les mesures, mais leur sémantique est à définir par l’application. L’avantage de cette boite à outils est sa simpli-cité, car tout en restant assez complète, la mise en œuvre de l’architecture d’acquisition de contexte dans une application requiert très peu d’effort. Chen [Che04] propose l’architecture Context Broker Architecture (CoBrA). Cette architecture utilise des agents pour la prise en compte du contexte dans des espaces intelligents. Dans chaque espace, on trouve un courtier central (broker en anglais), qui gère un modèle central du contexte qu’il construit avec les données acquises. Il partage ce modèle avec les dispositifs, les services et les agents qui sont dans le même es-pace. Le courtier peut aussi fournir des interprétations des données de contexte qu’il détient grâce à l’utilisation d’ontologies OWL [SWM04]. Le courtier fournit également des moyens pour garantir la confidentialité des données de contexte.
Le système Service-Oriented Context-Aware Middleware (SOCAM), pro-posé par Gu et al. [GPZ04], est un intergiciel distribué qui permet l’im-plantation rapide de services mobiles sensibles au contexte. Comme dans le cas de CoBrA, cet intergiciel utilise des ontologies OWL pour repré-senter et pour effectuer des raisonnements sur le contexte. Dans l’archi-tecture de SOCAM, on trouve des composants tels que les fournisseurs de contexte, qui capturent les données de contexte et les représentent en OWL, les interpréteurs de contexte, qui fournissent des services de rai-sonnement sur le contexte, les bases de données de contexte, qui stockent les données de contexte, les services sensibles au contexte, qui adaptent leur fonctionnement au contexte courant, et les services de découverte de services, qui permettent l’annonce et la découverte des fournisseurs et des interpréteurs de contexte.
Adaptation
D’une façon générale, l’adaptabilité est la capacité d’un système à s’adap-ter à des changements. En informatique, les systèmes qui présentent cette propriété, dits adaptatifs (parfois auto-adaptatifs), ont connu un regain d’attention ces dernières années. Selon Laddaga [Lad01], la principale rai-son pour laquelle on a besoin de logiciels adaptatifs est le coût de la ges-tion de la complexité. En effet, les logiciels actuels sont de plus en plus complexes car leurs objectifs sont de plus en plus ambitieux. Il est néces-saire de gérer cette complexité, surtout quand les objectifs des logiciels évoluent dans le temps. Les logiciels adaptatifs sont une réponse à ce pro-blème. Satyanarayanan [Sat01] justifie le besoin d’adaptabilité comme réponse au compromis entre l’offre et la demande des ressources : « L’adaptabilité est nécessaire quand il y a des disparités significatives entre l’approvisionnement et la demande d’une ressource. »
Définition
Plusieurs auteurs ont essayé de définir l’adaptation. Nous citons ici les définitions les plus répandues [ST09].
En 1997, Laddaga [Lad97] proposa une première définition : « Un logiciel auto-adaptatif évalue son propre comportement et change ce com-portement quand l’évaluation indique qu’il n’est pas en train de réaliser ce qu’il est censé réaliser, ou que de meilleures fonctionnalités ou performances sont pos-sibles. »
Peu après, Oreizy et al. [OGT+ 99] ont donné une définition plus com-plète. Cette définition ajoute la notion d’environnement, que nous pou-vons assimiler au contexte : « Un logiciel auto-adaptatif modifie son propre comportement en réponse à des changements dans son environnement de fonctionnement. Par environnement de fonctionnement, nous nous référons à tout ce qui est observable par le système logiciel, comme les données fournies par l’utilisateur, les matériels et les capteurs externes ou des mesures. »
Ces premières définitions ne mentionnent pas explicitement l’informa-tique ubiquitaire. McKinley et al. [MSKC04] ont signalé que l’informatique ubiquitaire introduit un besoin d’adaptation en raison de la mobilité des utilisateurs et des interactions dynamiques avec l’environnement.
Raibulet [Rai08] identifie trois concepts importants des systèmes adap-tatifs. En premier lieu, l’adaptabilité est demandée comme réponse à des changements qui arrivent soit à l’intérieur du système, soit dans son en-vironnement. Dans ce deuxième cas, on dira que le système est sensible au contexte. En deuxième lieu, l’adaptabilité est atteinte avec des changements que le système effectue sur lui-même. Finalement, pour considérer qu’un système est pleinement adaptatif, ces changements doivent s’effectuer lors de l’exécution du système.
Récemment, Salehie et Tahvildari [ST09] ont proposé une vue d’en-semble très complète du domaine de l’adaptation, avec une énumération des défis à affronter dans ce domaine. Notamment, ils identifient la concep-tion pour l’adaptabilité : il faut proposer des approches, des paradigmes, des architectures et des modèles appropriés pour la prise en compte de l’adap-tabilité dans les systèmes depuis la phase de conception. Ces auteurs ont également signalé que le point clé dans les systèmes adaptatifs est que leur cycle de vie ne doit pas s’arrêter après leur développement et leur confi-guration initiale ; ce cycle doit continuer durant l’exécution du système, en répondant aux changements de l’environnement à tout moment.
Types d’adaptation
Dans leur travail, Salehie et Tahvildari [ST09] proposent une taxonomie de l’adaptation qui essaie de classifier les propriétés de l’adaptation. Notam-ment, on y trouve des éléments qui répondent à la question de comment réaliser l’adaptation. Parmi ces éléments, les considérations suivantes nous semblent importantes :
– Prise de décisions statique versus dynamique. Dans le mode statique, les réponses aux changements sont codées en dur dans le système. Dans le mode dynamique, ces décisions sont implantées par des politiques ou des règles externes qui peuvent être changées lors de l’exécution du système.
– Adaptation interne versus externe. Dans l’adaptation interne, la lo-gique d’adaptation est entremêlée avec la logique applicative. Dans l’adaptation externe, il existe un composant ou module, appelé ges-tionnaire d’adaptation, qui surveille le système et commande les chan-gements.
– Adaptation basée sur les modèles versus adaptation sans modèles. Dans le second cas, le mécanisme d’adaptation ne dispose pas d’un modèle spécifique de l’application ni de son contexte ; le mécanisme contient toutes les informations nécessaires implicitement dans son code interne. Dans l’adaptation basée sur les modèles, le mécanisme d’adaptation s’appuie sur des modèles explicites de l’application et du contexte qui permettent de prendre en compte toutes les infor-mations afin de réaliser l’adaptation.
– Adaptation réactive versus proactive. L’adaptation réactive agit une fois que les changements auxquels elle répond se sont produits. L’adaptation proactive intervient quand le système prédit que le changement va se produire.
Dans les systèmes qui présentent des contenus aux utilisateurs, deux types d’adaptation sont possibles : l’adaptation du contenu et l’adaptation de la présentation. Dans le premier cas, le système change les contenus à présenter en fonction de l’utilisateur. Par exemple, un système vidéo peut afficher des dessins animés si l’utilisateur est un enfant, tandis que, pour les adultes, il affichera des actualités économiques. L’adaptation de la pré-sentation, en revanche, change la façon de présenter un même contenu. Par exemple, un système qui présente des informations en mode texte peut basculer vers l’audio lorsqu’une personne malvoyante l’utilise.
Selon la façon de mettre en œuvre l’adaptation d’un système, nous pouvons trouver dans la littérature deux types principaux d’adaptation : l’adaptation comportementale et l’adaptation architecturale.
L’adaptation comportementale consiste à changer le comportement d’un système lors son exécution [GLT08]. L’intérieur des composants est mo-difié, mais le nombre de composants ou la façon dont ils sont connectés restent les mêmes. Le composant adapte son fonctionnement interne en fonction des changements.
L’adaptation architecturale consiste à changer la structure d’un système lors de son exécution. Le nombre et la nature des composants présents, ainsi que la façon dont ils sont connectés, changent [GCH+ 04].
Dans la suite, nous nous focalisons sur l’adaptation architecturale, car elle nous semble la plus pertinente pour les systèmes collaboratifs ubiqui-taires. En effet, les activités collaboratives sont intimement liées à l’archi-tecture qui les soutient. Lorsque la structure d’un groupe change, la façon dont sont reliés les composants collaboratifs peut être amenée à changer.
Salehie et Tahvildari [ST09] ont signalé que l’adaptation architecturale agit souvent sur des systèmes structurés en couches. L’adaptation peut modifier des éléments dans une ou plusieurs couches de l’architecture. Dans ce sens, Satyanarayanan [Sat04] a ajouté qu’il est difficile de conci-lier les systèmes à couches avec l’adaptation. Pour lui, les architectures en couches sont nécessaires, spécialement dans le cas de l’informatique ubiquitaire, pour rendre la conception des systèmes propre et modulaire. En revanche, cette décomposition en couches peut complexifier l’adapta-tion architecturale, car les actions d’adaptation doivent gérer des objets qui sont dispersés sur plusieurs niveaux de l’architecture. Il considère que cette conciliation entre les logiciels en couches et l’adaptation architectu-rale est un des défis importants de l’informatique ubiquitaire. Dans le cas des systèmes collaboratifs ubiquitaires, l’objet de l’adapta-tion architecturale est l’architecture de collaboration mise en place. Cette architecture est distribuée sur les différents dispositifs des utilisateurs et de l’environnement qui interviennent dans la collaboration. Lors d’une adaptation, on modifiera les composants collaboratifs déployés sur les dis-positifs, ainsi que les différents flux que ces composants s’envoient entre eux.
Par exemple, si un utilisateur A arrive dans un espace intelligent et rejoint une session dans laquelle il doit recevoir des données audio de l’utilisateur B, il faut que le système déploie un composant récepteur au-dio sur le dispositif personnel de A, puis un composant d’envoi audio sur le dispositif de B. Ensuite, il faut établir le flux audio qui va de B vers A.
Intelligence artificielle et sémantique
Une partie importante de nos travaux se base sur des techniques déve-loppées dans le domaine de l’intelligence artificielle, et notamment de la représentation des connaissances. Dans cette section nous présentons ce domaine, ainsi que le courant du Web Sémantique, qui a amélioré dans les dernières années la façon de prendre en compte la sémantique des données et des services dans le Web.
Petit historique de l’intelligence artificielle
Depuis l’antiquité, l’homme a rêvé de construire des machines artificielles capables de penser comme les hommes. On trouve de telles machines, par exemple, dans les mythes grecs ou dans ceux de l’ancienne Égypte. Plus récemment, des histoires de fiction comme Frankenstein de Mary Shelley ont utilisé l’idée de personnages artificiels dotés d’intelligence [Maz95]. Cette idée a été également abordée par les philosophes. En partant de l’hypothèse qu’elle peut être reproduite d’une façon mécanique, les phi-losophes ont essayé de reformuler la pensée humaine afin de la rendre formelle, comme les mathématiques. Aristote, Leibniz, Descartes ou Rus-sell sont quelques uns parmi les grands philosophes qui ont travaillé sur ce sujet [RN03].
En informatique, dans la décennie de 1950, les chercheurs ont com-mencé à envisager la possibilité de créer la pensée artificielle à l’aide des ordinateurs. Le domaine de l’intelligence artificielle (IA) naquit of-ficiellement en 1956 lors d’une conférence au Dartmouth College aux États Unis [RN03]. Parmi les participants à cette conférence se trouvaient ceux qu’on considère les pères de l’IA, comme McCarthy, Minsky, Ne-well ou Nilsson. Dans les années suivantes, ils travaillèrent dans le but de construire des machines et des algorithmes capables de fonctionner d’une façon autonome et de réfléchir. En plus de l’informatique, l’IA a reçu des contributions d’autres domaines très divers, tels que la psychologie cogni-tive, les mathématiques, la neurobiologie ou la philosophie.
Les premières années de recherche virent arriver beaucoup de suc-cès, et les chercheurs étaient très optimistes. Par exemple, Simon déclara en 1965 : « Dans une vingtaine d’années, les machines seront capables de réa-liser n’importe quel travail que les humains peuvent réaliser. » Cet optimisme s’effaça en grande partie dans les années 1970, quand les chercheurs com-mencèrent à se rendre compte de la difficulté intrinsèque de beaucoup des thèmes abordés [RN03]. Les ambitions du domaine ont été revues à la baisse. Ainsi, l’idée de créer des machines intelligentes a été peu à peu abandonnée, pour se focaliser sur des machines dotées de programmes figés, dont l’exécution produit des résultats qui se rapprochent de ceux produits par des comportements intelligents.
Quelques années plus tard, dans les années 1980, l’IA regagna de l’attention avec notamment les progrès dans le champ des systèmes ex-perts [Ign91] qui soulignèrent l’intérêt de l’étude de la connaissance.
Grâce à l’augmentation de la puissance de calcul, ce domaine a connu un nouvel essor dans les années 2000 avec l’émergence du Web, les mo-teurs de recherche, les agents, les technologies de reconnaissance de la voix, la robotique ou l’exploration de données (data mining), entre autres.
Champs d’étude de l’IA
L’IA se décompose en plusieurs sous-domaines qui ont donné naissance à des champs de recherche indépendants. Les principaux sous-domaines sont [RN03] :
– Représentation des connaissances. Ce champ se focalise sur la façon de représenter des connaissances dans les systèmes informatiques pour permettre notamment l’inférence, c’est-à-dire la déduction de nouvelles connaissances à partir de connaissances existantes.
– Traitement du langage naturel. Ce champ cherche à trouver des moyens automatiques pour que les machines puissent traiter le langage na-turel humain (français, anglais, etc.), tant écrit que parlé. Les deux principaux problèmes dans ce champ sont la génération automa-tique de langage naturel et sa compréhension.
– Perception. Ce champ offre la capacité d’apprendre des faits du monde à partir de données acquises par des capteurs tels que des ca-méscopes, des microphones, etc. On y trouve notamment les études sur la vision artificielle.
– Apprentissage. Le but dans ce champ est de créer des techniques qui permettent à un système informatique d’apprendre. Cela signifie que le système est capable de généraliser des connaissances de façon inductive à partir d’exemples non structurés.
– Planification. Le but de ce champ est de créer des techniques per-mettant aux machines de résoudre des problèmes en générant des plans. Un plan est une stratégie pour la résolution du problème, et consiste en plusieurs actions à réaliser dans un ordre spécifique. Ces plans permettent de résoudre des problèmes complexes, comme par exemple la décision de la trajectoire optimale d’un robot pour se déplacer d’un point à un autre dans une pièce.
Représentation des connaissances
Historiquement, la représentation des connaissances [BL04] a été une des branches centrales de l’IA. Le but de ce champ est de représenter les connaissances de façon à faciliter leur traitement automatisé par une ma-chine. En d’autres termes, les systèmes de représentation des connais-sances formalisent la pensée et le savoir humains.
Les connaissances sont des faits ou des prédicats, qui peuvent être vrais ou faux. Par exemple, dans la phrase « Jean sait que la voiture de Claire est bleue », on énonce que Jean possède une certaine connaissance, qui est contenue dans la proposition « la voiture de Claire est bleue ». Si, dans le monde réel, la voiture de Claire est vraiment bleue, cette proposition est vraie ; si elle est, par exemple, rouge, alors la proposition est fausse. La connaissance implique une certaine façon de concevoir le monde. Dans l’exemple précédent, Jean considère que la voiture de Claire est bleue et non pas d’une autre couleur.
Le terme représentation met en relation deux domaines, où l’un d’entre eux remplace, ou représente, l’autre [BL04]. On utilise un domaine à la place de l’autre car ce premier domaine est plus concret, plus immédiat ou plus accessible que le deuxième. Par exemple, quand on écrit le mot chien, on utilise le domaine des lettres, dont font partie la lettre C, la lettre H, etc., pour représenter le domaine des animaux. En conséquence, la re-présentation des connaissances étudie l’utilisation de symboles formels afin de représenter des propositions.
Un concept important lié à la représentation des connaissances est ce-lui de raisonnement. Le raisonnement ou inférence est la capacité de traiter les connaissances que l’on possède afin de produire des nouvelles connais-sances. Par exemple, si l’on sait que « Claire est la femme de Jean » et que « la voiture de Claire est bleue », alors on peut inférer que « La voiture de la femme de Jean est bleue ». Ce fait n’était pas parmi l’ensemble initial de faits connus, du moins explicitement. Le raisonnement a rendu explicite cette connaissance qui était implicite.
Ainsi que le signalent Brachman et Levesque [BL04], le raisonnement est intimement lié à la représentation des connaissances. Pour eux, le point le plus important est justement l’interaction entre la représenta-tion des connaissances et le raisonnement. En effet, la capacité à effectuer des raisonnements dépend directement de la façon dont on représente les connaissances. Brachman et Levesque [LB87] ont souligné le compromis qu’il faut faire entre l’expressivité d’un langage de représentation et la complexité du raisonnement avec ce langage. Plus les constructions d’un langage sont complexes, et plus le raisonnement sera complexe en termes de calcul. Ceci a des fortes implications pour l’implantation d’algorithmes qui effectuent le raisonnement. Une autre propriété importante des lan-gages est la décidabilité. Un langage est dit décidable s’il existe un al-gorithme qui peut décider en un nombre fini de pas si, en partant d’un ensemble de connaissances, un fait est vérifié ou non.
Ainsi, une grande partie des efforts fournis dans ce champ ont été orientés vers la recherche de systèmes qui représentent les connaissances d’une façon aussi compréhensible que possible et avec lesquels on puisse réaliser des raisonnements aussi efficacement que possible.
Parmi les premiers systèmes de représentation des connaissances, les plus importants furent les systèmes de cadres (frame systems) [Min75] et les réseaux sémantiques [Qui67]. Ces systèmes n’étaient pas basés sur la logique, mais sur des structures de données en forme de réseau qui imitent la structure de la mémoire humaine. Les systèmes basés sur la logique sont plus récents. On y trouve notamment la logique de description [BCM+ ], qui a été créée comme une extension des cadres et des réseaux sémantiques en ajoutant une base formelle construite sur la logique de premier ordre.
Le Web Sémantique
Les techniques de représentation des connaissances ont récemment subi un regain d’intérêt dans le cadre de l’initiative connue sous le nom de Web Sémantique. Cette initiative fut lancée par Tim Berners-Lee et al. en 2001 [BLHL01]. Berners-Lee partit d’un constat : l’énorme expansion du Web a produit des quantités immenses de données non structurées qui sont disponibles en ligne. Toute cette information n’est pas facilement exploitable. D’un côté, les humains sont capables de la comprendre, de la parcourir et de trouver des relations entre des données, mais l’échelle phénoménale que le Web a atteint1 rend cette possibilité irréalisable dans la pratique. D’un autre côté, les machines, qui ont une grande capacité de traitement, ne peuvent pas comprendre l’information car elle n’est pas représentée d’une façon structurée qui facilite les traitements.
La solution proposée dans le cadre du Web Sémantique est d’ajou-ter des métadonnées aux données contenues dans le Web. Les métadon-nées sont des données qui décrivent les données ordinaires du Web : elles peuvent décrire un document en soi (par exemple sa date de publication ou son auteur) ou des entités, des personnes, des organisations, etc. qui sont mentionnées dans le document. Afin de rendre le traitement le plus automatique possible, les métadonnées sont exprimées d’une façon struc-turée ou formelle. Le but final est de fournir des outils qui puissent par exemple trouver des informations pour les utilisateurs, même si ces in-formations sont dispersées sur plusieurs documents qui ne sont pas liés entre eux. Ce concept peut être étendu pour aussi prendre en compte des services (par exemple des Services Web).
Le mot sémantique vient du fait que les métadonnées décrivent en quelque sorte le sens des données de telle manière que les machines peuvent l’interpréter. En définitive, cette approche transforme le Web, en le faisant passer d’un ensemble chaotique de données éparses vers une vraie bibliothèque globale pleine de connaissances.
Les métadonnées sont en fait une façon de représenter les connais-sances contenues dans un document. Le Web Sémantique s’est naturelle-ment tourné vers les diverses techniques développées dans le champ de la représentation de connaissances afin d’exprimer les métadonnées. Dans ce cadre, plusieurs langages ont été développés. Notamment, on trouve Ressource Description Framework (RDF), RDF Schema (RDFS) et Web Onto-logy Language (OWL2) [SWM04]. Chacun de ces langages se base sur le précédent, et chacun possède une syntaxe en XML qui est utilisée dans les documents Web. OWL permet l’expression d’ontologies, une ontologie étant, selon la définition de Gruber [Gru93], « une spécification formelle d’une conceptualisation d’un domaine de connaissance ». Une ontologie est donc une représentation des connaissances d’un certain domaine, qui sert comme modèle partagé de ce domaine et qui peut être traitée automatiquement par une machine. Une ontologie OWL est constituée principalement de concepts et de relations entre ces concepts.
Il existe trois variantes du langage OWL qui se différencient selon leur expressivité : OWL-Lite, OWL-DL (pour Description Logics) et OWL-Full. Chacune de ces variantes est contenue dans la suivante, qui ajoute des éléments qui augmentent l’expressivité. OWL-Lite est la variante la plus simple, servant principalement à la création de hiérarchies de classifica-tion. OWL-DL a été conçu pour fournir une expressivité maximale tout en restant complet et décidable. Le nom d’OWL-DL provient du fait qu’il correspond à une logique de description SHOIN (D). L’interprétation de cette notation est la suivante : S, raccourci pour ALC, indique qu’il s’agit d’une logique de description attributive avec négation de concepts. OWL-DL permet aussi l’expression de hiérarchies de rôles (H), de concepts énu-mérés (O), de rôles inverses (I), de restrictions dans la cardinalité des rôles (N ) et de types de données ((D)) [BCM+ ]. La dernière variante, OWL-Full, est celle qui fournit la plus grande expressivité des trois (par exemple elle permet d’enrichir le vocabulaire RDF/OWL), mais la pro-priété de décidabilité du raisonnement est perdue avec cette variante.
En général, OWL-DL offre un bon compromis entre l’expressivité four-nie et la capacité d’effectuer des raisonnements. Cette variante est donc la plus utilisée en pratique. Le fait qu’elle soit basée sur la logique de des-cription implique que les bases théoriques du raisonnement avec OWL-DL sont formelles, et donc solides et bien définies. Concrètement, l’inférence est possible en utilisant les algorithmes développés dans le cadre de la logique de description.
|
Table des matières
Liste des tableaux
1 Introduction
1.1 Contributions apportées dans ce mémoire
1.2 Organisation du mémoire
2 État de l’art et synthèse
2.1 Informatique ubiquitaire
2.2 Collaboration
2.2.1 Sessions
2.2.2 Gestion des sessions et déploiement
2.2.3 Collaboration et informatique ubiquitaire
2.3 La notion de contexte
2.3.1 Définition
2.3.2 Taxonomie des données contextuelles
2.3.3 Sensibilité au contexte
2.3.4 Solutions pour la prise en compte du contexte
2.4 Adaptation
2.4.1 Définition
2.4.2 Types d’adaptation
2.5 Intelligence artificielle et sémantique
2.5.1 Petit historique de l’intelligence artificielle
2.5.2 Champs d’étude de l’IA
2.5.3 Représentation des connaissances
2.5.4 Le Web Sémantique
2.6 Synthèse des travaux existants et positionnement
2.6.1 Gestion de la collaboration avec des ontologies
2.6.2 Systèmes collaboratifs pour les environnements ubiquitaires
Conclusion
3 Ontologie Générique de la Collaboration (GCO)
3.1 Introduction aux ontologies OWL
3.1.1 Définition des éléments d’une ontologie OWL
3.1.2 Raisonnement avec OWL
3.1.3 Règles SWRL
3.1.4 Outils pour le traitement des ontologies OWL et des règles SWRL
3.2 Description de GCO
3.2.1 Vue d’ensemble du modèle
3.2.2 Description détaillée
3.3 Règles associées à GCO et raisonnement
3.3.1 Règles associées à GCO
3.3.2 Inférence et traitement des règles
3.4 Principes de conception et propriétés de GCO
3.4.1 Langage
3.4.2 Contenu de l’ontologie
3.4.3 Généricité et extensibilité
3.4.4 Utilisation dans des architectures multi-niveaux
3.4.5 Simplicité et performances
3.4.6 Nomenclature
3.4.7 Autres principes suivis
3.5 Utilisation de GCO dans un système runtime
Conclusion
4 Facus : un Framework Adaptatif pour les SCUs
4.1 Approche d’adaptation multi-niveaux pour les SCUs
4.1.1 Approche multi-niveaux générique
4.1.2 Application de l’approche aux SCUs
4.2 Modèles et transformations de Facus
4.2.1 Modèles des niveaux
4.2.2 Transformations entre niveaux
4.3 Conception et implantation de Facus
4.3.1 Architecture de Facus
4.3.2 Acquisition des données de contexte
4.3.3 Service de déploiement de composants
4.3.4 Outils, langages et technologies utilisés dans Facus
4.3.5 Utilisation de Facus
4.3.6 Fonctionnement de Facus et processus d’adaptation
Conclusion
5 Expérimentations
5.1 Présentation du projet européen UseNet
5.2 Application d’illustration : jeu de bataille navale
5.2.1 Description de l’application
5.2.2 Conception et implantation de l’application
5.3 Évaluation fonctionnelle de Facus
5.3.1 Ontologie de niveau application
5.3.2 Utilisation de Facus par l’application
5.3.3 Déroulement de l’adaptation multi-niveaux
5.4 Évaluation des performances de Facus
5.4.1 Temps d’exécution de l’adaptation
Conclusion
Conclusion générale
Bilan des contributions
Perspectives
Réalisation
Nouvelles fonctionnalités
Liste des publications personnelles
Bibliographie
Télécharger le rapport complet
