Framework

Comme on l’a vu dans les sections pr´ec´edentes, un certains nombre d’objets math´ematiques (e.g. les polynˆomes dans la base monomiale ou de Bern- stein) sont n´ecessaires pour repr´esenter les courbes et les surfaces et des algorithmes sp´ecifiques sont associ´es `a ces diff´erentes repr´esentations. Une attention particuli`ere est port´ee `a la g´en´ericit´e dans la conception des structures pour lesquelles on veut garder une certaine efficacit´e. Grˆace `a la param´etrisation du code en utilisant des templates et au contrˆole de leur instanciation en utilisant des traits et des template expressions [33], on peut faire de la programmation g´en´erique sans pour autant perdre en efficacit´e. Les impl´ementations g´en´eriques, qui permettent la r´eutilisation du code sur les diff´erents types de repr´esentation de donn´ees, sont combin´ees avec des impl´ementations sp´ecialis´ees qui sont adapt´ees pour des op´erations critiques sur certaines de ces structures.

Le fait qu’une structure math´ematique repr´esente un objet g´eom´etrique particulier est une information importante pour programmer de mani`ere g´en´erique (cela permet de sp´ecifier les algorithmes ad´equats). En consid´erant une hi´erarchie de classes et en impl´ementant des sp´ecialisations `a chacun de ses niveaux, l’impl´ementation la plus sp´ecifique d’un algorithme est tou- jours choisie `a l’ex´ecution ce qui permet d’ˆetre efficace et de simplifier le d´eveloppement.

Dans cette section, on d´ecrit la conception de la couche interne d’Axel per- mettant une telle combinaison.

4.2. Point de vue d´eveloppeur 111

Object

Curve Surface

ParametricCurve ImplicitCurve ParametricSurface ImplicitSurface

PolynomialCurve BSplineCurve PolynomialSurface BSplineSurface

Fig. 4.8: Hi´erarchie virtuelle d’objets.

4.2.1.1 Hi´erarchie virtuelle d’objets

Les objets g´eom´etriques et alg´ebriques peuvent ˆetre organis´es au sein de diff´erentes cat´egories. De mani`ere plus pragmatique, cette classification d’ob- jets se retrouve dans une structure d’arbre dans laquel les noeuds corres- pondent aux classes abstraites. Une relation parent enfant dans cet arbre correspond `a une relation d’h´eritage. La structure dans son ensemble est appel´e une hi´erarchie virtuelle.

Une feuille correspond `a la mani`ere la plus sp´ecifique de « voir » un objet et chaque chemin qui part de la racine pour arriver `a cette feuille dans cette hi´erarchie virtuelle est une mani`ere de « voir » cet objet de la plus g´en´erique `

a la plus sp´ecifique. Dans un tel parcours, `a chaque niveau, l’objet acquiert de nouveaux attributs qui peuvent donner lieu `a de nouvelles fonctions ou des sp´ecialisations (surcharge en la programmation objet) de fonctions exis- tantes.

Outre le fait que la classification est une notion naturelle qui correspond `a la r´ealit´e, il y a deux avantages principaux `a une telle organisation. D’une part, cette hi´erarchie permet de lancer les algorithmes ad´equats en choisis- sant l’impl´ementation la plus adapt´ee au probl`eme. D’autre part, elle donne la possibilit´e au d´eveloppeur d’int´egrer ses propres types de donn´ees `a n’im- porte quel niveau de la hi´erarchie et donc, par h´eritage, de b´en´eficier de tous les algorithmes et fonctionnalit´es d´efinis `a un niveau plus haut.

Le m´ecanisme de s´election peut ˆetre fait de plusieurs fa¸cons. En effet, de nombreux langages tels que le C++ ont leur propre m´ecanisme de s´election

Intersection Intersection <Curve> Intersection <Surface> Intersection <ParametricCurve> Intersection <ImplicitCurve> Intersection <ParametricSurface> Intersection <ImplicitSurface> Intersection <PolynomialCurve> Intersection <PolynomialSurface> Intersection <BSplineSurface> Intersection <BSplineCurve>

Fig. 4.9: Hi´erarchie virtuelle d’outils.

(en utilisant le mot cl´e virtual dans ce cas). Sinon, il est possible d’uti- liser des design patterns d´edi´es tels que les Concept-Vue-Interface pattern. Dans ce cas, la hi´erarchie virtuelle est construite en utilisant un wrapper « templat´e » pour lier une interface `a son impl´ementation. Le m´ecanisme de s´election est r´ealis´e en combinant la surcharge avec l’utilisation des espaces de nommage dans lesquels les fonctions globales sont d´efinies de mani`ere `

