Adaptations dynamiques au contexte en informatique ambiante

Les défis de l’informatique ambiante

Un système ambiant se trouve dans un environnement et repose sur un ensemble d’entités qui peuvent interagir les unes avec les autres. Une entité peut être un « êtres vivant » comme un utilisateur par exemple, ou un système informatisé. Ces systèmes reposent sur des objets informatisés hétérogènes qui ont une existence physique, par exemple un PDA ou encore un réfrigérateur intelligent. Nous appellerons ces derniers des dispositifs. Ils sont fournis par des constructeurs et, pour la plus grande majorité d’entre eux, ne sont pas prévus pour être modifiables ni physiquement, ni logiciellement. A partir de l’ensemble des dispositifs accessibles il est possible pour une entité de créer de nouvelles applications en faisant interagir les dispositifs les uns avec les autres. Nous appellerons cet ensemble des dispositifs et entités logicielles auxquels un système peut accéder son infrastructure. Ces dispositifs peuvent être mobiles , ils peuvent entrer ou quitter à tout instant cette infrastructure. Lorsque c’est le cas, les applications doivent alors s’adapter à ces variations. Cette infrastructure impose alors les contraintes suivantes aux systèmes ambiants : Hétérogénéité : l’ensemble des dispositifs qui compose l’infrastructure d’un système ambiant peut être hétérogène aussi bien en terme de matériel que de communications. Il faut être capable de les faire interagir les uns avec les autres.
Multiplicité des entités se trouvant dans l’environnement : Un grand nombre et de nombreuses variantes d’entités et de phénomènes peuvent se trouver dans l’environnement d’un système ambiant et doivent être considérés. Le système ambiant peut alors lui-même prendre de nombreuses formes.
Briques logicielles de base non-éditables : les dispositifs fabriqués et commercialisés par des constructeurs ne sont généralement pas prévus pour être modifiés physiquement ni logiciellement. La création de nouvelles fonctionnalités dans un système ambiant ne peut donc pas passer par la modification de ces dispositifs.
Mobilité : avec l’apparition des dispositifs et logiciels mobiles, les déconnexions ne sont plus considérées comme des pannes mais comme un mode de fonctionnement normal . En raison de cette mobilité des dispositifs qui composent l’infrastructure d’un système, la topologie de cette dernière est fortement variable.
Ajouté au besoin de s’adapter aux variations de leur infrastructure, les systèmes ambiants, dans l’optique de s’insérer de manière transparente dans leur environnement, doivent également prendre en compte ses évolutions et s’y adapter. L’adaptation se définit dans le dictionnaire comme le fait d’«ajuster une chose à une autre» . Dans le domaine du logiciel, on la définit comme : «le processus de modification du système, nécessaire pour permettre un fonctionnement adéquat dans un contexte donné». On considère qu’une adaptation est nécessaire quand il n’y a plus de correspondance entre l’offre et la demande à une ressource . Dans le cadre de l’informatique ambiante, comme nous l’avons vu précédemment, la forte variabilité de l’environnement et de l’infrastructure d’un système ambiant ont pour conséquence le besoin d’adaptation. Cela peut être pour garantir une bonne continuité de service, ou encore pour faire correspondre au mieux le comportement du système à son environnement.

De l’adaptation statique à l’adaptation dynamique

