Acquisition du contexte : modèle de contexte pertinent pour l’adaptation structu relle

Afin de concevoir des composants capables d’adapter automatiquement leur structure, nous devons répertorier les éléments du contexte ayant un impact direct ou indirect sur la structure d’un composant logiciel. Nous avons alors isolé trois types de contexte (ContextPart) répondant à ce critère : le contexte de déploiement (DéploiementCxt) qui fait référence aux propriétés de l’architecture matérielle dispo- nible, le contexte d’exploitation (ExploitationCxt) qui fournit des informations sur les caractéristiques de l’utilisateur et de l’environnement d’utilisation et enfin, le contexte applicatif (ApplicationCxt) qui décrit les propriétés de l’architecture logicielle. La figure 4.4 présente le méta-modèle que nous avons retenu. Chaque partie contient un certain nombre d’éléments de contexte (ContextElement) organisés hié- rarchiquement. Un ContextElement représente une information élémentaire du contexte ou un ensemble d’informations hiérarchiques (ContextCategory). La prise en compte de ces différents contextes va per- mettre au composant de déclencher des phases d’adaptation et de déterminer une nouvelle structure, adaptée à la nouvelle situation.

Figure 4.4 – Méta-modèle du contexte

Comme nous l’avons évoqué précédemment, nous avons isolé trois types de contexte ayant un impact direct ou indirect sur la structure des composants. Ces trois types de contexte sont les suivants :

• le contexte de déploiement (DéploiementCxt)

Description : le contexte de déploiement fait référence aux caractéristiques techniques (propriétés

des composants matériels et des connecteurs matériels) de l’infrastructure disponible (i.e. archi- tecture matérielle) et à sa configuration.

Nous pouvons distinguer deux types de caractéristiques techniques relatives à l’architecture ma- térielle : d’une part, les caractéristiques fixes et d’autre part les caractéristiques évolutives. Les caractéristiques fixes correspondent aux données qui ne vont pas évoluer au cours de l’exécution de l’application. Il s’agit par exemple de la vitesse du processeur, du système d’exploitation, de la mémoire maximale disponible, etc. Leur prise en compte par le composant est généralement réalisée au moment de son déploiement.

Contrairement aux caractéristiques fixes, les caractéristiques évolutives varient tout au long du cycle de vie de l’application. Nous pouvons citer à titre d’exemple : le taux d’utilisation du pro- cesseur, le niveau de batterie restant, la bande passante du réseau, etc. Afin de garantir un bon fonctionnement du composant, les données de ce type doivent être contrôlées tout au long du cycle de vie du composant. Cette opération est réalisée par l’intermédiaire des sondes qui sont généralement constituées de capteurs logiciels ou matériels.

Raisons de la prise en compte : tout d’abord, la structure d’un composant doit être la plus adaptée

à son infrastructure de déploiement. Par exemple, un composant monolithique risque de ne pas pouvoir être déployé sur une machine alors qu’un composant composite peut être réparti sur l’in- frastructure distribuée disponible. En fait, un composant monolithique peut être déployé sur une machine seulement si les ressources matérielles disponibles le permettent. De plus, étant données que les ressources matérielles disponibles sur une machine de déploiement sont en perpétuelle évolution, il se peut qu’au cours de son exécution, la continuité de service du composant ne soit plus garantie (car les ressources matérielles nécessaires sont devenues insuffisantes). Dans ce cas, tous les services qu’il fournit deviennent indisponibles. Le composant peut alors, grâce à l’adap- tation structurelle, modifier sa structure et distribuer les services qu’il fournit sur l’infrastructure disponible (dans le cas où le transfert du composant dans son intégralité, sur un site de déploiement distant, ne peut être envisagé pour diverses raisons telles que les déconnexions trop fréquentes de la machine de l’utilisateur).

Prise en compte : le contexte de déploiement et plus particulièrement les caractéristiques évo-

lutives, est utilisé par le composant pour déclencher des phases d’adaptation. Par exemple, si le niveau de batterie ou bien la mémoire disponible dépasse un certain seuil (défini par le concepteur dans le cadre du contexte applicatif), une phase d’adaptation doit alors être déclenchée afin de garantir une continuité de service.

Le contexte de déploiement est également utilisé pour déterminer sur quels sites peuvent être dé- ployés les services des composants en fonction des ressources matérielles qu’ils requièrent pour garantir une continuité de service ou maintenir la qualité de service ;

