L’architecture 4 couches

L’architecture proposée doit nous permettre de mettre en place l’ensemble des mécanismes de décision que nous avons étudié dans l’état de l’art, ce qui, comme nous venons de le voir, peut impliquer de faire intervenir l’utilisateur. Ainsi, il est possible de faire évoluer le système même s’il se trouve dans une situation qui n’avait pas été prévue et qui n’est pas connue. Dans cette optique, une des évolutions apportées aux architectures précédentes est la mise en place d’un quatrième niveau. Celui-ci est le plus éloigné de l’infrastructure et de la plateforme d’exécution. Il met en jeu des mécanismes complexes qui peuvent autoriser les interactions avec l’utilisateur mais n’offrent aucune garantie quant à l’obtention d’une solution ou encore quant à ces temps de réponse.

L’architecture repose tout d’abord sur une infrastructure logicielle. Cette infrastructure doit permettre la prise en compte des dispositifs hétérogènes et volatiles qui la composent. Il faut donc qu’elle offre la capacité de découvrir dynamiquement de nouveaux dispositifs et doit avertir en cas d’apparition ou de disparition de l’un d’entre eux. Au dessus de cette infrastructure, viennent se construire les applications ubiquitaires comme des compositions d’entités logicielles de l’infrastruc- ture. Ce niveau applicatif est inclus dans notre architecture comme celui se trouvant au plus prêt de l’infrastructure et permettant les interactions entre capteurs et actionneurs (niveau 0) .

L’architecture que nous proposons repose donc sur 4 niveaux (FIGURE 3.10). Les trois pre- miers (en terme de proximité avec l’infrastructure), peuvent être conçus selon une décomposition comportementale. Ils peuvent se composer de plusieurs comportements et la hiérarchie entre ces comportements (de type concurrente) est basée sur leurs temps de réponse comme présenté en FIGURE 3.5. Comme dans les modèles architecturaux sur trois niveaux, le niveau N repose sur les mécanismes offerts par le niveau N-1 et peut agir sur la couche juste en dessous. Il a la possibilité de le contrôler ou de l’adapter afin qu’il vérifie une pertinence logique. Chaque niveau poursuit sa propre dynamique avec ses abstractions, et par conséquent, son niveau de complexité en rapport avec le nombre de couches intermédiaires entre le dit niveau et l’infrastructure. Les temps de réponse sont d’autant plus importants que cette complexité est élevée. Plus le niveau est proche de l’architecture, plus il offre une dynamique au plus proche de celle de l’environnement. L’approche hiérarchique doit permettre au niveau N+1 de garantir la pertinence logique du niveau N ; l’indépendance du niveau N a pour objectif de permettre de garantir sa pertinence temporelle. Enfin, chaque niveau de l’architecture sera alimenté en informations contextuelles. Nous ne proposons dans cette thèse aucune hypothèse ni recommandation sur l’utilisation d’un framework pour la perception du contexte. Dans cette architecture, le déclenchement d’une adaptation peut se faire via chaque niveau. En effet, puisque chacun d’entre eux dispose d’un mécanisme de perception du contexte, ils peuvent tous détecter un changement de situation qui sera à l’origine d’une adaptation. Par contre, dans les niveaux les plus hauts, ce déclenchement de l’adaptation se fera en propageant les modifications dans les niveaux inférieurs.

FIGURE3.10 – Une architecture sur 4 niveaux.

rant de l’application pour la situation courante. Il représente une configuration du système. Il dispose d’une vision à court terme du comportement du système. En effet, une configuration n’est valable que pour une situation donnée et permet de réagir à des changements connus et prévus pour cette situation. Ce niveau est appelé à être modifié lorsqu’il est constaté une erreur, un dysfonctionnement, dans le comportement de routine. Il peut également être sujet à modification lorsqu’un dispositif disparaît ou apparaît dans son infrastructure logicielle. Enfin, il évolue lorsque les comportements déployés ne sont plus consistants avec la situation courante.

Le niveau supérieur permet de réagir aux changements connus mais dont l’occurrence ne peut pas être nécessairement prévue à l’avance. Par exemple, le système peut utiliser un type de dispositif particulier dans une situation mais sa présence, n’est pas certaine. Il s’agit également d’une vision à court terme du comportement du système qui n’est valable que pour une situation donnée. A partir de la définition d’un ensemble de configurations pertinentes pour une situation, il a pour objectif de déployer la plus adaptée. Le niveau 1 est appelé à être modifié, lorsqu’il perturbe la pertinence logique du système, c’est-à-dire lorsque les comportements déployés ne sont pas adaptés à la situation courante.

Le niveau 2, permet de réagir aux changements qui ne sont pas familiers à la situation courante. Il permet de faire passer le système dans une configuration adaptée à une nouvelle situation. Ce niveau à une vision à moyen terme du comportement du système, et reste valide tant que l’on subsiste dans des situations prévues. Pour ce faire, il déploie dans le niveau inférieur l’ensemble des configurations pertinentes dans la nouvelle situation. Il lui est possible d’entraver la pertinence logique du système lorsqu’il active ou déploie dans le niveau inférieur des règles inadaptées.

Enfin, le niveau 3 permet de réagir aux changements considérés comme anormaux, c’est-à-dire menant à une situation qui n’a pas été prévue et qui est non-connue. Pour gérer cela, bien souvent le meilleur moyen est de faire intervenir l’utilisateur. En effet, lui seul connaît le comportement et

l’objectif qu’il souhaite voir le système atteindre. Ce niveau dispose de la vision à plus long terme du comportement du système. Avec l’expérience, il doit être de moins en moins sollicité. Comme le précédent, les risques associés à ce niveau sont de déployer des règles qui ne sont pas adaptées au contexte. Un autre risque à envisager est la possibilité qu’il ne trouve pas de solution.

FIGURE3.11 – Objectifs des différents niveaux.

Il est important de noter que tous les niveaux ne doivent pas être nécessairement présents à l’exception du niveau 0. D’autre part, comme les boucles de contrôle classique de l’autonomic computing, la granularité de cette architecture dépend des entités auxquelles elle est attachée. Il peut s’agir d’un composant composite comme d’un système global. Comme les architectures Obser- ver/Controler, elles peuvent être utilisées dans le système de manière décentralisée, hiérarchique ou centralisée. La FIGURE3.12 présente une utilisation hiérarchique de l’architecture.

FIGURE3.12 – Utilisation de l’architecture de manière hiérarchique.

Tout type de modèle du contexte ou de mécanisme de décision est susceptible d’être utilisé dans cette architecture et doit y trouver sa place. Nous allons maintenant étudier les différentes approches de traitement et d’exploitation du contexte existantes. Nous verrons, ensuite, comment les répartir afin qu’elles autorisent la réalisation par chaque niveau de son objectif mais aussi de manière à ce que les

mécanismes les plus complexes et coûteux en temps se trouvent dans les niveaux les plus complexes qui sont les plus éloignés de l’infrastructure.

3.3.2 Les différentes approches de traitement et exploitation du contexte à répartir