Principes g´en´eraux

DEMRAL (Domain Engineering Method for Reusable Algorithmic Libraries[11] pp. 273-291) d´efinit une m´ethodologie compl`ete et d´etaill´ee sur le processus de conception et d’´ecriture d’une librairie active. En voici une synth`ese r´esumant ses objectifs, sa m´ethode et son archi-tecture.

6.1.2.1 Objectifs

– Fournir `a l’utilisateur une interface«intentionnelle»abstraite de tr`es haut niveau. Son code sp´ecifie les probl`emes en termes de concepts propres au domaine et `a un niveau de d´etail appropri´e. Les probl`emes li´es `a l’impl´ementation des composants ne doivent pas interf´erer avec le code utilisateur. Il s’agit toujours de d´ecomposer les probl`emes en abstractions pertinentes ;

– G´en´erer du code efficace en terme de vitesse et de consommation d’espace m´emoire. La g´en´ericit´e ne doit pas s’accompagner d’une d´egradation des performances, toutes les optimisations possibles doivent ˆetre envisag´ees et mises en œuvre et toute fonctionnalit´e

1

106 CHAPITRE 6. M ´ETAPROGRAMMATION STATIQUE

inutile doit ˆetre ´ecart´ee de l’ex´ecutable r´esultant ;

– Permettre une adaptabilit´e et une extensibilit´e maximale. ´Eviter la duplication de code et l’enchevˆetrement des aspects.

6.1.2.2 M´ethodologie

On d´ecompose l’´elaboration de la librairie en trois phases, l’analyse du domaine, la concep-tion puis la mise en œuvre :

1. L’analyse du domaine d´efinit l’objet et l’´etendue du champ d’application de la librairie. Elle identifie les caract´eristiques (features) et contraintes propres `a sa sp´ecialit´e ainsi que les relations aux domaines connexes. Il s’agit entre autre d’extraire les abstractions, les concepts cl´es et les relations qu’ils entretiennent entre eux (similitudes, variations, d´ependences). Cette premi`ere phase a pour but d’exprimer clairement les sp´ecifications abstraites de la librairie sans aborder la conception logicielle.

2. La deuxi`eme ´etape concerne la conception de l’architecture g´en´erale et du langage ap-propri´e n´ecessaire `a l’expression des besoins de l’utilisateur (DSL de configuration,

confi-guration domain-specific language). La grammaire de ce langage d´ecoule directement de

l’analyse abstraite pr´ec´edente et des d´ecisions architecturales de la pr´esente phase. 3. Enfin, la troisi`eme partie consiste `a mettre en œuvre le DSL, son parser et l’ensemble

des composants logiciels utilis´es. Cette collection de composants poss`ede une interface appel´ee ICCL (Implementation Components Configuration Language). Le parser traduit l’expression du DSL en une expression de l’ICCL et l’assembleur de composant construit les classes et les algorithmes demand´es.

6.1.2.3 Architecture

La figure 6.1 montre comment une configuration utilisateur abstraite exprim´ee grˆace au DSL est pars´ee et traduite en configuration concr`ete exprim´ee dans le langage interne qu’est l’ICCL. `A partir de cette expression l’assembleur de composants construit les types et ´even-tuellement les algorithmes requis. L’ensemble parser - assembleur est appel´e g´en´erateur. 6.1.3 Mise en œuvre

Cette section d´ecrit les techniques de mise en œuvre du DSL, de l’ICCL et du g´en´erateur de mani`ere g´en´erale et en C++ en particulier.

6.1.3.1 Domain-specific language (DSL)

LesDomain-Specific Languagessont des langages de programmation d´edi´es `a un domaine

d’application particulier, permettant `a l’utilisateur de travailler directement avec les concepts du domaine concern´e grˆace `a des abstractions de plus haut niveau que les composants logiciels, mˆeme g´en´eriques. En utilisant de tels langages, le programmeur, qui maˆıtrise le vocabulaire

6.1. LIBRAIRIES ACTIVES ET PROGRAMMATION G ´EN ´ERATIVE 107 Parser Code généré Expression DSL Expression ICCL Assembleur Composants

Fig. 6.1 – Structure d’une librairie active