• Le contexte d’exploitation (ExploitationCxt)

Description : le contexte d’exploitation contient deux types de données contextuelles : d’une

part, des informations sur le profil de l’utilisateur (caractéristiques et préférences utilisateur) ; le profil de l’utilisateur comprend des données personnelles (âge, etc.) et des données relatives à son activité (profession, etc.). Il est généralement fourni par l’utilisateur lui-même.

D’autre part, des informations sur les conditions d’utilisation des services du composant ; les in- formations sur les conditions d’utilisation permettent à l’application d’évaluer la situation dans laquelle se trouve l’utilisateur au moment de son interaction. Par exemple, l’environnement d’exé- cution est bruyant, sombre, etc.

Raisons de la prise en compte : la structure d’un composant peut également dépendre de son

contexte d’exploitation. En effet, il apparaît plus judicieux, dans certains cas, de déployer un maximum de services susceptibles d’être les plus utilisés (en fonction des ressources matérielles disponibles), sur la machine de l’utilisateur du fait des risques de déconnexion à l’infrastructure distribuée. De ce fait, l’utilisateur pourra accéder aux services qu’il a le plus besoin malgré d’éven- tuelles déconnexions. Pour cela, le choix des services à déployer sur la machine de l’utilisateur est déterminant. Il doit donc tenir compte de l’utilisateur et de la situation dans laquelle il se trouve lors de l’interaction avec l’application.

Prise en compte : Le contexte d’exploitation est utilisé pour établir une classification des services

fournis par le composant en fonction des besoins liés à leur utilisation, de manière à en déployer un maximum sur la machine de l’utilisateur ;

• Le contexte applicatif (ApplicationCxt)

Description : tout d’abord, le contexte applicatif regroupe les propriétés relatives aux besoins

des services telles que la taille mémoire requise pour exécuter un service, la fréquence du proces- seur requise, le système requis, etc. Ces données sont fournies par le concepteur de chaque service d’un composant.

Les données relatives au comportement des composants contiennent des informations relatives aux appels de services (nombre de fois où un service est invoqué, probabilité d’invocation d’un service dans un contexte donné, etc.) ainsi qu’aux déclenchements de phases d’adaptation. Leur acquisi- tion nécessite la mise en place d’un historique permettant de garder une trace du comportement du composant ainsi que des outils d’introspection sur le composant. L’historique de l’application permet de mémoriser les évènements qui se sont produits dans le passé (appels de services, déclen- chement de phases d’adaptation, etc.), ainsi que leurs conséquences sur les ressources matérielles évolutives.

Raisons de la prise en compte : l’adaptation de la structure d’un composant dépend également des

besoins liés à l’utilisation de ses services ainsi que leur comportement.

Comme nous l’avons évoqué précédemment, la structure d’un composant doit être mise en cor- respondance avec l’architecture matérielle disponible. Pour cela, les besoins liés à l’utilisation des services d’un composant doivent être exprimés par son concepteur. Ces informations contextuelles font parties du contexte applicatif car elles sont spécifiques aux composants logiciels concernés. L’adaptation de la structure d’un composant dépend également de son comportement. Par exemple, dans le cas où deux services sont fortement liés (appel d’un service lorsque l’autre est appelé), il est préférable de regrouper ces deux services dans un même composant déployé sur une même machine de manière à éviter les surcoûts liés à d’éventuelles communications distantes, et ainsi, assurer une certaine complétude des services déployés sur une même machine (i.e. les services les plus dépendants étant regroupés sur une même machine).

Prise en compte : la prise en compte du contexte applicatif a pour objectif d’une part, de réaliser

l’adéquation entre l’architecture logicielle et l’architecture matérielle en tenant compte des besoins en ressources de chaque service et d’autre part, d’optimiser le choix des composants et de leurs sites de déploiement en évaluant les dépendances entre les services et en proposant une répartition visant à minimiser les connexions distantes entre les services, ainsi que de tirer partie des évè- nements du passé afin d’anticiper le futur. Par exemple, si l’application constate que l’exécution d’un service a engendré une forte consommation d’énergie, ce service pourra être redéployé sur des unités disposant de batteries à forte autonomie.

4.3.2 Prise de décisions : stratégie de génération automatique de la spécification d’une