L’ingénierie dirigée par les modèles

L’ingénierie dirigée par les modèles

L’informatique pervasive et les applications sensibles au contexte 

Introduction

Ces dernières années ont vu apparaitre toute une gamme d’outils informatiques d’un type nouveau capables d’accompagner les activités quotidiennes de l’être humain. Par exemple, des téléphones portables utilisables comme cartes de crédit ou qui passent automatiquement en mode silencieux lors de l’entrée en réunion. Les applications ont également évolué pour s’adapter à ces nouveaux outils, qualifiés de pervasifs. L’informatique pervasive, également appelée ubiquitaire, s’occupe du développement des applications qui automatisent ces activités non traditionnelles. Le terme «informatique ubiquitaire» a été présenté pour la première fois en 1991, par Weiser . Il a idéalisé un environnement intelligent doté de capteurs ayant pour objectif de réaliser certaines activités sans l’interférence humaine. La caractéristique essentielle des applications pervasive est d’anticiper le comportement de l’utilisateur en réagissant sans son intervention et de manière transparente.
L’importance croissante de l’informatique pervasive fait que des nombreux travaux récents s’y intéressent par la proposition d’un nouveau genre d’applications dites sensibles au contexte. La sensibilité au contexte concerne la perception de l’environnement pour interagir plus naturellement avec l’utilisateur. Cette perception passe par l’utilisation de capteurs de l’environnement physique, de matériels auto-descriptifs, de description des personnes, etc. Le contexte fournit un grand éventail d’informations qui permet au système pervasif d’agir de façon adaptée. Dans ce chapitre, nous allons présenter toutes les notions de base de l’informatique pervasive et les applications sensibles au contexte

L’informatique pervasive

En 1991, Mark Weiser a inventé l’expression de l’informatique pervasive (également appelée ubiquitaire, diffuse, ambiante, nomade,. . .). Il parlait alors d’une informatique invisible présente en tout lieu, à tout moment et en toute chose. Il a idéalisé un environnement intelligent doté de capteurs ayant pour objectif de réaliser certaines activités sans l’interférence humaine Actuellement, avec la miniaturisation des matériels informatiques, de nombreux objets informatisés se trouvent intégrés dans notre quotidien et font peu à peu disparaitre l’idée de l’ordinateur personnel comme le seul assistant numérique informatisé. Ainsi, Gaëtan Rey et al.,  ont défini un système d’informatique pervasive comme : – « Multi-utilisateurs », puisque dans un même espace de nombreux utilisateurs peuvent être amenés à utiliser les mêmes ressources et à communiquer de manière concurrente. – « Multi-dispositifs », car de nombreux objets physiques potentiellement informatisés et communicants peuvent nous entourer.
– « Multi-environnements », puisqu’ils sont mobiles tout comme les utilisateurs et peuvent changer d’emplacement et donc d’environnement. – « Multi-applications », puisque de nombreuses applications reposant sur ces objets communicants peuvent être conçues. L’informatique pervasive repose donc sur un ensemble d’entités environnementales en interaction – Une entité ambiante peut être un « être vivant », c’est-à-dire un utilisateur ou plus généralement une entité dotée de capacités sensori-motrices, voire cognitives. – Elle peut-être aussi un système informatisé. Ces systèmes reposent alors sur une infrastructure d’objets physiques appelés aussi dispositifs, qui peuvent offrir à leur tour une interface logicielle, appelée infrastructure logicielle, pour le reste du système informatisé. C’est sous ces contraintes que la partie logicielle modifiable du système permet in fine de mettre en œuvre de nouvelles fonctionnalités pour de nouvelles applications. D’une façon générale et en se basant sur la définition de, « L’informatique pervasive rend l’information/service disponible partout et à tout moment ». Actuellement les applications informatiques fonctionnent dans une variété de nouveaux paramètres, par exemple, embarqués dans des voitures ou des appareils portables. Ils utilisent des informations sur leur contexte pour réagir et s’adapter aux changements dans l’environnement informatique. Ils deviennent de plus en plus pervasives et sensibles au contexte.

Les applications sensibles au contexte