Une application peut être adaptée lors de diverses phases de son cycle de vie. Cependant, en raison de la forte variabilité du contexte et afin de conserver la pertinence temporelle des adaptations, il est important de réaliser ces adaptations de manière à interrompre le moins possible l’exécution de l’application.
Une adaptation est qualifiée de statique lorsqu’elle intervient avant l’exécution , c’est-à-dire avant que l’application ne soit déployée . Ce type d’adaptation nécessite, par conséquent, l’arrêt de l’application et son redéploiement . Si l’adaptation statique ne nécessite pas de s’appliquer sur une application qui a été prévue pour , elle requiert que les contraintes nécessitant l’adaptation varient peu, de telle manière que lorsque l’adaptation est déployée, elle peut rester stable suffisamment longtemps . Des mécanismes génériques pour réaliser de telles adaptations existent, comme par exemple, AspectJ. A l’origine, avec AspectJ, l’adaptation intervient lors de la phase de compilation. Le code décrit dans des entités abstraites est injecté dans le code de l’application pour générer un nouveau fichier source. Nous avons vu dans l’introduction que les systèmes ambiants doivent respecter plusieurs dynamiques d’évolution. La fréquence de ces évolutions pouvant être élevée, il n’est pas envisageable d’arrêter, puis d’adapter pour enfin redéployer l’application à chaque fois que la situation exige une adaptation . Nous souhaitons, au contraire, garder l’application utilisable le plus longtemps possible.
L’adaptation dite dynamique permet de modifier, totalement ou partiellement, le comportement d’un logiciel (OS, intergiciel, application …) tandis que celui-ci continue à s’exécuter .
Contrairement à l’adaptation statique, il faut alors que l’application soit prévue pour cela, c’est-à-dire à minima construite sur une plateforme permettant son adaptation. Une solution pour répondre à cette problématique est de combiner approches statiques et dynamiques. Par exemple, Yang et al proposent de permettre à des applications qui n’ont pas été conçues pour cela de s’adapter dynamiquement. Un processus en deux phases est alors réalisé. Cette approche consiste, dans un premier temps, à adapter statiquement l’application pour y ajouter des mécanismes qui permettront lors d’une seconde phase son adaptation dynamique par insertion ou suppression de code. Ce type d’approche est difficilement envisageable dans le cadre de l’informatique ambiante. En effet, en raison de l’imprévisibilité des évolutions du contexte d’une application ubiquitaire, il est impossible de prédire, à la conception, l’ensemble des adaptations qui pourront être réalisées sur une application.
Dans les approches couplant adaptation statique et dynamique, cela aurait pour effet d’entraîner régulièrement la mise en œuvre de l’adaptation statique pour mettre à jour les capacités d’adaptation dynamique.

Adaptations compositionnelles et paramétrées : des approches qui peuvent être combinées

Deux approches principales permettent de réaliser des adaptations dynamiques  : l’adaptation paramétrée et l’adaptation compositionnelle. La première modifie le comportement de l’application en faisant varier des paramètres existants, tandis que la seconde permet de reconfigurer une application en ajoutant, retirant, échangeant les modules qui la composent. Ces approches, loin d’être incompatibles, offrent des capacités qu’il peut être intéressant de combiner. Nous allons maintenant étudier ces deux approches plus en détail et plus particulièrement en terme de temps de réponse et de capacité à étendre les fonctionnalités du système.

L’adaptation paramétrée

L’adaptation paramétrée a pour objectif de modifier des variables afin de changer le «comportement» d’une application. Les paramètres peuvent être modifiés à l’exécution et entraîner la mise place d’une nouvelle stratégie, qui avait été prédéfinie, dans l’application. Cette approche est simple d’utilisation et offre des temps de réponse faibles. Cependant, l’ensemble des adaptations réalisables est borné et doit être défini à la conception. Les systèmes réalisant de telles adaptations sont parfois appelés « closed-adaptive », puisqu’ils choisissent les adaptations parmi celles disponibles sans qu’il soit possible d’en ajouter à l’exécution. Cette approche est donc bien adaptée aux applications se trouvant dans des environnements bornés, pour des buts bien précis et maîtrisés, pour lesquels un concepteur peut anticiper et spécifier l’ensemble des adaptations.

L’adaptation compositionnelle

L’adaptation compositionnelle vise à échanger des algorithmes ou stratégies d’une application par d’autres qui correspondent mieux aux besoins du système. Une adaptation peut être conçue et intégrée plus tard, pendant l’exécution, par late-binding. Comme nous pouvons le voir dans la littérature, l’adaptation compositionnelle est donc particulièrement adaptée au cadre de l’IAm et à la gestion des variations de l’infrastructure logicielle d’une application. L’adaptation compositionnelle offre ainsi la possibilité d’intégrer dans l’application de nouveaux algorithmes qui n’avaient pas été prévus à la conception . Les systèmes réalisant de telles adaptations sont parfois appelés « open-adaptive » . En Informatique ambiante, puisque nous possédons un ensemble de briques logicielles fournies par des dispositifs qu’il n’est pas nécessairement possible de modifier, nous souhaiterons les faire interagir entre elles dans l’optique de créer de nouvelles fonctionnalités . Pour ce faire, l’adaptation doit être capable de prendre en compte les apparitions ou disparitions de ces dispositifs. Alors, comme cela est écrit dans : «The ability to seamless compose services from various devices in a more or less ad-hoc manner is a frequently emphasized feature of ubiquitous computing» . Dans ce cadre, l’adaptation compositionnelle permet, par exemple, de prendre en compte dynamiquement les parties logicielles exposées par des dispositifs qui viennent d’apparaître et inversement lors de leur disparition. Par contre, les temps de réponses engendrés sont plus importants que ceux de l’adaptation paramétrée, les mécanismes mis en œuvre étant plus complexes. Quoiqu’il en soit, ces deux types d’adaptations ne sont pas incompatibles.

