Gestion du modèle au niveau d’une entité

En examinant notre classification des ressources, il est aisé de constater que celle-ci par-court plusieurs niveaux d’abstractions de conception (du niveau matériel jusqu’au niveau ap-plicatif). De même, en examinant notre classification des abstractions de conception (voir pa-ragraphe 5.3.1), il est aisé de voir que chaque niveau offre ses fonctionnalités aux niveaux supérieurs et nécessite des fonctionnalités des niveaux inférieurs.

Pour bénéficier des avantages de ces deux classifications, nous avons intégré le modèle Offres / Demandes à l’intérieur du modèle d’une entité. Cela nous amène à la définition d’une Ressource / Entité utilisatrice.

Une Ressource / Entité utilisatrice est l’unité logicielle pouvant gérer l’utilisation extérieure de sa propre fonctionnalité. Par définition, une ressource / entité utilisatrice est donc une en-tité (comme préalablement définie dans le chapitre précédent) à laquelle est rajoutée la gestion de ses offres / ses besoins de fonctionnalités.

La figure6.4présente la structure d’une ressource / entité utilisatrice :

Service de détection et de notification Entité fonctionnelle

Ressource / Entité utilisatrice

Entité de gestion de l’utilisation

Niveau fonctionnel Niveau méta

FIG. 6.4 – Structure d’une Ressource / Entité utilisatrice

Au niveau fonctionnel, une ressource / entité utilisatrice comporte l’entité fonctionnelle qui effectue les traitements attendus. Dans le cas d’une ressource matérielle, l’entité fonctionnelle comprend l’ensemble des méthodes d’accès à la ressource physique. Au niveau méta, une entité de gestion de l’utilisation est liée à l’entité fonctionnelle et matérialise la description des offres et des demandes effectuées par l’entité. Les offres et les demandes étant liées à des ressources et entités utilisatrices pouvant fortement évoluer dans l’environnement mobile, l’entité de gestion de l’utilisation interagit avec le service de détection et notification afin de répercuter les va-riations sur les offres et les demandes. Comme pour les entités adaptatives et auto-adaptatives, nous avons choisi de modéliser l’entité de gestion de l’utilisation par une entité pour les mêmes raisons de dynamicité évoquées dans le paragraphe5.2.2.

La figure6.5détaille la structure d’une ressource / entité utilisatrice, notamment la manière dont est implantée la gestion de l’utilisation :

AInteraction OfferDemandManager RegistrationManager UseIndexManager AImplementation OfferLoadIndex DemandLoadIndex OfferRegistration Offer Demand DemandRegistration UseManager Entité fonctionnelle

Entité de gestion de l’utilisation

(iii) utilise

Service de détection et notification (ii) affecte (i) utilise 0..1 * * * * 0..1

FIG. 6.5 – Relations entre éléments de la structure d’une Ressource / Entité utilisatrice L’entité de gestion de l’utilisation est liée à l’entité fonctionnelle par une relation de com-position. Comme pour les entités adaptatives, cela signifie que ces deux instances sont liées par l’exclusivité de leur relation et de leur cycle de vie.

Le cœur de l’entité de gestion de l’utilisation se trouve être le type UseManager, obtenu par héritage du type AImplementation. Il comporte les liens vers les trois parties essentielles suivantes :

(i) Le gestionnaire des offres et des demandes (typeOfferDemandManager): celui-ci est en charge de répertorier les offres (type Offre) et les demandes (type Demand) effectuées sur l’entité courante. En fonction des ressources dont il publie les offres, il utilise le service de détection et notification pour surveiller d’éventuelles variations (point i de la figure6.5).

(ii) Le gestionnaire de réservations (typeRegistrationManager): lorsque la demande d’une entité utilisatrice concorde avec l’offre de la ressource, le gestionnaire de réservations est en charge d’enregistrer une réservation sur la ressource et sur l’entité utilisatrice. Il effectue également la libération de la ressource lorsque l’entité utilisatrice a terminé. Il interagit avec le gestionnaire des offres et demandes de deux manières possibles (point ii de la figure6.5) :

(a) Lorsqu’une réservation ou une libération est effectuée, le gestionnaire de réserva-tions informe le gestionnaire des offres et demandes pour que celui-ci modifie ses offres afin de s’accorder avec ces deux évènements.

(b) Si le gestionnaire des offres et des demandes retire une offre sur une ressource qui avait été réservée, le gestionnaire de réservations doit effectuer une libération et en informer l’entité utilisatrice concernée.

(iii) Le gestionnaire des indices d’utilisation (type UseIndexManager) : celui-ci com-porte deux indices reflétant la charge supportée (type OfferLoadIndex) et in-duite (type DemandLoadIndex) par l’entité courante. Le rôle du premier indice est d’in-diquer, dans le cas où il devient trop élevé, que l’entité doit être déchargée de la trop grande importance des traitements actuels. Le rôle du second indice est d’indiquer, dans le cas où il devient trop élevé, que l’entité utilise trop de ressources et qu’il faudrait peut-être diminuer ses demandes.

Les types de ces indices sont abstraits, laissant ainsi à chaque entité le soin de les spé-cialiser selon l’estimation de charge que chacune désire. Le calcul de ces indices peut prendre en compte différentes caractéristiques internes des offres et demandes (nombre, importance, etc) et des réservation (nombre, etc), mais aussi de différents paramètres extérieurs (comme plusieurs indices qui peuvent être directement mesurés sur les res-sources à l’aide du service de détection et notification) (point iii de la figure6.5). Laisser chaque entité spécialiser ses propres indices posent néanmoins le problème de l’homo-généité des indices. Nous avons opté pour la même échelle de spécification d’indice que l’on peut rencontrer dans les machines Unix : un indice de charge de 0 correspond à au-cun traitement effectué par l’entité, un indice de charge de 1 correspond à une utilisation à plein temps de l’entité, une charge de 2 correspond à un partage équivalent en terme d’offres et de demandes à deux traitements, etc.

Les ressources particulières aux environnements mobiles peuvent être prises en compte par les nouveaux éléments de gestion introduits dans l’entité. Prenons l’exemple d’une entité se trouvant sur un terminal portable et ayant manifestée un intérêt pour les variations que celui-ci pourrait subir (enregistré auprès du service de détection et notification).

Si la probabilité de déconnexion laisse présumer d’une déconnexion prochaine, ou si le niveau de la batterie laisse présumer un arrêt prochain du terminal, le service de détection et notification avertit le gestionnaire des offres et demandes. Si l’entité se trouve être une res-source locale, le gestionnaire des offres et demandes peut décider de retirer ses offres (affectant aussi le gestionnaire des réservations). Si l’entité se trouve être une entité utilisatrice, le ges-tionnaire peut décider de retirer ses demandes, d’arrêter ses réservations locales ou de changer ses réservations locales pour des offres non locales (affectant également le gestionnaire des réservations).

Le service de détection et notification avertit également le gestionnaire d’utilisation qui modifie alors ses indices. Si l’entité se trouve être une ressource locale, l’indice de charge supportée peut être augmenté pour indiquer que la ressource va avoir de plus en plus de mal à réaliser les traitements en cours. Cet indice peut même être positionné à l’infini si la ressource estime ne pouvoir finir aucun traitement avant la déconnexion ou l’arrêt du terminal portable. Si l’entité est une entité utilisatrice, l’inde de charge induite peut lui aussi être augmenté pour indiquer que les traitements demandés sont trop contraignants pour le terminal portable et qu’ils devraient être redirigés vers une autre station. Cet indice peut même être positionné à l’infini si l’entité estime qu’elle ne pourra jamais obtenir le résultat de ses traitements.

Comme le montre l’exemple, la mise en œuvre du modèle Offres / Demandes s’accorde facilement avec les requis de l’environnement mobile. De plus, elle fournit de précieuses in-formations, les indices d’utilisation, pour notre système de distribution qui décidera, dans le paragraphe6.4, du placement et de la migration des entités.