L’objectif premier d’un système pervasif est de permettre de répondre au besoin de l’utilisateur où qu’il se trouve et à n’importe quel moment. La caractéristique essentielle des applications pervasives est d’anticiper le comportement de l’utilisateur en réagissant sans son intervention et de manière transparente. Par exemple, des téléphones portables utilisables comme cartes de crédit ou qui passent automatiquement en mode silencieux lors de l’entrée en réunion, des réfrigérateurs capables de commander par Internet des produits en fonction du besoin, des maisons qui adaptent la coloration de l’éclairage en fonction de l’humeur des habitants, des dispositifs GPS qui guident le conducteur en tenant compte non seulement du trajet mais également du trafic routier et de la dépense en carburant. L’importance croissante de ces applications fait que des nombreux travaux récents s’y intéressent. Abowd et al.  proposent de classer ces travaux en quatre axes : les interfaces naturelles, la capture et l’accès automatisé des activités humaines, l’informatique du quotidien et l’informatique sensible au contexte. Le travail de cette thèse se situe dans ce denier axe. L’informatique sensible au contexte se focalise sur le développement des applications qui prennent en compte le contexte d’utilisation et qui fournissent des solutions adaptées aux besoins des utilisateurs. Dans ce qui suit, nous allons aborder avec des exemples les concepts de base qui rentrent dans le développement de ces applications sensibles au contexte.

Contexte

Dans le domaine de l’informatique pervasive, de nombreuses recherches de développement des systèmes sensibles au contexte ont été proposées mais différemment et sans connaitre un consensus sur la définition de contexte et sa modélisation. Dans cette section vous voudrions donner les définitions de contexte les plus proches et les plus répandues avec quelques exemples.

Définitions

Qu’entend-t-on par « information de contexte » dans les systèmes sensibles au contexte ? Quelle est la signification du contexte qui a fait l’objet de nombreux travaux ? Diverses définitions du terme sont données dans la littérature et résumées dans . Au début, les définitions ont été données pour des contextes d’applications spécifiques en énumérant les concrètes entités contextuelles. Par exemple, les auteurs de  définissent le contexte comme étant des informations sur la localisation, l’identité des personnes à proximité et les conditions physiques. Dans, Les auteurs ajoutent à cette définition la notion de temps. D’autres définitions sont extrêmement large, la plus populaire est donnée par : « Le Contexte est toute information qui caractérise la situation d’une entité. Une entité étant une personne, un lieu ou un objet considéré comme pertinent relativement à une interaction entre un utilisateur et une application, incluant l’utilisateur et l’application eux-mêmes ». Les auteurs donnent une définition générale qui peut être utilisée dans un large champ d’applications sensibles au contexte. Pour affiner leur définition, ils identifient quatre catégories de contexte qui leur semblent pratiquement plus importantes que d’autres. Il s’agit de la localisation, l’identité (l’utilisateur), activité (Etat) et le temps. Dans , l’auteur approuve cette dernière définition et affirme qu’elle couvre tous les travaux proposés dans le contexte. Cependant, il la considère comme étant une définition générale qui ne se limite pas au contexte. Ainsi, il propose sa propre définition dans laquelle limite le contexte à «un ensemble d’informations, qui est structuré et partagé. Il évolue et est utilisé pour l’interprétation » La définition proposée dans  présente, également, le contexte comme étant organisé de façon hiérarchique. Dans cette proposition, les auteurs distinguent entre les informations environnementales qui déterminent le comportement des applications mobiles et qui ont pertinentes à l’application. Ils définissent ainsi le contexte comme « l’ensemble des états environnementaux et les paramètres qui déterminent chacun un comportement d’une application ou dans lequel un évènement d’application se produit et qui est intéressant pour l’utilisateur ». Comme indiqué précédemment, il est difficile de donner une définition complète du terme contexte et, en fait, la notion de contexte n’est pas universelle mais relative à une situation et au domaine de l’application [30]. Typiquement, le contexte devrait contenir des informations sur l’identité de l’utilisateur, sur son activité, sur le moment où le contexte est capturé et sur la localisation du client terminal. Fondamentalement, il convient de répondre aux questions suivantes « Qui ? », « Quoi ? », « Quand ? » et « Où ? » et, idéalement, devrait permettre au système de répondre à une dernière question : « Pourquoi ? »

Exemples

