Variabilité et adaptation par rapport aux spécificités des environnements ubiquitaires

Pour permettre la prise en compte des contraintes liées à ces environnements ubiquitaires, il est indispensable de proposer de nouvelles méthodes de conception d’applications ainsi que de nouvelles infrastructures logicielles.

Tout d’abord, la création d’application dites « ubiquitaires » amène à repenser les infrastructures logicielles pour les rendre adaptables dynamiquement, configurables et auto-administrables en fonction de l’environnement dans lequel elles se trouvent. Ces infrastructures prendront en compte la répartition, l’hétérogénéité, la mobilité mais également les ressources limitées des supports matériels. Elles doivent

alors offrir des garanties de sûreté de fonctionnement et de qualité de service dans leur comportement et dans les services offerts.

La conception d’applications fonctionnant dans ce type d’environnement pose également de nou- veaux problèmes en plus de ceux dus à la réalisation d’applications réparties. Ces problèmes tels que la mobilité des utilisateurs, l’hétérogénéité des terminaux et des systèmes doivent généralement être pris en compte au moment de la conception de ce type d’applications. En fait, toute application destinée à être exécutée dans un environnement ubiquitaire doit présenter un ensemble de caractéristiques ou propriétés spécifiques. Ces caractéristiques peuvent être catégorisées en deux parties (voir Tableaux 1.9 et 1.10) : d’une part les caractéristiques fonctionnelles ; et d’autre part les caractéristiques non-fonctionnelles de l’application. Ces caractéristiques peuvent concerner le comportement ou la structure de l’application ou des entités logicielles qui la composent.

Caractéristiques fonctionnelles d’une application ubiquitaire Tout d’abord, une application ubi- quitaire doit présenter un ensemble de caractéristiques fonctionnelles spécifiques afin de pouvoir être exécutée dans ce type d’environnement. Ces propriétés sont les suivantes :

• la transparence des interfaces

Une des caractéristiques d’une application ubiquitaire réside dans sa capacité à masquer ses mé- canismes fonctionnels. Cette capacité offre à l’utilisateur des modes d’interaction plus naturels avec son milieu. A terme, ces interactions devraient avoir lieu sans que l’utilisateur ait conscience d’utiliser les services fournis par des machines distribuées.

Cette caractéristique doit être prise en compte au moment de la conception de l’application (et plus particulièrement de ses interfaces de communication avec l’utilisateur). Elle requiert la mise en place d’outils permettant d’acquérir le contexte d’exécution de l’application. Les informations ainsi récoltées doivent être utilisées afin d’anticiper les besoins de l’utilisateur et de guider les interactions entre les deux parties ;

• l’adaptation aux moyens d’exécution

Les caractéristiques des machines sur lesquelles l’application est exécutée peuvent être très dif- férentes (ordinateur de bureau, PDA, téléphone, etc.). L’application doit prendre en compte les moyens qui sont mis à sa disposition (réseaux disponibles, périphériques disponibles, etc.). L’ap- plication doit être capable de prendre en compte ces informations afin d’assurer un interfaçage de l’application qui soit la mieux adaptée à la situation. En effet, une interface Homme-Machine doit impérativement être exécutée sur la machine de déploiement de l’application.

Leur prise en compte des possibilités de l’application à s’adapter à ce type de ressource doit être réalisée au moment de la conception de l’application. Des stratégies doivent être étudiées en fonc- tion des ressources disponibles. Par exemple, si la machine d’installation ne dispose pas de sorties audio, l’application doit opter pour d’autres types de communication (par exemple, utilisation de l’écran de la machine ou d’un vibreur) ;

• l’adaptation à la variation de l’environnement proche du terminal

Dans un environnement ubiquitaire et mobile, les conditions d’exécution d’une application varient en permanence. L’utilisateur et même parfois le terminal peuvent être en mouvement. L’appli- cation doit pouvoir être capable d’utiliser tous les moyens de communication avec l’utilisateur de manière adaptée à l’environnement. Par exemple, lorsque l’environnement d’exécution est très bruyant comme dans des lieux publics (gare, aéroports, etc.), l’application doit privilégier l’affi-