Adaptation et projection sur des représentations abstraites

Une adaptation peut se composer d’un ensemble d’instructions atomiques de modifications d’une application (par exemple l’instruction « ajouter un composant »). Traditionnellement, chaque modification, lorsqu’elle est mise en œuvre, est directement portée dans l’application de manière implicite.
L’application est alors interrompue lors de la réalisation successive de chaque modification. Nous verrons, dans la première partie de cette section que cette approche est adoptée par la plupart des plateformes d’exécution adaptatives à base de composants. Après avoir discuté des limitations que cela impose en terme d’interruptions de l’application, nous verrons dans la suite de cette section comment les approches utilisant des modèles de l’application à l’exécution permettent de répondre à ces problématiques.

Quelques plateformes adaptatives à base de composants

De nombreuses plateformes d’exécution adaptatives à base de composants existent et permettent de réaliser des adaptations compositionnelles. B. Morin dans sa thèse, montre que la plupart de ces plateformes d’exécution fournissent des API pour l’introspection et la reconfiguration. Ces deux techniques sont les principes de base de la réflexivité. La réflexivité est la capacité d’un système à observer et altérer son comportement . Elle ne s’applique pas uniquement à la programmation orientée objet mais, avec le développement des machines virtuelles, son utilisation s’est désormais largement répandue. Elle repose sur deux mécanismes : l’intercession, qui est la capacité d’un système à modifier son comportement et l’introspection qui est la capacité d’un système à s’observer. Pour ce faire, la réflexion repose sur deux niveaux. L’introspection consiste en particulier en la réification des entités logicielles composant l’application à un niveau méta. L’intercession, quant à elle, est le mécanisme qui permet de modifier ces entités réifiées. Le niveau méta, qui englobe les réifications et le code pour modifier ces entités est en connexion causale avec le niveau de base (l’application s’exécutant). Les modifications au niveau méta sont directement reportées au niveau de base de manière implicite, c’est le mécanisme d’absorption. Le niveau méta peut être vu comme un modèle de l’application s’exécutant . De la même manière, dans les plateformes d’exécution que nous allons présenter, les modifications sont directement reportées au niveau de base. Hormis le modèle à composant Fractal, les modèles OSGi, SLCA et SCA mélangent des concepts tirés à la fois des approches orientées composants et services. A chaque modèle nous associerons une implémentation de référence qui offre des mécanismes d’adaptations compositionnelle.

Appliquer les adaptations sur des représentations abstraites des plateformes d’exécution

Trouvant leurs origines dans le domaine des bases de données, les transactions sont un moyen de réaliser une «unité atomique d’accès à une ressource» donc de porter un ensemble de modifications de manière atomique . Les étapes dans le cycle de vie d’une transaction sont : début,  définition de l’ensemble des opérations validation ou abandon puis fin. Aucune modification n’est définitivement portée avant validation. Appliquées à l’adaptation, elles permettraient de réaliser un ensemble d’actions de modifications afin de les appliquer de manière atomique sur le système. Par exemple, le langage FScript permet de garantir les propriétés ACID (atomique, cohérente, isolée et durable) des transactions sur les adaptations.
Cependant, cette approche ne permet pas, avant validation, de vérifier les conséquences de l’ensemble des adaptations. Pour cela, il faut une image de l’application sur laquelle il est possible de réaliser des traitements, sans que cela porte à conséquence. Les travaux dans le domaine des models@runtime, en proposant de manipuler des représentations abstraites d’une application à l’exécution, offrent un telle possibilité. Si les recherches en ingénierie des modèles portaient au départ sur les phases du cycle de vie d’une application se déroulant avant l’exécution, elles ont évoluées vers l’utilisation de modèles à l’exécution. Couplés à des plateformes d’exécution adaptatives, les models@runtime peuvent offrir des capacités d’adaptation compositionnelle dynamique tout en limitant les répercussions apportées aux applications.