Quelques exemples d’entités et leurs contextes associés : – Dispositif utilisé : bande passante de la connexion réseau, disponibilité de la mémoire, charge du processeur, taille d’écran et modes d’interaction avec l’utilisateur. – Utilisateur : identité de l’utilisateur, sa langue maternelle, sa localisation géographique. – Salle : niveau de lumière ou de bruit, température.

Types de contexte

Nous distinguons deux types de contexte selon sa nature : Le contexte peut être statique (information qui ne devrait pas changer, par exemple, langue maternelle) ou dynamique (informations qui change au fil du temps, comme les conditions météorologiques). Donc, la prise en compte des deux types de contexte est crucial dans tous les propositions de développement des applications sensibles au contexte et, particulièrement, le contexte dynamique qui nécessite une adaptation au moment de l’exécution pour des réponses adéquates et rapides à l’utilisateur sans aucune intervention de sa part. Une application sensible au contexte en cours d’exécution doit être adaptée de manière dynamique lors de l’exécution si un changement de contexte se produit, principalement dans les systèmes en temps réel où il n’y a pas de temps à perdre (soins de santé, circulation de l’air ; trafic aérien, …). Par exemple, l’annulation d’un vol (comme une adaptation sensible au contexte) doit être menée s’il y a une chute forte de neige (comme une information de contexte). En conséquence, l’adoption d’une stratégie d’adaptation dynamique à l’exécution devient très essentiel dans le cycle de vie des applications sensibles au contexte.

Modélisation du contexte

Dans la littérature de modélisation de contexte, nous trouvons plusieurs modèles contextuels proposés dans le domaine de l’informatique pervasive. D’où, nous pouvons les classer comme suit : Les premiers modèles étaient de type « clé-valeur » qui a emprunté le mécanisme de base de données (relationnelles ou XML) pour mettre la valeur de l’information contextuelle comme une variable d’environnement (ou clé). Par la suite, les méthodes traditionnelles de génie logiciel ont été appliqué pour représenter le contexte : le modèle graphique comme ORM (Object-Role modeling) et UML, et le modèle orienté objet. Le modèle graphique fournit une vue claire et intuitive de contexte en décrivant les faits et les propriétés en tant que nœuds et les relations entre eux comme des arêtes. Le modèle orienté objet permet l’usage de leurs propres caractéristiques de l’encapsulation et de la réutilisation pour introduire l’abstraction et le mécanisme efficace de la classification pour la modélisation du contexte. Par rapport à ces approches de modélisation contextuelles, le modèle logique ne pas se préoccuper de la façon dont le contexte est organisé ou représenté. Mais, il fournit un modèle formel et abstrait en utilisant le raisonnement avec une partie de potentiel disponible de contexte et la résolution de la compatibilité entre les différents contextes. Cependant, les modèles ontologiques ont les avantages des approches orientées objet et de la logique de modélisation. ils fournissent un moyen formel pour modéliser le contexte dans des terminologies bien structurées, et soutiennent également le raisonnement formel. Selon , les ontologies offrent un meilleur formalisme pour construire les terminologies consensuelles du domaine de contexte d’une façon formelle afin qu’ils puissent être plus facilement partagées et ré-utilisées par les différents partenaires des environnements mobiles et ubiquitaires. La modélisation avec les ontologiques ont des avantages évidents en ce qui concerne le soutien à l’interopérabilité et de l’hétérogénéité. Ces avantages permettent de considérer que les modèles de contexte à base d’ontologie sont les plus appropriés pour représenter les informations de contexte. Dans le chapitre 5, nous présenterons notre modèle de représentation de contexte en se basant sur les ontologies.

Sensibilité au contexte

La principale caractéristique de l’informatique pervasive est le changement dynamique de leurs environnements ou bien, plus précisément, leurs contextes. Pour mieux aider l’utilisateur dans ses tâches quotidiennes, les systèmes informatiques pervasifs doivent tenir compte du contexte global et adapter leurs services aux utilisateurs selon le changement de ce dernier. Cette aptitude est connue sous le nom de « sensibilité au contexte »

Définitions