chage sur un écran plutôt que le son. Alors que lorsque l’utilisateur est en mouvement (marche, course, etc.), il est préférable qu’il utilise la voix pour communiquer ;

• la mobilité

L’utilisateur doit pouvoir accéder à des données personnelles à partir de n’importe quelle station de travail. La sécurité est donc un critère essentiel que doit préserver l’adaptation. Un système d’identification de l’utilisateur doit donc être mis en œuvre.

L’ensemble des propriétés qui ont été énoncées ci-dessus sont des propriétés fonctionnelles. De plus, elles sont spécifiques à l’application en question et concernent plus particulièrement son comportement. De ce fait, leur introduction dans une application existante ne peut pas être réalisée de manière auto- matique. En fait, c’est au concepteur de l’application et des entités logicielles qui la composent de les introduire. L’intégration de ces propriétés n’entre donc pas dans les objectifs de cette thèse.

Caractéristiques non-fonctionnelles d’une application ubiquitaire Pour être exécutée dans un en- vironnement ubiquitaire, une application logicielle doit également présenter un ensemble de propriétés non-fonctionnelles spécifiques. Ces propriétés liées à l’ubiquité sont les suivantes :

• la distribution

Les services de l’application doivent être accessibles à partir de n’importe quel nœud de l’infra- structure disponible. Une application ubiquitaire doit donc intégrer des mécanismes de distribu- tion. Or, l’intégration de tels mécanismes peut se révéler problématique dans de nombreux cas. Par exemple, un composant monolithique ne peut être distribué de manière ad-hoc. Pour répondre à cette caractéristique, il est donc indispensable de pouvoir modifier la structure du composant afin de lui introduire des mécanismes de distribution ;

• l’adaptation aux moyens d’exécution

L’hétérogénéité des moyens d’exécution fait à la fois partie des caractéristiques non fonction- nelles liées aux applications ubiquitaires. En effet, les machines de déploiement d’une applica- tion peuvent disposer de capacités (batterie, taille de l’écran, puissance du processeur, capacité de stockage, etc.) très variables ; allant du simple téléphone portable doté de capacités minimales au cluster de milliers d’ordinateurs multi-processeurs. L’application doit donc tenir compte de la capacité de calcul de chaque unité afin de fonctionner correctement et ce dans les meilleures conditions d’utilisation et de performance.

Contrairement aux interfaces Homme-Machine qui doivent impérativement être exécutées sur la machine de déploiement de l’application, les services dédiés aux calculs peuvent être distribués sur l’infrastructure disponible si besoin est. Ce besoin peut se traduire par l’impossibilité de déployer l’application dans son intégralité sur la machine concernée.

Les ressources liées à la capacité de calcul des machines doivent être prises en compte au moment du déploiement de l’application. Par exemple, lorsque la taille mémoire disponible sur la machine de déploiement est insuffisante, l’application peut se partitionner automatiquement et se déployer sur plusieurs nœuds de l’infrastructure distribuée en fonction de la mémoire disponible sur chaque nœud. De la même manière, si la vitesse du processeur est insuffisante pour effectuer certains calculs, les services nécessitant des ressources CPU plus importantes que celles fournies par la machine de déploiement peuvent être déployés sur d’autres nœuds de l’infrastructure distribuée. Certaines ressources sont fortement liées. Par exemple, pour palier au problème de consommation

d’énergie (si l’application doit être déployée sur une machine à faible autonomie), il peut se révéler indispensable d’isoler les services consommant le plus d’énergies (forte utilisation du CPU, accès disques nombreux, utilisation de périphériques spécifiques, etc.) afin de les répartir sur d’autres nœuds de l’infrastructure et ainsi diminuer la consommation d’énergie.

L’adaptation de la structure des composants, au moment du déploiement, est donc là aussi, néces- saire à l’introduction de cette propriété ;

• l’adaptation aux variations des performances des machines de déploiement

