Formes de composition

Il existe de nombreux moyens d’assembler des composants, ou plus précisément leurs interfaces (ou ports). Dans cette section, nous nous intéressons aux formes de composition les plus fréquentes dans les modèles de composants existants ainsi que celles particulièrement utiles aux applications HPC. Cette section traite des mé-thodes de composition de codes indépendamment, sans considérer particulièrement le cas de la composition efficace de codes parallèles, rencontrée dans les codes HPC. Ce problème est analysé dans la section 2.5.

Use-provide

La composition use-provide est l’une des formes de composition les plus récur-rentes dans les modèles de composants. Elle permet aux composants d’exposer des interfaces appelées port provide fournissant des services et des interfaces nommées ports use qui requièrent des services fournis par d’autres composants. Les ports provide exportent des fonctions alors que les ports use importent ces fonctions. Les ports use et provide peuvent être typés. Le type d’un port est généralement une

interface objet contenant un ensemble de méthodes auxquelles les modèles ajoutent parfois des informations supplémentaires telles que l’impact des méthodes sur le comportement du composant ou encore des contraintes d’utilisation des méthodes.

Les ports use et provide peuvent être connectés ensemble par une connexion de type use-provide. Lorsqu’un port use est connecté à un port provide, le port use peut appeler des méthodes du port provide (dans la mesure où la méthode est conforme au type des ports). Certains modèles proposent des connecteurs fournissant une abstraction d’un ensemble de connexions use-provide (voire d’un assemblage partiel) permettant d’exprimer notamment les cas où plusieurs ports use sont connectés à un même port provide. Ce type de connecteur est appelé use-multiple.

Ce type de composition est utilisé dans de très nombreux modèles de composants tels que Fractal [30], CCM [106, 117], GridCCM [96], GCM [13], Koala [93], ou encore parmi les approches dédiées au HPC telles que CCA [4] et L2

C [20]. Flux de données

Les approches à base de flux de données ont été présentées dans la section2.3.3. Dans les modèles de composants utilisant cette approche, des interfaces de sortie produisent un flux de données et des interfaces d’entrée consomment un flux de données. Les ports d’entrée et de sortie peuvent être typés. Le type des ports inclut généralement un type de structure de données (p. ex. primitive ou composée). Il peut aussi inclure des informations supplémentaires relatives au cycle de vie des données, des contraintes sur l’utilisation des données, etc.

Les ports d’entrée peuvent être connectés aux ports de sortie par le biais de connexions d’entrée-sortie transférant ainsi les données d’un port à un autre. Cer-tains modèles proposent des connecteurs plus complexes permettant de filtrer les données, de les répliquer vers plusieurs ports de sortie, de les stocker temporaire-ment ou encore de les redistribuer.

FlowVR [79], FastFlow [2] et Decaf [44] sont des exemples de modèles de com-posants supportant cette approche. On peut noter que dans le cas de FastFlow, l’architecture de l’application n’est pas explicitement séparée des détails d’implé-mentation (c.-à-d. architecture visible dans les sources C++ de l’application). Flux de travaux

Les modèles de composants basés sur les flux de travaux incluent les approches basées sur les flux de données et les étendent afin d’y intégrer des connecteurs des structures de contrôle telles que des conditions ou des boucles. Ces modèles per-mettent généralement aux composants d’exposer des interfaces d’entrée ou de sor-tie. Certains modèles dotent les composants d’interfaces de contrôle permettant de déclencher des traitements sur un autre composant sans transmettre de données.

Les interfaces de contrôle/données peuvent être connectées afin de définir un flot de contrôle entre deux composants (confondu avec le flot de données en cas d’interfaces de données). Ces modèles se distinguent de ceux basés sur les flux de données par la présence des connecteurs permettant de configurer le comportement

2.4. PROGRAMMATION PAR COMPOSITION 41 du flot de contrôle. Par exemple, certains modèles offrent un moyen d’exprimer des commutateurs dont le but est de sélectionner l’activation d’une interface de contrôle parmi plusieurs en fonction de données reçues depuis un port.

Parmi les approches existantes supportant ce type de composition, on peut citer comme exemple Gwendia [85] ainsi que le modèle de composants décrit dans [77]. STCM [27] est un autre modèle de composants supportant cette approche qui com-bine la notion de tâches et de composants dans une même unité de composition dis-posant d’interfaces use/provide et d’entrée/sortie, permettant d’effectuer des com-positions selon deux dimensions différentes (composition use-provide et composition à base de flux de travaux décrivant le flux de contrôle d’une application le biais de structures de contrôle telles que des boucles).

Squelettes algorithmiques

La définition des modèles de composants présentée en section2.4.2 est suffisam-ment large pour y inclure des approches basées sur les squelettes algorithmiques présentés en section 2.3.3. On peut donc considérer les fonctions de premier ordre comme des composants, les types de paramètres de leurs prototypes comme des in-terfaces et les squelettes comme des connecteurs (ou des composites) permettant de mettre en relation certaines des interfaces des composants (paramètres de sortie des fonctions). Les approches de squelettes algorithmiques se concentrant tout particu-lièrement sur la définition d’un ensemble de connecteurs (ou composites) spécifiques et prédéfinis afin de pouvoir exprimer une large gamme d’algorithmes.

Parmi les approches existantes de modèles de composants supportant la com-position à base de squelettes algorithmiques, on peut citer notamment STKM [3] qui bénéficie de la composition use-provide et de la composition à base de flux de travaux.

L’expression de squelettes algorithmiques peut aussi se faire à travers la généricité des modèles de composants hiérarchiques. Par exemple, dans HLCM [18], il est possible de créer un composant maître-esclave générique dont l’implémentation est un ensemble d’instances de composants esclaves connectés à un même composant maître. Le choix des composants maître et esclave peut être déterminé par des paramètres génériques.

2.4.5 Conclusion

Dans cette section, nous avons commencé par évoquer l’importance du génie lo-giciel dans la conception d’applications. Nous avons ensuite présenté les approches utilisées jusqu’à maintenant afin de faire face à la complexité croissante des appli-cations ainsi que des métriques et concepts permettant d’évaluer et d’agir sur la qualité de l’architecture des applications. Nous nous sommes concentré plus spéci-fiquement sur les composants logiciels, une approche favorisant la réutilisation de code et la séparation des préoccupations. Pour cela, nous avons fourni une définition des composants et des interfaces, puis nous avons décrit comment ils peuvent être assemblés afin de créer une application complète.

L’utilisation des modèles de composants est aujourd’hui largement démocratisée dans de nombreux domaines de l’informatique, des systèmes embarqués aux services web en passant par la conception de logiciels multimédias (musique, jeux vidéo, etc.). Cependant, l’adoption des approches à base de composants est bien moindre dans le cas des applications HPC. La faible adoption des modèles de composants dans ce domaine peut s’expliquer par la difficulté de combiner efficacement des codes parallèles complexes dans les approches existantes.