La terminologie de sensibilité au contexte a été évoquée pour la première fois par Schilit et al., dans [108] et présentée comme « un logiciel qui s’adapte en fonction de son lieu d’utilisation, la collection des personnes et des objets à proximité, ainsi que les modifications apportées à ces objets dans le temps ». Depuis lors, il y a eu de nombreuses tentatives pour définir cette terminologie. Dans [101], l’auteur définit la sensibilité au contexte comme « la capacité d’un programme ou d’un dispositif à sentir ou capturer différents états de son environnement et de lui-même ». Compte tenu de ces deux définitions, une application sensible au contexte doit avoir la capacité de capturer les entités contextuelles nécessaires de son environnement d’exécution, les utiliser pour adapter son comportement et, enfin, présenter les services disponibles et appropriés à l’utilisateur. Dans [46], les auteurs introduisent une autre définition dans laquelle ils insistent sur l’utilisation du contexte et de la pertinence des informations de contexte. Les auteurs estiment qu’« un système est sensible au contexte s’il utilise le contexte pour fournir des informations pertinentes et/ou des services à l’utilisateur, où la pertinence dépend de la tâche de l’utilisateur ». Les applications sensibles au contexte doivent donc être capables de collecter des informations de contexte, de les interpréter, de les analyser et d’adapter, en conséquence, leur comportement aux changements de contexte pour satisfaire au mieux l’utilisateur final. Ainsi, Dey [47] et Abowd [3] définissent trois catégories de fonctionnalités des applications sensibles au contexte, à savoir :– Les informations et les services qui peuvent être présentés à l’utilisateur dans le contexte courant. Ceci inclut la sélection d’informations de proximité (« où est la banque la plus proche ? ») et de services (interface modifiable) ;– L’exécution automatique d’un service dans un certain contexte. Ceci inclut les actions initiées par des déclencheurs de contexte (« context triggered actions »), par exemple un téléphone qui change son volume d’écoute en fonction du bruit ambiant ; – L’étiquetage du contexte à l’information pour une restitution ultérieure.

Exemples

Quelques exemples de la sensibilité au contexte : – Avertissement lorsqu’une personne est à proximité. – Affichage d’une position géographique. – Ajustement de sa vitesse en fonction de la distance du véhicule qui est devant. – Démarrage d’une synchronisation lorsque le réseau est rétabli. – Modification de la température de la pièce en fonction des personnes présentes. – Arrêt de la radio lors de la réception d’un appel téléphonique. – Message SMS visuel ou vocal (si je suis dans ma voiture).

 Architecture générale d’un système sensible au contexte

La séparation entre la détection et l’utilisation du contexte est nécessaire afin d’améliorer l’extensibilité et la réutilisabilité dans le système [118]. Dans cette perspective, la Figure 2.2 proposée dans [12] illustre une architecture en couches pour les systèmes sensibles au contexte, permettant de séparer les parties détection et utilisation, en y ajoutant la partie interprétation et raisonnement. Une description détaillée de ces différentes couches est donnée dans [12]. D’après plusieurs travaux [34, 74, 64], un système sensible au contexte a plusieurscomposants, tel que un capteur de contexte, stockage du contexte, raisonneur du contexte et consommateur du contexte. Ces composants sont logiquement séparés des applications qu’ils supportent. Ainsi, dans [124], les auteurs présentent et décrivent les éléments de base qui composent les systèmes sensibles au contexte dans l’environnement des services Web Ils proposent une séparation explicite [118] entre : – Les services sensibles au contexte et les applications : ils utilisent les informations du contexte et les outils supportés, afin de réagir « intelligemment » (être sensible au contexte). – Les composants de la sensibilité au contexte : ils aident les applications et les services en captant et fournissant les informations du contexte. Des exemples de ces composants sont les capteurs, les enregistreurs de contexte et les moteurs de raisonnement sur le contexte.

Les applications sensibles au contexte et SOA

En observant dans les travaux proposés pour le développement des applications sensibles au contexte, nous trouvant que la majorité [74, 116, 115, 72, 73] adoptent et préconisent la réalisation de telles applications sur des plateformes basées sur l’architecture orientée services (calque de l’anglais service oriented architecture, SOA) pour les gains qu’elle apporte tel que le faible couplage et l’interopérabilité.

L’architecture orientée services (SOA)