Séparation des préoccupations : découpler les propriétés fonctionnelles des propriétés transverses

La variabilité ainsi que l’envergure des phénomènes auxquels peuvent être sensibles les systèmes ambiants mènent souvent à la mise en place de systèmes complexes proposant de nombreuses fonctionnalités. Il devient alors vite difficile de maîtriser ou de maintenir ces systèmes. En effet, bien souvent, différentes fonctionnalités se trouvent offertes par un même morceau de code. C’est le cas dans les approches consistant à décrire l’ensemble des configurations atteignables ; un même code se trouve souvent disséminé dans plusieurs configurations. Il en va de même lorsque nous écrivons de manière ad-hoc toutes les adaptations. Modifier ce code disséminé implique alors de modifier indépendamment chaque configuration, adaptation.
Nous retrouvons, par exemple, ce type d’approche dans Genie , une plateforme pour laquelle nous avons vu qu’il est nécessaire de définir l’ensemble des variantes de configurations du système et les transitions entre elles. C’est également le cas de l’intergiciel CARISMA (Context-Aware Reflective mIddleware System for Mobile Applications). Il s’agit d’un intergiciel réflexif qui peut être personnalisé en fonction des besoins des applications. A chaque application peut être associé un profil. Ces profils définissent les associations entre fonctionnalités fournies, politique de mise en œuvre de cette fonctionnalité et le contexte permettant l’identification d’une fonctionnalité. Ces profils peuvent être modifiés pendant l’exécution de l’application grâce à la notion de réification des profils. Dans cette approche, un seul profil peut être associé à une application et les associations dans divers profils peuvent être dupliquées. Les préoccupations dans un même profil sont entrelacées. L’API permettant la modification d’un profil nécessite l’écriture ad-hoc des modifications de ce dernier.
Ce type d’approche limite la modularité et la réutilisabilité des adaptations ainsi que des diverses fonctionnalités de l’application. L’entrelacement du code des adaptations et des diverses fonctionnalités rend ardue l’identification du code à modifier et ne facilite pas l’intégration de ces modifications.
Le manque de réutilisabilité que cela entraîne, implique bien souvent l’écriture ad-hoc de l’ensemble des configurations du système. Or, nous avons vu que l’environnement est trop variable et imprévisible pour que l’on puisse écrire de manière ad-hoc, pour chaque variation de l’environnement, toutes les configurations d’une application. Il n’est pas non plus possible d’écrire toutes les transitions possibles entre ces configurations ou encore toutes les adaptations. Le principe de la séparation des préoccupations propose de répondre à cette problématique. Il s’agit d’un principe de conception empruntant une stratégie de type : «diviser pour mieux régner» qui permet de décomposer et d’encapsuler les différentes fonctionnalités du système dans des entités modulaires.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