Les performances des machines de déploiement varient tout au long du cycle de vie de l’applica- tion. Ces variations peuvent être dues directement à l’exécution de l’application (un service qui crée des données donc diminution de la capacité de stockage de la machine) ou bien à d’autres applications exécutées sur cette même machine. Une solution à ce problème consiste à sonder en permanence les ressources (taux d’utilisation du processeur, stockage disponible, batterie restante) évoluant au cours du temps et à déclencher des phases d’adaptation de l’application si nécessaire. Par exemple, si la capacité de stockage disponible devient critique (en dessous d’un seuil préa- lablement défini par l’administrateur de l’application), une solution peut consister à réorganiser la structure de l’application de manière à isoler les services les plus consommateurs de cette res- source et à les redéployer sur d’autres nœuds de l’infrastructure disponible.

Dans ce cas, les composants doivent être capables d’adapter leur structure à leur environnement de déploiement pendant leur exécution ;

• l’adaptation à l’hétérogénéité des moyens de communication

La diversité des réseaux pouvant être accessible par une machine est également importante (ré- seaux physiques, Wifi, Bluetooth, infrarouge, etc.). L’application doit donc tenir compte de toutes ces informations afin de fonctionner correctement et ce dans les meilleures conditions d’utilisation et de performance. Cette caractéristique peut se traduire par la mise en place de mécanismes de distribution configurables qui vont permettre d’adapter la communication entre les différents com- posants de l’application en fonction des types de réseaux disponibles, de leur bande passante et de leur taux d’utilisation. De ce fait, l’adaptation de la structure du composant est nécessaire afin d’assurer la distribution et sa configuration ;

• l’adaptation aux variations des performances du réseau

La bande passante d’un réseau peut varier en fonction du flux de données échangées ainsi que de la puissance du signal s’il s’agit d’un réseau sans fil. Le réseau peut même dans certains cas être inutilisable (trop faible réception du signal, positionnement hors zone de réception, etc.). Ainsi, l’hypothèse de stocker uniquement les composants sur des serveurs dédiés accessibles par l’inter- médiaire d’une infrastructure distribuée ne peut être envisagée. Par exemple, considérons le cas de réseaux sans fil : si l’utilisateur se trouve dans une zone qui n’est pas couverte par le réseau, ou bien s’il se produit une panne matérielle du réseau ou de l’un des serveurs, aucun service ne sera disponible. Cependant, dans le cas où l’application ne peut être déployée dans son intégralité sur la machine concernée (ressources limitées), il est nécessaire de déterminer la meilleure stratégie de distribution possible de manière à prendre en compte les caractéristiques du réseau. Par ailleurs, il est préférable de réduire au minimum le nombre de connexions distantes entre les différents com- posants d’une application afin d’en assurer un fonctionnement optimal. L’adaptation dynamique de la structure des composants est donc nécessaire ;

• l’adaptation à la disponibilité des services

Une application destinée à être exécutée dans un environnement ubiquitaire ou mobile doit être capable de supporter les éventuelles connexions et déconnexions des différentes machines qu’elle utilise. En effet, des services peuvent être inaccessibles (déconnections d’unités de l’infrastruc- ture distribuée, pannes de réseau ou de machines, etc.) pendant des intervalles de temps inconnus. Cependant, ces services peuvent être utilisés par d’autres services de l’application ; ce qui peut engendrer des problèmes. Une application ubiquitaire doit pouvoir continuer à fonctionner malgré la non disponibilité de certains de ses services (i.e. l’indisponibilité d’un service utilisé ne doit pas entraîner le « crash » de l’application). Ainsi, elle doit assurer une continuité de service malgré les déconnexions. Par exemple, si l’utilisateur de l’application sort de la zone de couverture du réseau

Wifi et que celle-ci utilise un service uniquement accessible au travers de ce réseau, l’application