et les sp´ecificit´es du domaine, peut s’´epargner l’apprentissage des techniques purement infor-matique, d’autant plus que la plupart du temps des m´ecanismes d’optimisation tr`es pointus sont incorpor´es. Le spectre des domaines est d´ej`a vaste : le calcul symbolique, num´erique ou matriciel (Maple), les finances, l’´electronique, la t´el´ephonie et bien d’autres.

Les DSL se pr´esentent sous forme d’applications ind´ependantes ou sont impl´ement´es dans un langage de programmation d´ej`a existant. L’utilisation du C++ permet par exemple de profiter des techniques de programmation g´en´erique qui leur font parfois d´efaut. La Gene-rative Matrix Computation Library (GMCL, [11] pp. 293-427) d´efinit un tel langage dans le domaine de la programmation matricielle et sur le C++. Elle va plus loin que la Matrix Template Library (MTL, [60]) qui ne fait qu’´etendre STL au domaine des matrices. Notre travail sur les machines `a ´etats s’inspire fortement de GMCL et de MTL en ´etendant les concepts de programmation g´en´erative aux machines `a ´etats et en d´efinissant en C++ le DSL correspondant.

Les DSL se caract´erisent par un vocabulaire propre au domaine auquel ils s’appliquent et ´evidemment par une grammaire. Peu importe sa forme et sa mise en œuvre, le langage doit s’attacher `a :

– ˆEtre le plus exhaustif et le plus pointu possible.

– D´efinir des abstractions proche du domaine concern´e et le plus ´eloign´e possible des consid´erations purement informatiques.

108 CHAPITRE 6. M ´ETAPROGRAMMATION STATIQUE

– Produire du code efficace en tenant compte des ´eventuelles optimisations propres au domaine et `a la machine cible.

Le DSL sp´ecifique aux matrices regroupent des concepts comme les«formes»de matrice (tri-angulaire, diagonale, sym´etrique), le type des ´el´ements (entiers, nombres `a virgule flottante), les matrices lignes ou colonnes, etc. Dans le domaine des machines `a ´etats on rencontre les notions d’orientation des transitions, d’information port´ee par les ´etats ou les transitions, de temps d’acc`es aux transitions et de d´eterminisme. Le DSL permet aussi d’exprimer des directives g´en´erales sur le type d’optimisation d´esir´e (en temps, en espace) et le degr´e de v´erification des donn´ees manipul´ees `a l’ex´ecution (bound checking). En outre, il est charg´e de fournir des valeurs par d´efaut pour chacun des param`etres non sp´ecifi´es par le programmeur. En C++, le DSL ne constitue que la fa¸cade de la librairie. Les expressions sont construites grˆace `a des patrons de classe imbriqu´es repr´esentant un arbre puis des m´etafonctions per-mettent sa compilation en une expression ICCL.

6.1.3.2 Implementation Component Configuration Language (ICCL)

Le DSL est l’interface abstraite entre la librairie et le monde ext´erieur. L’ICCL est en fait l’interface proprement dite ; elle permet la configuration et le param´etrage des composants logiciels concrets qui seront utilis´es lors de la compilation. L’utilisateur n’a pas besoin d’en avoir connaissance car le g´en´erateur se fait l’interm´ediaire entre ses sp´ecifications et le code disponible dans la librairie. En C++, l’ICCL prend la forme d’une collection de patrons de classes et de fonctions que le compilateur combinera et instanciera en fonction des besoins.

6.1.3.3 G´en´erateur

Le g´en´erateur au sens large comprend la partie parser ou g´en´erateur de configuration et l’assembleur de composants. Le g´en´erateur de configuration se charge d’interpr´eter les sp´ecifications venant du DSL pour construire le composant. L’assembleur se sert des sous-composants pour construire les types `a partir d’expressions formul´ees en ICCL par le g´en´era-teur de configuration.

En C++, c’est le compilateur qui g´en`ere, `a partir d’un type sous forme de patrons de classe imbriqu´es, un type concret de composant grˆace `a un m´etaprogramme. Il g`ere en outre les valeurs par d´efaut des sp´ecifications qui n’auraient pas ´et´e pr´ecis´ees. Le g´en´erateur n’est donc rien d’autre qu’une grosse m´etafonction des types abstraits d´efinissables par le DSL vers les types concrets disponibles dans l’ICCL.

La section suivante introduit les techniques de m´etaprogrammation en C++ qui sont `a la base de l’´elaboration des librairies actives.