Du support générique d’opérateurs de
composition dans les modèles de composants
logiciels

 Validation 

Application à SCA : GenericSCA

Le patron de conception présenté à la section 4.2.1 a été appliqué à SCA. Le métamodèle de SCA du «projet d’outils Eclipse pour SCA2 » a été utilisé. Les concepts qui ont été rendu génériques dans le cadre de GenericSCA sont les composants (primitifs et composites). Le support des generics Java a aussi été ajouté. Les concepts qui peuvent être utilisés comme paramètres de type génériques dans GenericSCA sont les mises en œuvres de composants,les interfaces de ports, les types de données et les valeurs de données pour les composites. Les composants primitifs acceptent des types de données et les valeurs de données comme paramètres et les generics Java les classes Java. Le métamodèle de GenericSCA est basé sur une copie de celui de SCA. Il comporte huit classes additionnelles pour modéliser la généricité : GenericImplementation, ImplementationParameter, ImplementationArgument, GenericInterface, InterfaceParameter, InterfaceArgument, JavaTypeParameter et JavaTypeArgument. Il n’a pas été nécessaire de créer une classe pour modéliser les types Java génériques car dans le métamodèle de SCA sur lequel nous nous sommes basé, les types Java sont simplement modélisés par une chaîne de caractères contenant leur nom. Il n’a pas non plus été nécessaire de modifier le métamodèle pour supporter les valeurs de données en paramètres car le concept de propriétés de configurations de SCA correspond déjà à cette utilisation. Le support des contraintes pour les paramètres des types de composants génériques passe par l’ajout d’une classe au métamodèle : Constraint de laquelle dérivent toutes les autres. Les différentes classes de contraintes existantes dans GenericSCA sont les suivantes. Une classe XpathConstraint modélise des contraintes sur des valeurs de données exprimées sous la forme d’une expression XPath booléenne qui constitue la manière classique de manipuler des valeurs de données en SCA. Pour les autres types de paramètre la seule classe de contrainte existante pour l’instant est constituée de l’égalité modélisée par les classes ImplementationEqConstraint, InterfaceEqConstraint et JavaTypeEqConstraint. Finalement, trois classes de contraintes servent à modéliser les combinaisons logiques d’autres contraintes : ConjonctionConstraint, DisjunctionConstraint et NegationConstraint. Le support des spécialisations explicites a été mis en œuvre selon la première approche proposée pour les composants composites. Le choix de cette approche est dû au fait qu’elle est moins invasive et donc plus facile à mettre en œuvre dans le cadre d’une modification d’un métamodèle existant. Une classe compositeSpecialization a été ajoutée au modèle qui modélise cet aspect.

Mise en œuvre