Le SOA [50]est une architecture logicielle permettant la conception des systèmes à base d’un assemblage de services développés dans différents langages de programmation, déployés sur différentes plateformes et systèmes d’exploitation. Chaque service représente un composant logiciel autonome de traitement et de gestion de données, communiquant avec son environnement à l’aide de messages. Ce terme est apparu au cours de la période 2000-2001 et concernait à l’origine essentiellement les problématiques d’interopérabilité syntaxique en relation avec les technologies d’informatique utilisées dans les entreprises. L’objet de base dans une architecture orientée services est la notion de service, c’està-dire une fonction encapsulée dans un composant que l’on peut interroger à l’aide d’une requête composée d’un ou plusieurs paramètres d’entrée et fournissant un ou plusieurs résultats. Avec SOA, chaque service doit être indépendant des autres afin de garantir sa réutilisabilité et son interopérabilité. Plusieurs avantages seront gagnés par l’adoption d’une architecture SOA dans le domaine de développement logiciel [50], à savoir : – Les services sont réutilisables : ils sont conçus de façon à ce qu’ils puissent être réutilisés ultérieurement. – Les services interagissent à travers un contrat formel : pour pouvoir interagir, les services utilisent un contrat formel qui décrit chaque service et définit les termes de l’échange d’information. – Les services sont faiblement couplés : ils sont conçus pour interagir avec le minimum d’interdépendances. – Les services font abstraction de la logique métier : la seule partie visible du service est la partie exposée par le contrat de service (appelée interface publique). La logique sous-jacente du service est invisible et hors de portée du demandeur du service. – Les services sont composables : les services peuvent être associés entre eux pour réaliser une fonction particulière (ex. processus métier). Ceci permet la représentation de la logique métier selon plusieurs niveaux de granularité et facilite la réutilisation et la création de plusieurs niveaux d’abstraction – Les services sont autonomes : les tâches accomplies par un service possèdent des limites. Le service possède un contrôle suivant cette limite et ne dépend pas d’autres services pour accomplir sa tâche.
La composition, le faible couplage et la flexibilité de réaction garanties par ces avantages permettent l’architecture orientée services de contribuer d’une manière efficience dans la construction des applications sensibles au contexte à base de services comme nous allons présenter dans les chapitres 6 et 7. Aussi, le SOA peut être implémenté par plusieurs plateformes et technologies existantes telles que, les services Web avec les spécifications de WS-*, les services Web de type REST (REpresentational State Transfer)  OSGI Alliance  ESB (Enterprise Service Bus)  Beaucoup de travaux de développement des applications sensibles au contexte à base de services utilisent la technologie des services Web dans leurs réalisations comme une plateforme basée SOA. Les services Web reposent principalement sur des technologies basées sur XML pour la structure et le contenu de messages échangés entre services (SOAP), pour la description fonctionnelle et non fonctionnelle des services (WSDL), pour la découverte et le courtage des services (UDDI, WS-Discovery) et pour leurs orchestrations (BPEL). L’ensemble de ces technologies est appelé WS-*  En revanche, écrire des applications SOA avec de nombreux services Web, n’est pas toujours chose aisée. Notamment, la mise en œuvre des services Web (WS-*, REST, etc.) demande du temps et surtout du code technique en plus des classes métiers. Pour notre cas, nous proposons d’utiliser un autre modèle ouvert de la plateforme SOA fondé sur l’ingénierie logicielle à base de composants (CBSE), en l’occurrence, l’architecture à base de composant-service (SCA) qui s’avère prometteuse pour le développement des applications sensibles au contexte à base de services, notamment pour la facilité qu’elle offerte quant à l’adaptation en temps d’exécution de ces applications.

 L’ingénierie logicielle à base de composants (CBSE)