doit réagir en fonction de ces nouvelles conditions d’exécution. Elle peut, par exemple rechercher un service similaire au travers d’autres réseaux ou bien proposer à l’utilisateur un fonctionnement en mode dégradé (i.e. certains services ne seront pas accessibles à l’utilisateur). Ainsi, la struc- ture des composants doit être suffisamment flexible pour supporter la non disponibilité de services qu’ils utilisent ;

• l’adaptation à la disponibilité des ressources

De la même manière que pour les services, les ressources utilisées par une application ne sont pas figées. Une ressource qu’elle soit physique (imprimante, carte graphique, carte réseau, etc.) ou logicielle (variable, base de données, etc.) peut être indisponible pendant une certaine durée. En effet, les ressources évoluent en permanence tout au long du cycle de vie d’une application. Ces évolutions peuvent avoir de graves conséquences sur le fonctionnement de l’application. Par exemple, la déconnexion intempestive de l’un des périphériques de la machine (possibilité d’ajou- ter et de supprimer des périphériques à la volée) ou bien une chute de sa capacité de stockage disponible (lié à l’utilisation d’autres applications en parallèle) peut introduire des disfonctionne- ments dans l’application. Pour palier à ces problèmes et ainsi, assurer une continuité de services, l’application doit être capable de récupérer des informations sur son contexte d’exécution et de réagir si nécessaire à des évolutions ayant un impact notable sur son utilisation. Des stratégies de reprise après panne doivent également être établies. Ainsi, la structure des composants doit être suffisamment flexible pour supporter la non disponibilité de ressources

• la fiabilité de l’acquisition des données sur le contexte due à l’utilisation de capteur

Un des problèmes liés à l’acquisition des données sur le contexte d’exécution de l’application ré- side dans la fiabilité des informations ainsi récoltées. Si certaines données fournies par le capteur paraissent erronées, l’application ne doit pas en tenir compte. Il est donc nécessaire de déterminer pour chaque élément du contexte des plages des valeurs permettant de déterminer si l’application doit réagir ou non à ce nouveau contexte.

Les propriétés citées ci-dessous sont des propriétés transverses aux applications. De ce fait, elles peuvent être introduites à une application existante de manière automatique. Par ailleurs, ces propriétés peuvent concerner le comportement de l’application ou bien sa structure (voir Tableaux 1.9 et 1.10). En fait, comme nous avons pu le constater, un grand nombre de ces propriétés nécessite l’adaptation de la structure de l’application et des entités logicielles qui la composent, pour être mise en œuvre. Cette stratégie passe par la prise en compte du contexte courant pour déterminer une structure pour l’applica- tion et ses constituants adaptée à la situation. De plus, étant donné que dans ce type d’environnement,

les conditions d’exécution d’une application évoluent en permanence, l’adaptation doit être réalisée de manière dynamique et entièrement automatique.

Caractéristiques (Propriété1) (Propriété2) (Propriété3) (Propriété4) (Propriété5)

Type Fonctionnelle X

Non-fonctionnelle X X X X

Cible Comportement X X

Structure X X X

Propriété1: adaptation aux variations des performances du réseau Propriété2: adaptation à la disponibilité des services

Propriété3: adaptation à la disponibilité des ressources Propriété4: transparence des interfaces

Propriété5: prise en compte de la fiabilité de l’acquisition des données sur le contexte

Table 1.9 – Caractéristiques d’une application ubiquitaire (a)

Caractéristiques (Propriété6) (Propriété7) (Propriété8) (Propriété9) (Propriété10) (Propriété11)

Type Fonctionnelle X X X

Non-fonctionnelle X X X X

Cible Comportement X X X

Structure X X X X

Propriété6: adaptation aux moyens d’exécution Propriété7: adaptation à l’environnement proche du terminal

Propriété8: prise en compte de la mobilité Propriété9: adaptation à l’hétérogénéité des moyens de communication

Propriété10: adaptation aux variations des performances des machines de déploiement

Propriété11: distribution

Table 1.10 – Caractéristiques d’une application ubiquitaire (b)

1.5.2 Les applications sensibles au contexte comme solution à l’adaptation dans les envi-