a pouvoir utiliser la repr´esentation de l’objet. Par exemple, la figure 4.8

montre une hi´erarchie simple d’objets g´eom´etriques qui est assez proche de celle que l’on trouve dans Axel.

4.2.1.2 Hi´erarchie virtuelle d’outils

Les outils g´eom´etriques et alg´ebriques (ou les algorithmes) peuvent ´egalement ˆetre classifi´es. Il s’agit, l`a aussi, d’une hi´erarchie virtuelle. Cependant, ´etant donn´e que les algorithmes d´ependent des types de leurs arguments, cette derni`ere est ´etroitement li´ee `a la hi´erarchie virtuelle d’objets.

Le m´ecanisme de s´election, g´en´eralement utilis´e avec les fonctionnalit´es d’un objet (une m´ethode d’une classe en programmation objet), fonctionne de la mˆeme mani`ere sur la hi´erarchie d’outils ou d’algorithmes. Ces derniers peuvent ´eventuellement ˆetre d´efinis en utilisant le pattern template method. Si on consid`ere par exemple un algorithme d’intersection, il est possible de d´efinir un sch´ema g´en´erique de subdivision qui subdivise un domaine donn´e et qui se base sur un pr´edicat pour s’arrˆeter ou continuer. Un autre

4.2. Point de vue d´eveloppeur 113 pr´edicat est alors utilis´e pour traiter une cellule qui ne sera plus divis´ee. On peut utiliser ce sch´ema pour d´efinir une intersection de surfaces comme le montre la figure 4.9. A ce niveau, aucun pr´edicat ne peut ˆetre sp´ecialis´e. Cependant en consid´erant que les surfaces `a intersecter sont param´etr´ees, cela permet de disposer de fonctions d’´evaluation. Ainsi, une approximation du lieu d’intersection peut-ˆetre impl´ement´ee en ´echantillonnant des points sur les grilles de chacune des surfaces par exemple. Maintenant, si on sait de plus que les surfaces sont polynomiales, alors on peut acc´eder `a leurs repr´esentations internes (en l’occurrence aux ´equations) et ainsi les utiliser pour mettre en place des crit`eres d’injectivit´e (comme ceux d´ecris dans les sections 3.5.4 et 3.6 du chapitre 3) permettant de rendre les calculs plus efficaces et de certifier le r´esultat.

Le choix d’un algorithme peut ˆetre r´ealis´e au moment de l’ex´ecution de diff´erentes mani`eres. Axel estime que l’impl´ementation la plus sp´ecifique est ´egalement la plus efficace. Mais l’utilisateur peut choisir n’importe quel algorithme dans la hi´erarchie virtuelle d’outils.

Dans la mesure o`u ces hi´erarchies peuvent ˆetre utilis´ees pour int´egrer des plugins d´edi´es, on doit ´egalement pouvoir lier ces hi´erarchies avec des fonc- tionnalit´es d’une application externe. Dans la section qui suit, on d´ecrit la m´ethode adopt´ee pour construire des modules dynamiques en combinant du code g´en´erique et sp´ecifique `a travers un m´ecanisme de plugin transpa- rent. La connexion avec la librairie de calcul symbolique Mathemagix illustre bien cette approche. Elle sert en fait de base aux calculs avec des polynˆomes repr´esentant les courbes et surfaces alg´ebriques.