A l’instar de la programmation orientée objet (POO), l’ingénierie logicielle à base de composants (notée CBSE pour component-based software engineering) définit le composant comme étant l’élément de base d’une application. Celui-ci peut être vu comme une entité indépendante encapsulant un code métier correspondant aux opérations qu’il peut effectuer [63]. La programmation par composant permet de définir plus aisément une architecture pour l’application. Elle permet aussi d’organiser l’interopération entre les objets formant chaque composant. En effet, l’accès au code métier d’un composant est limité à un ensemble d’interfaces appelées généralement les interfaces fournies ou requises. Les interfaces fournies représentent les interfaces par lesquelles un autre composant peut accéder aux fonctionnalités offertes par le composant et les interfaces requises correspondent à celles permettant au composant d’accéder aux fonctionnalités des autres composants. Ces interfaces clientes sont généralement nécessaires au bon fonctionnement du composant. Parmi plusieurs modèles de composants proposés, nous nous sommes intéressés plus particulièrement par le modèle Fractal [31] qui est la base de notre plateforme cible FraSCAti et qui sera utilisée ultérieurement dans ce mémoire.

L’architecture à base de composant-service (SCA)

L’architecture orientée services a besoin des plateformes logicielles plus appropriées et beaucoup plus flexibles pour la livraison, le support et la gestion d’applications distribuées conformes à ses principes. Le Service Component Architecture (SCA) vise à accomplir ce besoin à l’aide des spécifications technologiques agnostiques soutenant la mise en place d’un service comme un composant logiciel. SCA est un ensemble de spécifications pour la construction d’applications distribuées et des systèmes utilisant les principes de SOA  et CBSE. Les spécifications SCA définissent la façon de créer et d’assembler les composants dans des applications complètes . Un composant implémente généralement une logique métier, qui est exposée sous forme d’un ou plusieurs interfaces « services ». Et également, un composant peut se servir des services fournis par d’autres composants, dans ce cas, il peut s’appuyer sur l’utilisation des interfaces « références ». Enfin, un composant peut aussi définir une ou plusieurs propriétés dont chacune contient une valeur qui peut être lue lorsque le composant est instancié Dans la deuxième partie de ce mémoire, nous allons voir comment exploiter les avantages de SCA afin de construire nos applications sensibles au contexte à base de services.

Conclusion

L’informatique pervasive a pour objectif de fournir les informations/services adéquats à l’utilisateur où il se trouve dans son environnement. Le nouveau type des applications sensibles au contexte permettent de satisfaire cet objectif en se basant sur les informations de contexte recueillies de l’environnement, l’utilisateur et l’application pour réaliser la sensibilité au contexte et déterminer le comportement de l’application que devrait prendre selon les différentes situations contextuelles. Aussi, nous avons vu, dans ce chapitre, l’architecture orientée services (SOA) qui répond bien à la réalisation de ces applications sensibles au contexte avec la technologie des services Web. Actuellement, le SOA est renforcé en plus par la nouvelle architecture à base de composant-service (SCA) qui permet l’utilisation de plusieurs plateformes d’exécution y compris les services Web.Dans le chapitre suivant, nous présenterons le développement dirigée par les modèles et qui sera utilisé, ultérieurement, pour proposer notre approche de développement des applications sensibles au contexte à base de services.

Table des matières