I Introduction et analyse de l’état de l’art 
1 Introduction 
1.1 Introduction
1.2 Les défis de l’informatique ambiante
1.2.1 Trois grands axes de variabilité
1.2.2 Imprévisibilité et combinatoire dans des environnements non bornés
1.2.3 Dynamicité et multi-dynamicité
1.2.4 Des temps de réponse adaptés et maîtrisés
1.3 Synthèse et objectif
2 Analyse de l’état de l’art 
2.1 De l’adaptation statique à l’adaptation dynamique
2.2 Adaptations compositionnelles et paramétrées
2.2.1 L’adaptation paramétrée
2.2.2 L’adaptation compositionnelle
2.3 Adaptation et projection sur des représentations abstraites
2.3.1 Quelques plateformes adaptatives à base de composants
2.3.2 Appliquer les adaptations sur des représentations abstraites des plateformes d’exécution
2.4 Séparation des préoccupations
2.4.1 La notion de séparation des préoccupations
2.4.2 La Programmation Orientée Aspects (AOP)
2.4.3 La Programmation Orientée Feature (FOP)
2.4.4 L’adaptation comme une préoccupation transverse
2.5 Gérer la variabilité dans des environnements imprévisibles
2.5.1 Approches explicites : spécifier toutes les configurations et adaptations faisant passer d’une configuration à une autre
2.5.2 Augmenter l’abstraction pour limiter le nombre de configurations et de transitions entre ces configurations
2.5.3 Vers de l’émergence contrôlée
2.6 Synthèse et objectifs
II Contribution 
3 Une architecture 4-couches 
3.1 L’architecture classique des intergiciels sensibles au contexte
3.1.1 Décomposition fonctionnelle classique des mécanismes de prise en compte du contexte
3.1.2 Des architectures verticales
3.2 Une architecture tirée de la robotique : l’architecture 3T
3.2.1 A l’origine : une décomposition comportementale
3.2.2 D’une architecture pour la robotique
3.2.3 … à une architecture pour le self-management
3.2.4 Discussion
3.3 Une architecture 4 couches pour l’informatique ambiante
3.3.1 L’architecture 4 couches
3.3.2 Les différentes approches de traitement et exploitation du contexte à répartir dans les 4 niveaux de l’architecture
3.3.3 Organisation des mécanismes d’exploitation du contexte et d’adaptation dans les 4 niveaux
3.4 Synthèse
4 Mécanisme d’adaptation 
4.1 Retour sur les contraintes
4.2 Approche proposée : des cascades d’aspects
4.2.1 Adaptation structurelle et dynamique
4.2.2 Décomposer et réutiliser pour mieux gérer la variabilité
4.2.3 Composition opportuniste, déterministe et symétrique pour autoriser l’impré-visibilité
4.2.4 Temps de réponse maîtrisés et adaptés
4.2.5 Synthèse
4.3 Les Aspects d’Assemblage
4.3.1 Principes et formalisation
4.3.2 Le tisseur d’Aspects d’Assemblage
4.3.3 Présentations détaillées du processus du tissage
4.3.4 Propriétés logiques
4.4 Les Cascades d’Aspects d’Assemblage
4.4.1 Principes
4.4.2 Combinaisons d’AAs et décomposition fonctionnelle
4.4.3 Des models@runtime pour minimiser les modifications dans l’application s’exécutant
4.5 Propriétés temporelles
4.5.1 Approche mono-cycle
4.5.2 Approche multi-cycles
4.5.3 Synthèse
4.5.4 Étude approfondie sur un cycle de tissage
III Validation et application 
5 Mise en œuvre 
5.1 Scénario
5.2 Mise en œuvre de l’architecture
5.2.1 Une infrastructure logicielle à base de services pour dispositifs
5.2.2 Niveau Réflexe interne : Plateforme d’exécution
5.2.3 Niveau Réflexe externe : Designer de Cascades d’AAs
5.2.4 Niveau Tactique : Gestionnaire de contextes
5.2.5 Niveau Stratégique
5.3 Conclusion
IV Conclusions et perspectives 
6 Conclusions et perspectives 
6.1 Synthèse
6.2 Perspectives de recherche
6.2.1 Faire évoluer les points de coupes des AAs
6.2.2 « Model checking » sur les applications en entrée et sortie du tisseur
6.2.3 Un méta-modèle d’assemblage et un langage de greffon applicable au plus grand nombre de plateformes d’exécution
6.2.4 Vers un mécanisme de fusion plus évolué
6.2.5 Et si on arrête plus les cascades ?
6.2.6 Diagramme de feature et cascades d’aspects
6.2.7 Faire cohabiter plusieurs architectures sur quatre niveaux
6.3 Liste des publications
7 Bibliographie détaillée par catégorie 
7.1 Bibliographie programmation orientée Aspect
7.2 Bibliographie programmation orientée feature
7.3 Bibliographie Contexte
7.4 Bibliographie Informatique ambiante, vision et challenges
7.5 Bibliographie Intergiciels
7.6 Bibliographie Robotique
7.7 Bibliographie Modèles
7.8 Bibliographie Autres

Rapport PFE, mémoire et thèse PDFTélécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *