Mise en œuvre de l’exemple avec interaction par appel de méthode avec

Figure 5.22 – Déclaration d’un composant MemoryAccessorqui expose une connexion

ou-vertememorydont lerôleaccessest rempli par un port de typeLocalReceptacle<DataAccess>.

composite CompositeAccessorImpl implements MultiAccessor {

MemoryAccessor c1;

MemoryAccessor c2;

merge(this.memory, c1.memory, c2.memory);

}

Figure 5.23 – La mise en œuvre compositeCompositeAccessorImplfusionne les connexions

c1.memoryetc2.memory avec la connexion exposéethis.memory.

5.3.3 Mise en œuvre de l’exemple avec interaction par appel de

mé-thode avec HLCM/CCM

Description Contrairement à l’interaction par partage de mémoire, il n’est pas nécessaire

de décrire de nouveau connecteur pour gérer l’interaction par appel de méthode : il s’agit

d’un des connecteurs nativement supportés par HLCM/CCM. Il est cependant nécessaire de

supporter de nouvelles mises en œuvres de ce connecteur quand l’un des deux ou les deux

rôles _{sont remplis non plus par une unique instance de composant primitif mais par un}

ensemble d’instances qui coopèrent au sein d’une mise en œuvre parallèle de composant.

Pour représenter le fait que plusieurs instances de composant coopèrent pour fournir ou

utiliser le service, deux options sont possibles :

1. laisser lerôle _{correspondant être rempli plusieurs fois, une fois par participant ; ou}

2. regrouper les ports au sein d’unbundle _{et utiliser ce}bundle _{pour remplir le}rôle _une

seule fois.

Cette seconde approche a l’avantage de permettre d’associer une sémantique portée par

lebundle _{au regroupement des ports. Ce choix permet des regroupements à plusieurs}

ni-veaux, comme par exemple en regroupant dans le but d’un équilibrage de charge plusieurs

fournisseurs du service eu mêmes parallèles et donc constitués d’un ensemble d’instances

qui coopèrent.

DeuxbundlesParallelFacetetParallelReceptaclesont donc introduits pour

représen-ter une coopération pour fournir le service ou pour l’utiliser respectivement. Cesbundles

sont paramétrés par une interface objet à la manière de leurs pendants séquentiels et par un

entier qui représente le nombre de participants à l’interaction. L’exemple de la spécification

dubundle ParallelFacetest présenté sur la figure 5.24.

Quatre combinaisons valides existent pour remplir lesrôlesuseretproviderdu

connec-teurUseProvidesuivant que lerôleuserest rempli par un port de typeReceptacleou

Paral-lelReceptacleet que lerôleprovideest rempli par un port de typeFacetouParallelFacet.

Parmi ces combinaisons, une est nativement gérée par HLCM/CCM : le cas où les deux

participants sont séquentiels.

bundletype ParallelFacet<Integer N, interface I> {

each(i:[1..N]){ UseProvide<provider={Facet<I>}> part[i]; }

}

Figure 5.24 – Définition du bundle ParallelFacet qui contient N connexions UseProvide

appeléespartet dont lerôle providerest rempli par un port de type Facet<I>.

5.3. Validation du modèle 75

adaptor Scatter<Integer N> supports

UseProvide<user={ParallelReceptacle<N, MatrixPart>}>

as UseProvide<user={Receptacle<Matrix>}> {

Distributor<N> dist;

each(i:[1..N]){ merge(dist.in[i], supported.user.part[i]); }

merge(this, dist.out);

}

Figure 5.25 – Définition de l’adaptateur de connexionScatterqui supporte une connexion

UseProvide dont lerôle userest rempli par un port de typeParallelReceptacle<N,

Matrix-Part> comme si il s’agissait d’une connexion dans laquelle le rôle user est rempli par un

port de typeReceptacle<Matrix>.

Afin de gérer les trois cas supplémentaires, on pourrait envisager de décrire trois

nou-veaux générateurs. Comme cela a été montré plus tôt, cette approche ne permettrait pas

d’assurer que les composants soient compatibles si de nouvelles variations autour de

l’in-teraction par appel de méthodes étaient introduites. Il ne serait alors pas envisageable de

décrire la version parallèle et la version séquentielle comme deux mises en œuvres d’un

même composant, empêchant ainsi un choix automatique entre ces version.

Il s’agit donc d’une situation qui se prête particulièrement bien à l’utilisation

d’adapta-teurs de connexion. L’adaptateurScatterqui permet d’exposer des connexions dont lerôle

user est rempli par un port de type ParallelReceptacle comme si ce rôle _{était rempli par}

un port de type Receptacle est présenté sur la figure 5.25. Un connecteur Gathernon

re-présenté permet symétriquement d’exposer des connexions dont lerôleproviderest rempli

par un port de typeParallelFacetcomme si cerôle _{était rempli part un port de type}Facet.

L’ajout de ces deux adaptateurs de connexion n’empêche pas de fournir des mises en

œuvres optimisées pour certains cas particuliers. Dans ce cas précis, il semble par exemple

intéressant de proposer un générateur qui gère le cas où à la fois l’utilisateur et le

fournis-seur du service sont parallèle sans introduire de goulot d’étranglement.

5.3.4 Analyse

Ces deux exemples montrent qu’il est possible de décrire les exemples présentés à la

section 5.1.2 en utilisant des mises en œuvres interchangeables à la fois pour les codes

qui constituent l’application et pour leurs interactions. L’approche adoptée dans HLCM se

distingue ainsi de ce qui avait été observé avec l’approche utilisée dans les modèles de

composants existant.

Cette possibilité est due au fait que HLCM assure trois propriétés importantes :

1. une mise en œuvre composite peut exposer un unique point d’interaction qui implique

plusieurs instances de composant internes à la mise en œuvre ;

2. plusieurs mises en œuvres de composant peuvent respecter une même interface tant

que les points d’interactions qu’elles exposent sont compatibles et même si ils ne

pos-sèdent pas exactement le même type ; et

3. ces deux point ne nécessitent pas l’insertion d’artefacts sans sémantique dans

l’as-semblage.

Ces propriétés permettent de découpler la hiérarchie des composants des interactions qui

peuvent alors logiquement traverser les barrières de cette hiérarchie.

L’approche adoptée qui s’appuie sur l’utilisation d’un modèle existant (CCM) comme

mo-dèle sous jacent impose cependant des limitations. Il s’agit en effet d’un momo-dèle qui

pro-pose déjà un niveau d’abstraction relativement élevé qui masque la distribution entre les

composants en imposant l’utilisation d’appels de méthodes Corba entre eux. Certaines

in-teractions nécessitent l’utilisation de mécanismes de plus bas niveau comme le partage de

mémoire qui s’appuie sur des transferts d’adresses mémoire. Cette possibilité n’existe pas

76

Chapitre 5. Introduction du concept de connecteur dans les modèles de composants

hiérarchiques

dans CCM et a donc nécessité l’utilisation d’un contournement qui passe par une

modifi-cation du modèle sous-jacent. Ce point sera discuté plus en détail dans le chapitre 7.

5.4 Conclusion

Ce chapitre a étudié la possibilité d’intégrer le concept de connecteurs de première classe

à un modèle de composants hiérarchique et générique. L’analyse d’exemples synthétiques

d’applications a permis d’identifier un problème inhérente à l’approche naïve classiquement

utilisée en présence de la hiérarchie. Dans certaines situations cette approche impose aux

utilisateurs de faire un choix entre des mise en œuvre efficaces des connecteurs et la

pos-sibilité de remplacer les mises en œuvres de composants.

Une nouvelle approche a été proposée qui s’appuie sur trois nouveaux concepts : les

connexions ouvertes, les adaptateurs de connexions et les bundles_{. Les connexions}

ou-vertes sont utilisées pour décrire l’interface des composants, les adaptateurs de connexions

supportent le polymorphisme et lesbundles _{permettent de construire des abstractions de}

plus haut niveau au dessus de celles existantes. Avec la généricité telle que présentée au

chapitre 4, ces trois concepts forment la base du modèle de composants abstrait HLCM.

Un patron de conception permettant de modéliser ces concepts a été décrit ainsi qu’une

transformation de modèles permettant de supporter leur exécution. Cette approche a été

appliquée à CCM pour donner HLCM/CCM qui a été utilisé pour son évaluation. Pour

cela, les exemples synthétiques d’applications de la section 5.1 ont été décrits à l’aide de

HLCM/CCM.

Il ressort de cette évaluation que l’approche choisie permet de décrire des interactions

entre composants à l’aide de connecteurs. Une spécificité de cette approche est qu’elle

permet aux connexion de relier de manière directe les composants primitifs sans

empê-cher l’existence de plusieurs mises en œuvres interchangeables pour les composants et

les connecteurs. La possibilité de connexion directe semble offrir la possibilité de proposer

des mises en œuvres performantes des connexion, la question des performances exactes

pouvant être obtenues sera étudiée plus en détail dans le chapitre 7. Ces caractéristiques

correspondent aux objectifs qui ont été définis au chapitre 3 pour la conception d’un modèle

de composants extensible par des fonctionnalités dédiées au calcul à haute performance.

Chapitre

6

HLCMi : une plate-forme de mise en

œuvre de HLCM

6.1 Environnement de modélisation . . . 78

6.1.1 Syntaxe abstraite . . . . 78

Dans le document Du support générique d'opérateurs de composition dans les modèles de composants logiciels, application au calcul à haute performance. (Page 88-91)