Introduction Générale
1.1 Contexte et Motivation
1.2 Objectif et Étapes de Recherche
1.3 Organisation du mémoire
I Contexte Technologique et État de l’Art 
2 L’informatique pervasive et les applications sensibles au contexte
2.1 Introduction
2.2 L’informatique pervasive
2.3 Les applications sensibles au contexte
2.3.1 Contexte
2.3.1.1 Définitions
2.3.1.2 Exemples
2.3.1.3 Types de contexte
2.3.1.4 Modélisation du contexte
2.3.2 Sensibilité au contexte
2.3.2.1 Définitions
2.3.2.2 Exemples
2.3.2.3 Architecture générale d’un système sensible au contexte
2.4 Les applications sensibles au contexte et SOA
2.4.1 L’architecture orientée services (SOA)
2.4.2 L’ingénierie logicielle à base de composants (CBSE)
2.4.3 L’architecture à base de composant-service (SCA)
2.5 Conclusion
3 Le Développement Dirigé par les Modèles
3.1 Introduction
3.2 L’ingénierie dirigée par les modèles
3.2.1 Le Modèle
3.2.2 Le Metamodèle
3.3 L’approche MDA
3.3.1 Processus de développement dans MDA
3.3.1.1 Le modèle d’exigences CIM
3.3.1.2 Le modèle PIM 0
3.3.1.3 Le modèle PSM
3.3.1.4 Transformations du modèle CIM au modèle PSM
3.3.2 Modélisation et métamodélisation dans MDA
3.3.3 Transformation des modèles dans MDA
3.3.3.1 Les différentes approches de transformations de modèles
3.4 Le développement dirigé par les modèles (MDD)
3.4.1 Présentation
3.4.2 MDD et les applications sensibles au contexte
3.4.3 Une autre plateforme PSM basée sur SOA
3.4.3.1 FraSCAti
3.5 Conclusion
4 Approches MDD pour le développement des applications sensibles au contexte : État de l’art     4.1 Introduction
4.2 Classification des approches
4.2.1 Approche de ContextUML
4.2.1.1 Modélisation du Contexte
4.2.1.2 Modélisation de la Sensibilité au Contexte
4.2.1.3 Avantages de ContextUML
4.2.2 Approches basées sur ContextUML
4.2.2.1 ContextUML et les Aspects
4.2.2.2 Modélisation du Contexte pour la Réalisation des Services Mobiles Simples
4.2.3 Approches basées sur UML et MOF
4.2.3.1 Un metamodèle MOF pour le Développement des Applications Mobiles Sensibles
4.2.3.2 Développement Dirigé par les Modèles des Applications Web Composites Sensibles
4.2.4 Approches ad-hoc basées sur un DSL
4.2.4.1 Development Dirigé par les Modèles des Services Sensibles au Contexte
4.2.4.2 Modèle de Rôle Dépendant du Contexte
4.3 Évaluation et leçons apprises
4.4 Conclusion
II Contributions et Étude de Cas 
5 Modélisation de Contexte avec les Ontologies
5.1 Introduction
5.2 Un métamodèle de contexte
5.3 Les ontologies et le contexte
5.3.1 Définition des ontologies
5.3.2 Avantages des ontologies dans la modélisation du contexte
5.3.2.1 Formalisme extensible à grande échelle
5.3.2.2 L’expressivité et la richesse sémantique
5.3.2.3 Capacités de raisonnement et d’inférence
5.4 Modèles ontologiques proposés
5.5 La spécification ODM
5.6 Modélisation de contexte basée sur les ontologies
5.6.1 Applications mobiles sensibles au contexte
5.6.2 Etude de cas: Le service SAMU
5.6.3 Modèle de contexte avec la notation ODM
5.6.3.1 Les règles SWRL pour la déduction du contexte de haut niveau
5.6.3.2 Un modèle de contexte satisfait les exigences tracées
5.7 Conclusion
6 MDD et AOM pour le Développement des applications Sensibles au Contexte 69
6.1 Introduction
6.2 Mécanismes de sensibilité au contexte
6.3 Architecture conforme à MDA pour développer des applications sensibles au contexte
6.3.1 L’architecture de l’approche proposée
6.4 Le Metamodèle ContextAspect
6.4.1 Les éléments du modèle Aspect
6.4.2 Les éléments du modèle Contexte
6.4.3 Les éléments du modèle Sensibilité au Contexte
6.5 Processus de développement
6.5.1 Phase de modélisation
6.5.2 Phase de composition
6.5.3 Phase de transformation
6.5.4 Phase d’adaptation
6.6 Conclusion
7 Scénario d’Adaptation Dynamique
7.1 Introduction
7.2 Processus d’Adaptation Dynamique
7.2.1 Étape de surveillance du changement de contexte
7.2.2 Étape d’analyse
7.2.3 Étape de planification
7.2.4 Étape d’exécution
7.3 Conclusion
8 Comparaison, Avantages et Limites
8.1 Introduction
8.2 Comparaison avec les travaux connexes
8.2.1 Travaux combinant MDD avec AOM
8.2.2 Travaux combinant MDD avec AOP
8.2.3 Travaux basés sur MDD
8.3 Avantages et résultats
8.4 Limites de l’approche proposée
8.5 Tableau comparatif
8.6 Conclusion
9 Conclusion Générale 104
9.1 Synthèse des contributions5
9.1.1 Modélisation du Contexte avec les Ontologies
9.1.2 Architecture logicielle conforme à MDA et le métamodèle ContextAspect
9.1.3 Méthodologie Générique de Conception et Développement
9.1.4 Adaptation Dynamique au contexte
9.2 Perspectives envisagées

Télécharger le rapport complet