Cette section évalue les propriétés de génie logiciel deCometsur le cas de l’ad- vection 2D. Plus précisément, elle analyse la séparation des préoccupations, la flexi- bilité et la réutilisation du code des assemblages Cometdétaillées en section 6.1.4 par rapport aux versions de référence présentées en section 6.1.2.
6.2.1 Séparation des préoccupations
Nous avons vu dans les sections 6.1.1 et 6.1.2 que l’advection 2D est décompo- sée en deux parties distinctes : le calcul des gradients et l’interpolation. Le calcul de l’interpolation peut être calculé de plusieurs manières laissant la place à deux variantes algorithmiques : Splines et Lagrange.
Mise en œuvre dans les versions Comet Comet permet de séparer les dif- férentes parties dans des unités logicielles distinctes décrivant explicitement leurs dépendances. En effet, le calcul des gradients est réalisé par une métatâche dédié (ainsi qu’un composant associé). Il en est de même pour le calcul de la variante
6.2. ÉVALUATION DES PROPRIÉTÉS DE GÉNIE LOGICIEL 135 Spline et celui de la variante Lagrange qui ont tous les deux des métatâches et com- posants spécifiques. Les dépendances des métatâches et les composants responsables de leurs mises en œuvre disposent d’interfaces décrivant l’ensemble de leurs dépen- dances. Leurs interfaces sont suffisamment généralistes (ports de données trans- mettant des buffers multidimensionnels partitionnés en blocs réguliers) pour qu’une variante puisse être remplacée par une autre. Le fonctionnement de ce remplacement est visible à la figure6.3.
Bénéfices Une telle décomposition permet de séparer les préoccupations de l’ap- plication. Par exemple, une personne spécialiste de l’interpolation par splines ou de l’interpolation à base de polynômes de Lagrange n’a pas à se préoccuper du calcul des gradients et inversement. Dans le cas contraire, la multiplication des préoccu- pations dans une même portion du logiciel nuit à sa maintenabilité. La difficulté à maintenir l’application peut augmenter exponentiellement en fonction du nombre de variantes considérées et le nombre de parties couplées et devenir un problème majeur à l’échelle de l’application entière. En effet, le couplage des différentes parties avec une autre peut dépendre des variantes considérées (p. ex. version à grain fin) et le nombre de combinaisons possibles correspond au produit du nombre de variantes de chacune des parties.
Limites des versions Comet actuelles La gestion des données temporaires mise en place manuellement dans les versions Comet réalisées renforce la dépendance entre les deux métatâches composées. En effet, les données temporaires sont ac- tuellement détruites par les tâches issues de la métatâche d’interpolation et donc ces données ne peuvent pas être réutilisées ensuite par d’autres métatâches pou- vant être ajoutées dans l’assemblage (p. ex. métatâche d’analyse des données). Or la mise en œuvre des composants d’une application ne devrait pas dépendre de l’as- semblage, sous peine de limiter les modifications possibles de l’assemblage et donc de dégrader la maintenabilité de l’ensemble. De plus, il est important de noter que le repartitionnement des données temporaires allouées par morceaux (non implémenté actuellement) peut introduire des copies supplémentaires (obligatoires) et donc un surcoût devant être étudié. La source de ce problème provient de la mise en œuvre Halley qui ne supporte pas l’allocation de données temporaires par morceaux ac- tuellement4. La mise en place de mécanisme d’allocation par morceaux efficace et généraliste est actuellement un problème ouvert et l’impact sur le modèle Comet est pour le moment inconnu.
Informations complémentaires Afin de préserver la séparation des préoccupa- tions, il est important de noter que deux types de métatâches ont été définis, car une modification d’une des métatâches ne devrait pas avoir d’impact sur les autres.
4. au lieu d’allouer un buffer de données en entier et de le partitionner ensuite, des fragments sont alloués un à un ou en groupe afin de réduire la quantité de mémoire nécessaire à l’exécution de l’application, mais aussi afin de permettre une réutilisation des fragments alloués et ainsi améliorer l’utilisation du cache tout en limitant les coût relatifs de la pagination
Version Variante Lignes de code Lignes partagées entre les variantes
Impl. En-tête Déf.
Référence Splines 953 464 - 426
(dont 426 d’en-têtes)
Lagrange 758 479 -
Comet Splines 1244 586 181 1257 (dont 532 d’implémentation, 571 d’en-têtes et 154 de définitions)
Lagrange 866 586 181
Table 6.2 – Nombre de lignes de code C++ (hors espaces, commentaires et asser- tions) et de lignes réutilisées entre les deux variantes Splines et Lagrange des versions de référence et Comet. Les en-têtes comprennent les définitions des structures de données ainsi que les interfaces de composants. Les définitions comprennent les fi- chiers de description des métatâches et de l’assemblage. Les abréviations Impl. et Déf. sont utilisées pour désigner respectivement les mots Implémentation etDéfini- tion. Le nombre de lignes de code n’inclus pas les greffons (réalisés par les experts).
C’est en particulier le cas si une version à grain fin est mise au point pour une des variantes.
6.2.2 Partage de code entre les variantes
Le tableau6.2 présente le nombre de lignes de code et de lignes réutilisées entre les deux variantes Splines et Lagrange des versions de référence et Comet. Le code des greffons devant être écrits par des experts n’est pas compris dans le nombre de lignes.
Globalement, les versions Comet utilisent une quantité de lignes de code plus grande que celles de référence : de 42% dans le cas Splines à 32% dans le cas La- grange. Cette différence provient principalement de la description des composants (implémentation), des interfaces (en-têtes), des métatâches (définitions), de l’assem- blage (définitions) nécessaire pour faire fonctionner la version Comet.
Toutefois, on constate que la version Comet permet de partager beaucoup de lignes de code entre les versions (2,95 fois plus). En particulier, la version Co- met permet de réutiliser simplement une partie de l’implémentation, le calcul des gradients, ce qui n’est pas le cas de la version de référence. En effet, bien que la version Comet ajoute respectivement 291 et 108 lignes de code correspondant à l’implémentation par rapport à la version de référence sur les variantes Splines et Lagrange, 532 lignes d’implémentation sont partagées entre les deux variantes. Dans l’ensemble, les versions Comet contiennent plus de code réutilisable que celles de référence : de 63% (Splines) et 77% (Lagrange) avecCometà 30% (Splines) et 34%
avec la version de référence.
6.2.3 Remplacement de variantes
Le remplacement d’une variante par une autre est traité de manière totalement différente entre les deux versions. D’une part, la version de référence implémente les
6.3. ÉVALUATION DES PERFORMANCES 137