Un prototype de mise en œuvre de l’algorithme de transformation d’assemblages GenericSCA en assemblages SCA de base a été réalisé et est disponible au téléchargement (http: //graal.ens-lyon.fr/~jbigot/genericSCA). Il met en œuvre l’algorithme présenté en 4.2.2. Le cas des generics Java est particulier puisqu’il consiste simplement à vérifier la compatibilité des types utilisés comme paramètre et à les effacer. En effet, Java gère les generics à l’exécution par effacement de type, les paramètres ne sont utilisés que pour assurer la sûreté de typage à la compilation et sont complètement oubliés à l’exécution. Puisque les métamodèles manipulés sont modélisés en Ecore, il a tout d’abord semblé intéressant de s’appuyer sur les langages spécifiques au domaine (Domain Specific Language – DSL) dédiés à la transformation de modèle dans EMF. Un premier essai a été effectué avec QVT (Query View Transform) et plus particulièrement sa version impérative QVTO (QVT Operational). Le support de ce langage n’était toutefois pas satisfaisant lors du développement du prototype et l’algorithme de transformation a finalement été développé en Java. Les classes Java qui correspondent à celles du métamodèle de GenericSCA ont été automatiquement générées. Le parseur pour instancier ces classes depuis les documents XML SCA a aussi été automatiquement généré grâce à des annotation du métamodèle de SCA. Les classes Java correspondant au métamodèle de SCA et le code utilisé pour générer les documents XML SCA une fois la transformation effectuée sont ceux du projet d’outils Eclipse pour SCA. Finalement, plus de 50 000 lignes de code Java ont été générées et autant sont issues de la réutilisation de code existant. La mise en œuvre du cœur de l’algorithme de transformation requiert environs 750 lignes de Java dont la majorité consiste simplement en des copies d’attributs de classes GenericSCA vers l’attribut du même nom d’une classe SCA (dernier cas de l’algorithme de la section 4.2.2). Ce code aurait pu être généré si un langage dédié à la transformation de modèle comme QVT avait pu être utilisé. La logique de l’algorithme elle-même ne constitue  Gen Farm D in in out in workers out in collector out out SCA Gen Replication C I=I, O=O, R=N, C=W T=I T=O Figure 4.13 – Le composant générique Farm. Il s’agit d’un composite qui contient trois instances dispatcher, workers et collector. qu’environs 100 lignes de ce code bien qu’il soit difficile de donner une estimation précise puisqu’elle est fortement imbriqué avec le reste. 4.3.3 Exemples d’utilisation de GenericSCA Ce prototype a été validé en développant en GenericSCA une mise en œuvre du squelette ferme de tâches. Il s’agit d’un composant composite générique acceptant en paramètres des types java, des mises en œuvre de composant et une valeur de donnée. Sa mise en œuvre repose sur de la méta-programmation pour contenir le bon nombre d’instances de composant. Cette mise en œuvre de la ferme de tâches a été utilisée avec succès pour calculer des images de l’ensemble de Mandelbrot pixel par pixels et par blocs d’image. La fin de cette section présente cet exemple plus en détail. Le composant générique «Farm» Le composant générique Farm présenté graphiquement sur la figure 4.13 est un composite qui accepte six paramètres : – deux paramètres sont des types Java (I et O) qui décrivent le type des données en entrée et sortie de la ferme respectivement ; – trois paramètres décrivent des mises en œuvres de composants (D, W et C) qui définissent les types du distributeur de données, des travailleurs et du collecteur respectivement ; – un paramètre est un entier (N) qui définit le nombre de travailleur dans la ferme. Ce composite contient simplement une instance de chacun des composants D et C. Il s’appuie sur le composite Replication décrit plus en détail ci-après pour créer des instances du composant W. Ces instances sont connectés par un flux de donnée mis en œuvre grâce à l’interface Java générique DataPush qui comporte une unique méthode void push(A data). Cette interface est utilisée avec T comme argument avant le passage dans les travailleurs et avec O après. Les paramètres D et C ont des valeurs par défaut : RRDispatcher et SimpleCollector respectivement. Ces composants distribuent les données selon l’algorithme du tourniquet (round-robbin) et les collectent sans réordonnancement particulier. Ce sont des mises en œuvres Java génériques qui ne dépendant pas du type des données manipulées. Le composant générique «Replication» Le composant générique Replication présenté graphiquement sur la figure 4.14 réplique un certain nombre d’instances d’un type de composant donné. Il accepte quatre paramètres : – deux paramètres sont des types Java (I et O) qui définissent le type des données en entrée et en sortie du composant ; – un paramètre est une mise en œuvre de composant (C) qui définit le type du composant répliqué ; – le dernier paramètre est un entier (R) qui définit le nombre de fois que le composant est répliqué.

Conclusion 

initial Gen When (R==1) C id = 0 additional Gen Replication C in in in in out out out others SCAReplication R = R-1 in out id = R-1 out Figure 4.14 – Le composant générique Replication. Il s’agit d’un composite qui contient deux instances additional et others. Il possède une spécialisation explicite utilisée quand la valeur du paramètre R est 1. Cette spécialisation explicite ne contient qu’une instance initial. Sa mise en œuvre s’appuie sur la méta-programmation et sur la récursivité. Elle contient une instance de C appelée additional et une instance de Replication où la valeur du paramètre R est décrémentée de 1. Le cas de base de la récursivité est définit par la spécialisation explicite utilisée quand la valeur de R atteint 1. Dans ce cas, seule l’instance de C est créée. Évaluation Cet exemple démontre qu’il est possible de mettre en œuvre des squelettes algorithmiques à l’aide des concepts de généricité et de hiérarchie. L’introduction de la métaprogrammation rend cependant l’analyse du comportement de tels composants complexe à analyser. Cette mise en œuvre de la ferme de tâches a été utilisée pour calculer des images de l’ensemble de Mandelbrot. Deux sortes de travailleurs ont été développés et utilisés au sein de la ferme : – le premier calcule la valeur d’un unique pixel à la fois ; – le second travaille sur des morceaux plus importants de l’image dont la taille exacte peut être paramétrée. Ces deux versions ont été déployées avec succès au sein de la ferme sur une machine multi-cœur en faisant varier le nombre de travailleurs entre un et quatre. La phase de transformation a nécessité entre une et deux secondes avec l’essentiel du temps utilisé à analyser les fichiers en entrée. 4.4 Conclusion Cette section a étudié la faisabilité d’introduire la généricité dans les modèles de composants afin de pouvoir y décrire de nouveaux squelettes. Pour cela, un patron de conception qui permet d’étendre un modèle de composants existant pour lui ajouter la généricité a été proposé. Un algorithme qui étant donné un assemblage décrit dans ce nouveau nouveau modèle permet de générer un assemblage équivalent dans le modèle d’origine a aussi été décrit. Ceci a été appliqué à SCA pour donner GenericSCA qui a été validé en mettant en œuvre une application de rendu d’image basé sur le squelette de ferme de tâches.