Ingénierie de la spécialisation de programmes 1 : principes et applications (Coll. Logique et programmation)

-

Livres
355 pages
Lire un extrait
Obtenez un accès à la bibliothèque pour le consulter en ligne
En savoir plus

Description

La spécialisation de programmes, aussi appelée évaluation partielle, est une technique générale destinée à rendre les programmes plus performants (plus rapides et possiblement plus petits) quand certaines entrées peuvent être connues à l’avance. Du point de vue du génie logiciel, la spécialisation facilite aussi grandement l’écriture des programmes et leur maintenance.
Cet ouvrage, conçu à la fois pour les chercheurs et les ingénieurs logiciels, tant architectes que développeurs, en fait une large présentation pratique.
Ce volume pose la problématique de l’adaptation par la spécialisation. Il présente les grands principes de la spécialisation de programmes ainsi que les techniques de spécialisation, en se concentrant plus particulièrement sur la spécialisation dite hors ligne. À titre illustratif, il décrit aussi l’architecture de Tempo, spécialiseur hors ligne pour le langage C, capable d’effectuer des spécialisations en cours d’exécution.
Il est illustré de résultats chiffrés pour des applications concrètes dans différents domaines.
Avant-propos. Chapitre 1. Introduction : spécialiser pour adapter. Chapitre 2. Préliminaires sur les langages et les programmes. Chapitre 3. Les grands principes de la spécialisation de programmes. Chapitre 4. Techniques de spécialisation. Chapitre 5. Spécialisation hors ligne. Chapitre 6. Un spécialiseur pour C : Tempo. Chapitre 7. Applications de la spécialisation. Bibliographie. Table des figures. Index.

Sujets

Informations

Publié par
Date de parution 21 septembre 2011
Nombre de visites sur la page 6
EAN13 9782746242098
Langue Français

Informations légales : prix de location à la page 0,066 €. Cette information est donnée uniquement à titre indicatif conformément à la législation en vigueur.

Signaler un problème

2101-Marlet:Layout 1 28/06/11 15:57 Page 1
collection Logique et programmation dirigée par Marc Pouzet collection Logique et programmation dirigée par Marc Pouzet
La spécialisation de programmes, aussi appelée évaluation partielle,
est une technique générale destinée à rendre les programmes plus
performants (plus rapides et possiblement plus petits) quand certaines
entrées peuvent être connues à l’avance. Du point de vue du génie
logiciel, la spécialisation facilite aussi grandement l’écriture des
programmes et leur maintenance. Cet ouvrage, conçu à la fois pour les
chercheurs et les ingénieurs logiciels, tant architectes que
développeurs, en fait une large présentation pratique. Ingénierie
Ce volume pose la problématique de l’adaptation par la spécialisation.
Il présente les grands principes de la spécialisation de programmes
ainsi que les techniques de spécialisation, en se concentrant plus
particulièrement sur la spécialisation dite hors ligne. A titre illustratif, de la spécialisation
il décrit aussi l’architecture de Tempo, spécialiseur hors ligne pour le
langage C, capable d’effectuer des spécialisations en cours d’exécution.
Il est illustré de résultats chiffrés pour des applications concrètes dans de programmes 1différents domaines.
L’auteur
principes et applicationsIngénieur de l’Ecole polytechnique et docteur en informatique,
Renaud Marlet a occupé des postes dans la recherche publique
(INRIA) et l’industrie logicielle (PME, startup). Multidisciplinaire, il est
actuellement chercheur senior à l’Ecole des Ponts ParisTech, où il
dirige le pôle de recherche IMAGINE.
Renaud Marlet
978-2-7462-2101-7
Z(7ic7e6-CCBABH(
www.hermes-science.com
Renaud Marlet
Ingénierie de la spécialisation de programmes 116






Ingénierie de la spécialisation de programmes 1



































© LAVOISIER, 2011
LAVOISIER
11, rue Lavoisier
75008 Paris

www.hermes-science.com
www.lavoisier.fr

ISBN 978-2-7462-2101-7



Le Code de la propriété intellectuelle n'autorisant, aux termes de l'article L. 122-5, d'une part,
que les "copies ou reproductions strictement réservées à l'usage privé du copiste et non
destinées à une utilisation collective" et, d'autre part, que les analyses et les courtes citations
dans un but d'exemple et d'illustration, "toute représentation ou reproduction intégrale, ou
partielle, faite sans le consentement de l'auteur ou de ses ayants droit ou ayants cause, est
illicite" (article L. 122-4). Cette représentation ou reproduction, par quelque procédé que ce
soit, constituerait donc une contrefaçon sanctionnée par les articles L. 335-2 et suivants du
Code de la propriété intellectuelle.
Tous les noms de sociétés ou de produits cités dans cet ouvrage sont utilisés à des fins
d’identification et sont des marques de leurs détenteurs respectifs.


Printed and bound in England by CPI Group (UK) Ltd, Croydon, CR0 4YY, September 2011.








Ingénierie


de la spécialisation

de programmes 1

principes et applications









Renaud Marlet







Collection logique et programmation
dirigée par Marc Pouzet




Ingénierie de la spécialisation de programmes 2 : techniques avancées –
Renaud Marlet, 2011

Tabledesmatières
Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Entrerechercheetingénierie . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Publicpourcetouvrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Organisationdel’ouvrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
RendreàCésar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Chapitre1.Introduction:spécialiserpouradapter . . . . . . . . . . . . . . 17
1.1. Paramètresdeproductionetéquationéconomiquedulogiciel . . . . . 18
1.2. Variabilitéetlignesdeproduits . . . . . . . . . . . . . . . . . . . . . . 24
1.3. Réutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.4. Génielogicieldel’adaptation . . . . . . . . . . . . . . . . . . . . . . . 30
Chapitre2.Préliminairessurleslangagesetlesprogrammes . . . . . . . . 33
2.1. Langagesdeprogrammation . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2. Sémantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3. Équivalencedeprogrammes . . . . . . . . . . . . . . . . . . . . . . . . 57
2.4. Exécution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.5. Performancedesprogrammes . . . . . . . . . . . . . . . . . . . . . . . 74
2.6. Analysesdeprogrammes . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2.7. Transformationsdeprogrammes . . . . . . . . . . . . . . . . . . . . . 82
Chapitre3.Lesgrandsprincipesdelaspécialisationdeprogrammes . . . 87
3.1. Programmespécialisé. . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.2. Spécialiserpouraméliorerlaperformance . . . . . . . . . . . . . . . . 103
3.3. Spécialisationautomatique . . . . . . . . . . . . . . . . . . . . . . . . . 108
3.4. Lesgrandesapplicationsdelaspécialisation . . . . . . . . . . . . . . . 113
3.5. Momentsdespécialisation . . . . . . . . . . . . . . . . . . . . . . . . . 119
56 Ingénieriede laspécialisation -I
3.6. Rentabilitédelaspécialisation . . . . . . . . . . . . . . . . . . . . . . . 124
Chapitre4.Techniquesdespécialisation . . . . . . . . . . . . . . . . . . . . . 131
4.1. Lestransformationsdeprogrammesdelaspécialisation . . . . . . . . 132
4.2. Terminaisondelaspécialisation . . . . . . . . . . . . . . . . . . . . . . 146
4.3. Correctiondelaspécialisation . . . . . . . . . . . . . . . . . . . . . . . 148
4.4. Autresformesdespécialisation . . . . . . . . . . . . . . . . . . . . . . 154
Chapitre5.Spécialisationhorsligne . . . . . . . . . . . . . . . . . . . . . . . 161
5.1. Lesgrandsprincipesdelaspécialisationhorsligne . . . . . . . . . . . 162
5.2. Intérêtscomparésdelaspécialisationhorsligne . . . . . . . . . . . . . 183
5.3. Principauxingrédientsdel’analysedetempsdeliaison. . . . . . . . . 191
5.4. Casdesentréesstatiquesdevenantdynamiques . . . . . . . . . . . . . 200
Chapitre6.UnspécialiseurpourC:Tempo . . . . . . . . . . . . . . . . . . 209
6.1. Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
6.2. Technologiesenrupture . . . . . . . . . . . . . . . . . . . . . . . . . . 213
6.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
6.4. Économiedel’ingénierie . . . . . . . . . . . . . . . . . . . . . . . . . . 225
6.5. AutourdeTempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
6.6. AutresspécialiseurspourlelangageC . . . . . . . . . . . . . . . . . . 235
Chapitre7.Applicationsdelaspécialisation . . . . . . . . . . . . . . . . . . 239
7.1. Applicationsdanslessystèmesd’exploitationetlesréseaux . . . . . . 241
7.2. Applicationsaucalculnumérique . . . . . . . . . . . . . . . . . . . . . 253
7.3. Applicationsàlacompilationàpartird’interprète . . . . . . . . . . . . 254
7.4. Applicationsàl’optimisationd’architectureslogicielles . . . . . . . . 259
7.5. Laspécialisationcommeoutildegénielogiciel . . . . . . . . . . . . . 276
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Tabledesfigures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313Avant-propos
Iln’yapasd’effortsinutiles,Sisyphesefaisaitdesmuscles.
—RogerCaillois
Entrerechercheetingénierie
J’ai eu la chance dans ma vie d’informaticiende ne pas devoir irrémédiablement
1choisirentrerechercheetingénierie .Etc’estaucontactdecesdeuxmondes,chacun
campé sur ses convictionsmais moins hermétiquesl’un à l’autrequ’onne le dit, que
je me suis souvent posé cette double question : comment mieux écrire de meilleurs
programmes?
Cet ouvrage présente un élément de réponse, à la fois technique et
méthodologique : la spécialisation de programmes (aussi appelée évaluation partielle). En tant
que technique, la spécialisation est un moyen de rendre les programmes plus
performants(plusrapidesetparfoispluspetits).Etmiseauserviced’uneméthodologie,sous
l’angledugénielogiciel,ellefacilited’écrituredesprogrammesetleurmaintenance.
1. Aprèsundiplômed’ingénieur (Écolepolytechnique, Palaiseau), j’aiétédoctorant àl’INRIA(Sophia
Antipolis), assistant de recherche au LFCS (Université d’Édimbourg), ingénieur puis directeur du pôle
informatique d’une agence de Simulog (Toulouse), ingénieur puis chargé de recherche INRIA à l’IRISA
(Rennes), directeur technique adjoint de Trusted Logic (Versailles), chargé de recherche INRIA au LaBRI
(Bordeaux), etactuellement chercheur sénior àl’École desPontsParisTech (Marne-la-Vallée).
-INRIA:Institut National deRecherche enInformatique et enAutomatique.
-IRISA:Institut deRecherche en Informatique et SystèmesAléatoires.
-LaBRI :Laboratoire Bordelais de Recherche enInformatique.
-LFCS:Laboratory forFoundations ofComputer Science.
-Simulog :société spécialisée dans lesproduits et services decalcul scientifique et génie logiciel.
- Trusted Logic : société spécialisée dans les produits et services de très haute sécurité pour les petits
systèmesembarqués (cartes àpuce, téléphones mobiles, terminaux depaiement, domotique, etc.).
78 Ingénieriede laspécialisation -I
Notations.
Lesrenvoisauxsectionsetsous-sectionsdansletextesontnotésprécédés d’un signe « § ». Par exemple, « cf. §3.4.5 » renvoie à la section 4.5 du
chapitre 3. Les renvois d’un volume de cet ouvrage à un autre sont précédés du
numéro de l’autre volume et d’un tiret. Par exemple, à l’intérieur du volume
I,
«cf.II-§3.4.5»renvoieàlasection4.5duchapitre3duvolumeII.Maisàl’intérieurduvolumeII,cemêmerenvoiapparaîtrasimplementcomme«cf.§3.4.5».
2L’idée de la spécialisation de programmesremonte aux années 1960 [LOM64] .
Mais c’est à la fin des années 1980 qu’elle a véritablement pris son essor [BJØ88].
Elle a principalementété développéedans la rechercheacadémique,initialementaux
États-Unis, au Japon, en URSS et en Suède, puis notamment au Danemark et en
France. Mais des chercheurs dans des laboratoires de grandes entreprises s’y sont
aussiintéressés,enparticulierchezMicrosoft.
Des prototypes de spécialiseurs automatiques ont été développés, en particulier
pourdes langagesde haut niveaucomme Lisp, Scheme ou
Prolog,toutefoismodérément répandus dans l’industrie. Mais comme illustré dans ce livre, des spécialiseurs
ontégalementété mis aupointpourdes langagespluslargementutilisés commeCet
Java,spécialiseurscapablesdetraiterdesproblèmespratiques,detailleréelle.
Grâce à ces spécialiseurs, un certain nombre d’expérimentations ont pu être
menées, y compris chez des industriels. Par exemple, Tempo, spécialiseur pour
programmes C développéà l’IRISA (cf. chap. I-6), a été testé par ThomsonMultimédia
pour la spécialisation d’interprètes de commandes de set-top boxes. Et il l’a été
récemmentencoreparSTMicroelectronicspourletraitementmultimédia(MP3,WM9).
Mais malgrédes résultats souventpositifs, avec Tempomais aussi avec
d’autresspécialiseurs et d’autres équipes de recherche à travers le monde, la spécialisation de
programmesn’estpasvéritablementparvenueàfranchirlaportedeslaboratoirespour
devenirunélémentstandarddelaboîteàoutilsduprogrammeur.
Unepremièreraisonà celaest quelaspécialisationdeprogrammesmetenœuvre
des concepts et des outils spécifiques, qui demandentune assez bonnemaîtrise. Cela
peutendécouragercertains,oubienlaisser croireàdes sous-performancessuite à un
usage imparfait. Il faut reconnaître que la technologie actuelle n’est pas totalement
presse-boutonetneparvientpasencoreàcachertouteslescomplexitéssous-jacentes.
Enfait,bienspécialiser(etaubonmoment)estencoreloind’êtreunproblèmecloset
3larecherchesurcethèmeresteactive .Maisdesenseignementspeuventd’oresetdéjà
2. L’idéeremontemêmepourcertains[JON95]audéveloppementdelathéoriedesfonctionsrécursives
dansles années 1930et 1940, et authéorème decurryfication récursive de Kleene [KLE52].
3. Outre des communications à des conférences et revues plus généralistes, une série de rencontres
sponsorisées parl’Association forComputing Machinery (ACM)réunit presquechaque année depuis 1991Avant-propos
9
êtretirés.Undesobjectifsdecetouvrage,outreuneprésentationgénéraledelaspécialisationdeprogrammesetdesesapplications,estd’enexpliquerlesmécanismespour
en réduire la complexité apparente. Il est aussi d’en indiquer les limites et les zones
encoresous-explorées,notammentdanslesensd’uneplusgrandeautomatisation.
Onpeutnotertoutefoisquecesconsidérationssurlesdifficultéstechniquesnesont
pas propres à la spécialisation. On en trouve de similaires pour d’autres méthodes
d’améliorationde la performancedes programmes,comme la parallélisationet, dans
unemoindremesure,lacompilationoptimisante.
Une autre explication à ce succès modéré est que la spécialisation n’est pas une
baguette magiqueà optimiser n’importequel programme; elle
fonctionneparticulièrement bien sur certains types de programmes, mais est peu opérante sur d’autres.
C’estpourcelaqu’ilestavantageuxdel’associeràdespratiquesdegénielogiciel,qui
peuventguider voire garantirune bonne spécialisation. Or ce lien avec le génie
logicielestjusqu’àprésentrestétrèsténu.Unautreobjectifdecelivreestprécisémentde
mieux faire connaître cet aspect porteur de la spécialisation de programmes et de le
promouvoir(cf.chap.I-1etI-§7.5).
D’autres explications encore — car elles sont multiples — sur la faible diffusion
relative de la spécialisation de programmes sont données au chapitre II-8. Il faut
cependant réaliser que des optimisations typiques ou inspirées de la spécialisation sont
malgré tout présentes dans des compilateurs optimisants de niveau industriel, bien
que sous des formes réduites ou adaptées, et que certains systèmes de compilation
fontexplicitementusage dela spécialisationdeprogrammes(cf.II-§7.3.3).Enoutre,
un certain nombre de techniques d’optimisation ad hoc basées sur la génération de
code sont régulièrement utilisées par des industriels sans nécessairement qu’ils
réalisent qu’en fait ils mettent là en œuvre une forme de spécialisation, donc sans mise
enperspectiveetpeut-êtreavecdeslimitationsinfondéesoudescoûtsinutiles.
Selon nous, le champ des recherches et des développements est encore
largement ouvert (cf. chap. II-7), et une plus grande diffusion reste possible (cf. II-§8.4
etII-§8.5).Leverreestrésolumentàmoitiéplein.
Publicpourcetouvrage
Cetouvrageaétéécritdansl’espoirqu’ilprofiteaussibienauxchercheursqu’aux
ingénieurslogiciel,tantarchitectesquedéveloppeurs.
la communauté des chercheurs en spécialisation de programmes : ACM SIGPLAN symposium on Partial
Evaluation and(Semantics-Based) ProgramManipulation, abrégé enPEPM(prononcer «pépeum »).10 Ingénierie delaspécialisation-I
Les chercheursy découvrirontune thématiquetransverseallant de la compilation
au génie logiciel, ou pour ceux qui sont déjà familiers avec la spécialisation de
programmes, un traitement plus en largeur de certains sujets comme la précision des
analysesdeprogrammes(cf.chap.II-1),laréification(cf.chap.II-2),laspécialisation
de programmes incomplets (cf. chap. II-3), l’exploitation efficace de code
spécialisé
(cf.chap.II-4),laspécialisationincrémentale(cf.chap.II-5),laspécialisationdedonnées (cf. chap. II-6), ou encore certains points techniques comme le traitement des
pointeurs de fonctions (cf. I-§6.4.3). Figurent également au fil du texte des
informationspratiquesgénéralementabsentesdespublicationsscientifiques.Letoutesttraité
sanscomplaisance,avecuncertainreculsurlatechnologie(sessuccèsmaisaussises
limites).
Les ingénieurslogiciel ne seront pas en reste car un accent particulier est mis sur
les considérations pratiques, qui infléchissent parfois considérablement les modèles
théoriquestropidéalisés.L’accentestégalementmissurl’explicationdesphénomènes
plutôtquesurlaformulationderésultatsabstraits—cequin’interditpasunerigueur
dans la présentation. Sauf exception, les descriptions formelles des algorithmes,
notammentpourlesanalysesdeprogrammes,nesontpasincluses;lelecteurestrenvoyé
pourcelaauxpublicationscitées,quipourlaplupartsontdisponiblesenligne.
Ce livres’efforceaussi deséparerles conceptsafindemettreenvaleurles enjeux
etlesalternatives.Pourcela,ilprésentelestravauxdedifférentsauteursdansuncadre
homogène,afindemieuxclassifier lesréponsesproposéesetd’apporterdeséléments
de comparaison. Il tente également d’expliciter des arguments et des choix parfois
laissés implicitesouinexpliquésdanslalittératuredudomaine.
Une grande partie de l’ouvrageparle de spécialisation de programmesC et, dans
une bien moindre mesure, de programmes Java et C++. Cela peut sembler restrictif,
mais la plupart des constructions et traits caractéristiques de C sont présents dans la
plupart des langages impératifs plus récents. C’est donc en quelque sorte un point
de passage obligé et central. Bien que les langages fonctionnels et logiques soient
mentionnés à de multiples reprises, leur spécialisation n’est en revanche pas traitée,
mais des références sont fournies. De nombreux autres langages de programmation
sontégalementévoquésaufildutexteàtitredecomparaison.
En outre,bienqu’il détaille des techniqueset des outils de spécialisation,ce livre
ne s’adresse pas uniquement aux développeursou aux utilisateurs de fonctionnalités
despécialisation.Iléclairenotammentlesnotionsdemomentd’exécution(cf.I-§3.5)
et d’échelonnement des calculs dans un programme (cf. II-§5.1). Les notions de
sélection parnécessité (cf.II-§4.4)et de sélectionpar anticipation(cf.II-§4.5)peuvent
également trouver un usage hors de la spécialisation. Le livre établit aussi des liens
entredesoptimisationsdeprogrammesconnuesparailleursmaisquisontd’ordinaire
envisagées séparément(cf. I-§4.4.5),et il présente un cadre général dans lequel elles
s’inscriventetsurtoutsegénéralisent.Avant-propos 11
Ce regard sur certains aspects de la programmation est une forme d’apport en
soi, indépendammentmême d’une éventuelle mise en œuvre de la spécialisation, ou
d’optimisationsen rapportavec la spécialisation. Bien qu’avecdes bénéfices réduits,
laspécialisationdeprogrammespeutd’ailleursêtremiseenœuvre«àlamain»,sans
recoursàunoutilautomatiqueparticulier(cf.I-§7.5.1).C’est mêmeenfaitsouscette
forme que la spécialisation est la plus commune aujourd’hui, et très régulièrement
pratiquée(cf.I-§7.1.4)—souventcommeMonsieurJourdain,laprose.C’esteneffet
une forme de spécialisation qui est employée pour optimiser les chemins critiques
d’unprogramme(trajetsqu’empruntesouventl’exécutionetoùellepassebeaucoupde
temps),quisontleszonesqu’ilestplusrentablederechercheràoptimiserenpremier.
Mêmesi uneinterventionmanuelledansducoden’apas lecaractèresystématiqueet
répétable d’une opération automatique, les principes et techniques présentés dans
ce
livredoiventpermettredestructurerunetelleoptimisation.
Enfin,parcequec’estunsujetparticulièrementimportant,quiapeuétéétudiéjusqu’àprésent,le livremetenavantle lienentrespécialisationdeprogrammeset génie
logiciel. Ce lien explique notamment les situations dans lesquelles la spécialisation
deprogrammesest particulièrementprofitable.Inversement,il fournitdes moyensde
développer des programmes performants sans effort additionnel et sans dégradation
des qualités intrinsèques. À performance égale, les programmes sont plus faciles à
concevoir,àécrire,àvalider,àmaintenir,àréutiliseretàfaireévoluer.
Organisationdel’ouvrage
Cetouvrageestdiviséendeuxvolumes.LevolumeIprésentelesgrandsprincipes
delaspécialisationdeprogrammes,lestechniquesmajeures,lesoutilsexistants,ainsi
que les applications. Le volume II traite pour sa part de sujets plus avancés et ouvre
uncertainnombredeperspectivesscientifiquesetindustrielles.
Bien que l’ensembleforme un tout cohérent,le premier volumepeut se lire
indépendamment, même s’il comporte des références « en avant » au second, qui traite
de certaines questions plus en détails. Ce second volume s’appuie quant à lui sur les
conceptsdéfinisdanslevolumeI,maissanslesrappeler.Cependantdanslamesureoù
laterminologieetlesnotationsemployéesessaientdesuivreauplusprèslespratiques
courantes, il reste relativement autonome et accessible à qui aurait déjà des bases de
spécialisationdeprogrammes.L’organisationdétailléedeschapitresestlasuivante:
I-1.Introduction : spécialiserpouradapter. Lepremierchapitredonneunevue
très générale et non technique de la spécialisation de programmes, et de ses
apports
pourl’industrieinformatique.Nousexaminonsnotammentlesparamètresdeproduction et l’équation économique du logiciel; nous introduisons les problèmes de
variabilité et de lignes de produits; nous détaillons la notion de réutilisation; et nous
esquissons ce qui pourrait être un génie logiciel de l’adaptation.Pour chacun de ces
thèmes,nousétudionslesapportsattendusdelaspécialisationdeprogrammes.12 Ingénierie delaspécialisation-I
I-2. Préliminaires sur les langageset les programmes. Nous posonsensuite un
cadreuniformepourdiscuterdansleschapitressuivantsdepointstechniquesliés aux
langages de programmation en général (sans viser un langage particulier) :
moyens
d’interactiond’unprogramme(entréesetsorties),sémantiqueetéquivalencesdeprogrammes, processus d’exécution, analyses et transformations de programmes. Nous
définissonsourappelonspourcelauneterminologieainsiquedesnotations.
I-3. Les grands principes de la spécialisation de programmes. Puis nous
donnons une première définition de la spécialisation de programmes.Nous analysons sa
nature (exploiter les données connues) et ses objectifs principaux (réduire le temps
d’exécutionet/ou la taille mémoire).Nous caractérisons aussi un
programmespécia-
lisé,notammententermesd’équivalencessémantiquesetdeprécalculs.Nousprésentonsleprincipedel’automatisationduprocessusdespécialisationainsiquesesusages
majeurs, et introduisons la notion de moment de spécialisation. Nous détaillons
égalementlestypesdegainsqueprocureunespécialisation.
I-4. Techniques de spécialisation. Au chapitre suivant, nous expliquons
com-
mentlacréationdeprogrammesspécialiséspeutêtreautomatiséeàl’aidedetransformationsdeprogrammes.Nousdécrivonscellesquisontpertinentes,voirespécifiques
pour la spécialisation. Nous discutons également leur terminaison et leur correction.
Par ailleurs, nous passons rapidementen revue des transformations« cousines », qui
répondentàdesquestionssimilairesàcelledelaspécialisation.
I-5.Spécialisationhorsligne. Nousnousconcentronsdanslasuitesuruneforme
de spécialisationparticulière,la spécialisationdite hors ligne,approchesans doutela
plusrépandueetégalementcellequiaenregistréleplusdesuccès,notammentsurdes
applications réalistes. Nous en présentons les grands principes et discutons en détail
sesavantagesetinconvénientsparrapportàsa«rivale»naturelle,laspécialisationen
ligne. Nous détaillons égalementles ingrédientsprincipauxde l’analyse de temps de
liaison(binding-timeanalysis,BTA),quiestaucœurdelaspécialisationhorsligne.
I-6. Un spécialiseur pour C : Tempo. Nous donnons ensuite les grandes lignes
d’un spécialiseur pour le langage C, appelé Tempo. Après un bref historique axé sur
les besoins en matière de spécialisation, nous indiquons en quoi Tempo a été « en
rupture » par rapport aux autres spécialiseurs. Nous en dessinons les traits saillants
ainsi que l’architecture générale, accompagnés de considérations d’ingénierie. Nous
décrivonségalementquelquessystèmes qui ont été construits autourde Tempo,ainsi
quelesprincipauxautresspécialiseurspourC.
I-7.Applicationsdela spécialisation. Pourmontrerquelaspécialisationestune
technologie«quimarche»,nousprésentonsunensembled’expériencesmenéesavec
Tempo,dansdesdomainesaussivariésquelessystèmesd’exploitation,lesréseaux,le
traitementd’images,le calculscientifique,la compilationà partir d’interprètes,et les
architectureslogicielles.Nousconcluonssuruneobservationimportante:bienquela
spécialisation enregistre de réels succès sur des programmesexistants (legacycode),Avant-propos 13
c’estsurtoutpourledéveloppementdenouveauxprogrammesqu’ilfautenvisagerde
systématisersesgains,entantqu’outild’appuipourlegénielogiciel.
Lesecondvolumecomporteleschapitressuivants.
II-1. Précision des analyses de programmes. Un bonspécialiseur est avanttout
un spécialiseur capable d’exploiterau mieux toutes les possibilités de spécialisation,
c’est-à-direcapabledepréexécuterun grandnombrede calculs,en
fonctiondesdon-
néespréalablementconnues.Encesens,c’estl’analysedetempsdeliaison,quis’ac-
compagneaussid’uneanalysed’aliasdanslecasdelangagesavecréférences,quifait
laforced’unspécialiseurhorsligne,carelledéterminelescalculsquipeuventounon
êtrepréexécutés.Nousétudionsdanscechapitrelaquestiondelaprécisiondecesanalyses. Nous détaillons unensemble de variantespossibles et expliquonsen quoielles
sont utiles ou non pour des problèmes pratiques. Nous comparons aussi la précision
dequelquesspécialiseursexistantsetévaluonsainsileurpouvoirdespécialisation.
II-2.Réification:delavaleurauterme. Puisnousconsidéronslaquestiondela
réification, qui se pose le problème de fabriquer du code exécutable pour une valeur
précalculée.Cette question,quiest
souventconsidéréecommeallantdesoicargénéralement simplifiée, est délicate à traiter si on la considère dans toute sa généralité.
Nous donnons des éléments de réponse, en fonction du partage d’accès et de la
mutabilité desdonnéesà réifier,etétudionségalementla possibilité departagephysique
de données entre moments d’exécution. Nous expliquons par ailleurs comment une
analysedetempsdeliaisonpeutgérerdesvaleursnonréifiables.
II-4. Exploitation de la spécialisation. Exploiter un programme spécialisé
consiste à l’employer là où l’on aurait normalementutilisé le programme générique.
Cettequestionest
elleaussisouventnégligéedanslalittératuredudomainecarappa-
remmentanodine.Ilexistepourtantplusieursmoyensd’employeruneroutinespécia-
lisée,plusoumoinssystématiques,chacunavecsesvariantes,etchacunavecsesavantages et inconvénients, qui peuvent varier en fonction du programme et des
circonstancesdel’exécution.Nouslesétudionsetcomparons,notammentencequiconcerne
lagestionefficaceetsûreduchoixderoutinespécialiséeàappeler.
II-3. Spécialisation de programmes incomplets. La spécialisation de
programmes incomplets désigne la possibilité de ne spécialiser qu’un fragment de
programme(typiquement,unmodule)plutôtqu’unprogrammecomplet.C’estunbesoin
extrêmement fréquent, et donc une fonctionnalité indispensable pour un spécialiseur
réaliste, bien que parfois traitée de façon assez sommaire. Pour cela, il faut
notamment pouvoir modéliser la partie du programme dans laquelle s’insère le fragment
à
spécialiser,ainsiquelesroutinesexternesappelées.Nousanalysonsicilesbesoinsde
modélisationdecodeetétudionslesavantagesetinconvénientsdelangagesdemodélisationexistants.Nousargumentonsenfaveurd’uneformedemodélisationbaséenon
passurdeslangagesabstraitsmaissurdesfragmentsdecodeconcrets.Cetteapproche
aétéimplémentéedansTempoetutiliséedanslaplupartdesesapplications.14 Ingénierie delaspécialisation-I
II-5.Spécialisationincrémentaleàl’exécution. Bienspécialiser,c’estaussi
exploiterauplustôtlesdonnéesdèsqu’ellessontdisponibles,demanièreàfactoriserun
maximumdecalculs.Ilfauttoutefoisprendreaussiencomptelecoûtéventueldecette
factorisation. Nous illustrons ce principe en montrant comment effectuer des
spécialisationsincrémentalesencoursd’exécution.Nousutilisonspourcelaunspécialiseur
standard (Tempo), que nous appliquons de manière itérée non pas à un programme
déjà spécialisé mais à un générateur de programmes spécialisés. Nous étudions et
comparonsplusgénéralementdifférentsmodèlesdespécialisationincrémentale.
II-6. Spécialisation de données. Il peut arriver que la spécialisation de
programmes produise du code volumineux, notamment lorsque des boucles sont
déroulées, et cela peut dégraderconsidérablementles performancesdu code spécialisé.
En
cecas,unevariantedelaspécialisationdeprogrammes,appeléespécialisationdedonnées,permetdemaîtrisercette«explosiondecode»toutenconservantlaplusgrande
partie des gains de spécialisation. Nous détaillons et caractérisons cette technique,
également en termes de points communs et de différences par rapport à la
spécialisation de programmes, et étudions aussi comment les deux approches peuvent être
combinées.Nousenfaisonsparailleursuneévaluationquantitative.
II-7. Perspectives scientifiques. Malgré les succès enregistrés, la spécialisation
n’est pas (encore?) devenue un élément standard de la boîte à outils du
programmeur. Nous cherchonsà comprendreles causes de ce succès mitigé et à identifier
les
obstaclesàuneutilisationpluslarge.Nousentironségalementdesperspectivesscientifiques,surlestechniquesdespécialisationmaisaussienlienaveclegénielogiciel.
II-8.Conclusion : dela théorie à la pratique.
Pourfinir,auregarddesperspectivesscientifiquesquinoussemblentlesplusprometteuses,nousabordonslaquestion
de l’industrialisation de la spécialisation. Nous discutons pour cela des limites de la
course à la performance et des difficultés générales qu’ont communément les
industriels pour adopter des technologies liées à l’ingénierie du logiciel, souvent
considérées comme non directement productives. Nous concluons en donnant malgré tout
notrevisiondestransfertspossibles.
Terminologie
Dans les domaines de recherche qui concernent la programmation en général, et
la spécialisation de programmes en particulier, peu de travaux sont rédigés en
français; la plus grande partie de la littérature est en anglais [MOG00]. J’ai autant que
possibleessayéd’adopteruneterminologiefrançaise,choisissantdesappellationsqui
semblaient suffisamment courantes, mais j’ai aussi parfois accepté quelques
anglicismes«reconnus».Danstousles cas,j’aimentionnéaussilaterminologieanglaise,
entre parenthèses. Les identifiants dans les exemples de programmessont également
enanglais,maislescommentairesdeprogrammessontenfrançais.Avant-propos 15
RendreàCésar
Celivrereprendetdéveloppeunepartiedemonmanuscritd’habilitationàdiriger
les recherches (HDR), excluant les chapitres sur les langages dédiés [MAR07]. Le
texte a été remaniéet substantiellement augmenté; certains chapitres ont été ajoutés,
d’autresprofondémentrestructurés.L’introductionetla conclusionontégalementété
réécrites,labibliographiecomplétée,etl’indexrationalisé.
Je remerciepourleurs commentairesles membresde monjuryd’habilitation,qui
ont essuyéles plâtres de la toute premièrerédactionde ce textesous sa formeHDR :
Jean-PierreBanâtre,PierreCointe,CharlesConsel,LaurentHascoët,MartinOdersky,
Jean-BernardStefani,avecunementionspécialepourOlivierDanvy,dontla sagacité
4généreuseetencyclopédiquen’estpasunelégende .(Ilvadesoiquelesimperfections
eterreursdanscelivrerestentdemonfait.)
C’estLaurentHascoët,avecquij’aipartagéunbureaulorsquenousfaisionspartie
5du projet CROAP que dirigeait Gilles Kahn à l’INRIA Sophia Antipolis, qui le
premier m’a dit que ce que j’essayais de faire dans mon coin avait un nom et s’appelait
«évaluationpartielle».C’estluiquim’amontrélavoie.
Mais c’est ensuiteà l’IRISA,quedirigeaitalorsJean-PierreBanâtre,quej’ai
réalisé la plus grande partie des travaux que je décris ici. C’est parce qu’il m’a fait
confiance que je peux être là où je suis aujourd’hui. Je souhaite à tout chercheur de
servirsousunedirectioncommelasienne:franche,bienveillante,éclairée.
6J’étaisalorsmembredel’équipeCompose ,dirigéeparCharlesConsel.C’estsans
contestelapersonneàquijedoisleplus.Savisionetsamanièredetravaillerontétéde
grandessourcesd’inspiration.Je remercieaussitoutceuxquiontfaitdeComposeun
environnement amical et particulièrement stimulant, et de Tempo une grande œuvre
collective,àcommencerparGillesMulleretJuliaLawall.Onnecomprendsachance
defairepartied’unetelleéquipequelorsqu’onn’yestplus.
4. Dans une étude de C. Lee Giles et Isaac G. Councill portant sur plus de 300.000 publications
scientifiques en informatique, parue dans les Proceedings of the National Academy of Sciences of the United
States of America (101(51) :17599-17604, 21 décembre 2004), Olivier Danvy est classé « the most
acknowledged individual ».
5. Figure éminente de l’informatique française, Gilles Kahn a disparu prématurément en 2006. Mon
manuscrit d’habilitation lui estdédié.
6. L’équipeComposeestdevenue plustardéquipePhoenix,aprèsundéménagement auLaBRI/INRIA
Bordeaux –Sud-Ouest en2000.16Chapitre1
Introduction:spécialiserpouradapter
Thereasonablemanadaptshimselftotheworld;
theunreasonableonepersistsintryingtoadapt
theworldtohimself.Thereforeallprogress
dependsontheunreasonableman.
—GeorgeBernardShaw,ManandSuperman
"MaximsforRevolutionists"
Bienquevirtuellementinusable,unprogrammeresteunobjetdeconsommation,et
l’industriedulogicielestsoumiseauxmêmescontrainteséconomiquesquelesautres
industries, y compris aux mêmes variabilités de demandeset de besoins. On pourrait
penser que le caractère immatériel des programmes conduise cependant à une
ingénierie radicalement différente; il n’en est rien. La rationalisation des processus de
productionsembleobéiràdesloisuniverselles.
Néanmoins, la maléabilité des programmes,tantôt codes exécutables,tantôt
données,donnelieuàdes procédésoriginaux,notammentdesprocédésd’adaptation,qui
n’ontpas d’équivalentailleurs dansl’industrie[DAN06a].C’est le cas enparticulier
de la spécialisation de programmes (aussi appelée évaluation partielle), qui permet
d’améliorerautomatiquementlaqualitédesprogrammesainsique,indirectement,leur
procédédeproductionetdemaintenance.
Ce chapitre d’introduction donne une vision très générale et non technique de la
spécialisationdeprogrammesetdeses apportspourl’industrieinformatique.
1718 Ingénierie delaspécialisation-I
Organisationduchapitre
– §1.1. Nous parcourons tout d’abord les principaux paramètres de production
économique du logiciel : qualité, coût et temps de production. Après une brève
descriptiondela spécialisation deprogrammes,nous indiquonscommentelle peutjouer
surchacundecesparamètres.
– §1.2. Nousexaminonsensuiteunedifficultésupplémentaire:gérerlavariabilité
des besoins. Cela conduit parfois au développement de lignes de produits, en
l’oc-
currence,defamillesdeprogrammes.Danscecaségalementlaspécialisationdeprogrammesproposedessolutions.
– §1.3. En fait, la réutilisation est au cœur de la plupart de ces questions. Nous
examinons plus particulièrement les moyens de la réutilisation de code (composants
et paramètres) ainsi que les compromis à trouver entre généricité et spécificité. La
spécialisationdeprogrammesévitecescompromis.
– §1.4. Enfin, c’est plus généralement une sorte de génie logiciel de
l’adaptation
quenousévoquons.Làencore,pourdifférentesstructurationsdel’adaptation,notammentpourlecasdeslangagesdédiés,laspécialisationdeprogrammesestprofitable.
1.1. Paramètresdeproductionetéquationéconomiquedulogiciel
Comme dans les autres domaines industriels, produire économiquement un
logi1ciel nécessitedetrouverunéquilibreentredeuxparamètresmajeurs:qualitéetcoût.
Dans certains contextes concurrentiels dynamiques, le temps de mise sur le marché
peutêtreprépondérant.Nouspassonsenrevuecesparamètresetindiquonsenquoila
spécialisationdeprogrammespeutavoirunimpactsurchacund’eux.
1.1.1. Qualitédulogiciel
Unlogicielad’aborddesqualités(positivesounégatives)quisont«extérieures»,
directementsensibles parl’utilisateur. Mais il a aussi des qualités « intérieures», qui
neconcernentqueleprogrammeur.
1.1.1.1. Qualitésextérieures
Un bon produit est avant tout un produit qui dispose de bonnes fonctionnalités.
De ce point de vue, la qualité du logiciel relève en premier lieu de l’étendue et de
1. En règle générale, on entend par logiciel un programme exécutable. Cependant, dans certains
domaines commeletraitement automatique deslangues (TAL),lavaleur et lacomplexité dulogiciel tiennent
plus souvent dans les données qui accompagnent le programme (lexique, grammaire, données collectées
par apprentissage statistique sur corpus, etc.) que dans le programme lui-même. Les données sont
égalementcapitales danslessystèmesexperts ainsiquedanscertains logiciels liésparexempleauxdomainesdu
spatial, dumédical oudel’information géographique.Introduction : spécialiserpour adapter 19
la pertinence des services offerts aux utilisateurs — qu’ils répondent à des besoins
avérés,oufabriquéspourl’occasion.
Mais la qualité concerne également des aspects dits non fonctionnels tels que la
performance(vitessed’exécution,taillemémoirerequiseparleprogramme,précision
des résultats des calculs, proximité de l’optimum, taille des problèmes qui peuvent
être traités, consommation électrique, etc.), la facilité d’intégration (interopérabilité,
respect des standards, etc.), la facilité voire le plaisir d’utilisation du produit
(simplicité, ergonomie,convivialité,etc.) ou les garanties de fonctionnement(temps réel,
sécurité,sûreté,fiabilité,toléranceauxpannes,etc.).
Certaines qualités, bien que non fonctionnelles, peuvent être primordiales. Par
exemple, dans certains domaines comme la météorologie ou les jeux vidéo, un
programmetroplentn’estpassimplementinconfortable;ilestenfaitinexploitable.Ilen
va de même d’une carte bancaire ou d’un passeport électronique qui n’est pas assez
sûr,d’unsystèmeaéronautiqueoudecontrôledecentralenucléairequin’estpasassez
fiable,d’unproduitgrandpublicquin’estpasassezconvivial,etc.
1.1.1.2. Spécialisationdeprogrammes
La spécialisation de programmes est une technique qui a pour objectif premier
d’améliorer certaines des qualités non fonctionnelles des programmes :
principalement la vitesse d’exécution, mais aussi, accessoirement, la taille des programmes,
voireleurconsommationélectrique.
Elles’intéressepourcelaàdescontextesd’utilisationparticuliersdesprogrammes,
par exemple lorsque certains des paramètres d’entrée sont fixés a priori. C’est pour
ces contextes d’utilisation particuliers, connus avant l’exécution même, que les
programmespeuventêtreaméliorés.
Plus précisément, étant donnés un programme et un contexte d’utilisation
particulier de ce programme,un spécialiseur (outil qui met en œuvre la spécialisation de
programmes) produit automatiquement un nouveau programme, appelé programme
spécialisé, qui est similaire au programme de départ mais où une bonne partie de
ce
quiestspécifiqueaucontexted’utilisationfixéaétéprécalculé.Pourcecontexted’uti-
lisationparticulier,leprogrammespécialiséalemêmecomportementfonctionnelque
leprogrammededépart,appeléparcomparaisonprogrammegénérique.
Commeilalesmêmeseffetsetproduitlesmêmesrésultats,leprogrammespécialisé a donc aussi les mêmes qualités fonctionnelles que le programme générique. La
plupart de ses autres qualités non fonctionnelles restent également inchangées :
précision, facilité d’utilisation, garanties de fonctionnement, etc. En particulier, la
spécialisation de programmesn’ajoute ni ne supprime de bogues puisque le programme
spécialiséauncomportementidentique.20 Ingénierie delaspécialisation-I
Enrevanche,commeilamoinsdecalculsàfaire,leprogrammespécialiséestplus
performant:ilestplusrapide,moinsgourmandenélectricité,etaprioripluspetit.(En
fait, commeexpliquédansla suite, la taille ducodepeutdans certainscas augmenter
pourcertainstypesdeprécalculs,maisceproblèmepeutêtrecontourné.)
1.1.1.3. Qualitésintérieures
Le développeurde logiciel est en outre confronté à des qualités plus intérieures :
2programmes faciles (ou non) à lire et à comprendre, à valider , à tester, à corriger, à
maintenir,àétendre,àfaireévoluer,àréutiliser,àporter,etc.Cespropriétéssontliées
àl’architectureduprogrammeainsiqu’austyleetàladisciplinedeprogrammation.
Laspécialisationdeprogrammesn’apasd’impactdirectsur cesqualitéscarc’est
leprogrammegénériquequeleprogrammeurcontinuedelire,d’écrireetdemettreau
point. Le programme spécialisé, généré automatiquement, n’a pas vocation à être lu
etencoremoinsmodifié.Laspécialisationn’estencesensqu’uneétapeintermédiaire
avantl’exécution,au mêmetitre quela compilation.(Entoute rigueur,il peutparfois
arriver qu’on veuille lire le code spécialisé dans certains cas de débogage ou pour
mieux comprendre la nature des optimisations, comme on peut lire parfois le code
machinegénéréparuncompilateur.)
En revanche, comme les qualités intérieures d’un programme sont la plupart du
temps dégradées lorsqu’on le modifie à la main pour le rendre plus rapide ou plus
petit,laspécialisationagitpourleurpréservation.Eneffet,ellepermetaudéveloppeur
d’écrire et de maintenir des programmes génériques peu performants, mais faciles à
lire, à valider, à étendre, etc. Et elle se charge d’en produire automatiquement des
versionsefficaces(spécialisées),destinéesuniquementàêtreexécutées.
En toute rigueur, il n’y a donc pas véritablement un gain en termes de qualité,
mais plutôt une non-dégradation.Cependant, dans la mesure où la recherche de
pro-
grammesplusrapidesestunproblèmerécurrentetquasisystématique,onpeutconsidérerquelaspécialisationapporteenpratiqueungainindirectmaistangibleencequi
concernelesqualitésintérieuresdesprogrammes.
1.1.2. Coûtdulogiciel
Lecoûtdulogicielportebienévidemmentsurlesdifférentestâchesquiconcourent
àsa production(classiquement:spécification,conception,développement,validation
ainsi qu’à sa maintenance et son évolution. Il est à noter que la maintenance peut
2. Certains auteurs distinguent lavérification (leproduit répond-il auxspécifications?)delavalidation
(le produit répond-il aux besoins?). Cependant, en pratique, la vérification et la validation sont souvent
confondues, ouprisel’une pourl’autre, aupointque certains préfèrent parler globalement de«vérification
et validation »(V&V),sansrentrer dansledétail. Poursimplifier, nousparlons uniquement devalidation.Introduction : spécialiserpour adapter 21
parfois compter jusqu’à la moitié du coût total, ce qui appelle à une prise en compte
3de l’ensemble du cycle de vie d’un logiciel pour en évaluer son coût véritable . Ces
diverses tâches requièrentdes compétences et des niveaux d’expertise différents, qui
pondèrentlecoûttotal.
À ces coûts de production « brute » s’ajoutent aussi parfois des coûts liés à la
4 5propriété intellectuelle et au risque , ainsi que les coûts de distribution, c’est-à-dire
6 7dereproduction etdetransport .
Orlelogicielfaitpartied’unecatégoriedeproduitssinguliers:réaliserlepremier
exemplaireesttrèscoûteux,maisenfabriquerdenouveaux(dupliquerleprogramme)
8necoûtequasimentrien .Defait,l’industrielogicielleestuneindustriequin’exploite
pas véritablement de matière première (autre que la matière grise), et la diffusion de
3. Cela inclut également sa « bonne disparition » en fin de vie, notamment en prenant en compte une
éventuelle migration des données versdenouvelles solutions.
4. Ces coûts incluent notamment celui de licences logicielles pour l’utilisation de composants tierces,
le paiement de droits d’exploitation de brevets, ou des efforts de recherche pour contourner des brevets
bloquants. Lemouvement dulogiciel libre suscite toutefois unchangement depoint devue significatif.
5. Danslecasdelogicielscritiques,lorsquelerisqueestimportant(financier,humain,écologique, etc.),
les coûts de production, d’exploitation et de maintenance peuvent également s’accompagner de primes
d’assurances (ou de provisions) contre les conséquences d’une défaillance. C’est un poste à part entière,
qu’on équilibre avec la part d’effort que l’on place dans les garanties de fonctionnement. Dans l’édition
logicielle, la pratique est toutefois defaire porter lerisque par leclient au travers delicences d’utilisation.
6. Lorsqu’un logiciel est fourni sur un support matériel, c’est typiquement sur un CD-ROM ou dans
la mémoire d’un système embarqué, qui ont des coûts de fabrication extrêmement faibles. En effet, pressé
en grande quantité, entre 10000 et 100000 exemplaires, un CD-ROM en polycarbonate coûte en 2010
autour de20centimes —moinscher que samiseenemballage. Pour depetites quantités (quelques centaines
d’exemplaires), il vaut mieux avoir recours au procédé de gravure de CD-R, plus économique que le
pressage car il ne nécessite pas la coûteuse création préalable d’un disque matrice (glass master); un disque
gravé revient dans ce cas autour d’un euro pièce. En ce qui concerne les programmes résidents dans les
systèmes embarqués (consoles de jeux, assistants personnels (PDA), imprimantes, lecteurs de DVD,
ordinateurs de bord, etc.), le coût de leur implantation en mémoire morte (ROM) ou persistante (EEPROM,
Flash)estégalement del’ordre del’euro, avecdesvariations enfonctiondelataille mémoire, desquantités
produites et des personnalisations éventuelles. Ce coût est souvent modique comparé à celui du reste du
matériel, sauftoutefois lorsque ce matériel est extrêmement réduit, commedans lecas descartes àpuce.
7. Le coût de transport est infinitésimal dans le cas d’un téléchargement, et minime pour le cas d’un
support physique. UnCD-ROMoudela mémoiresurunepuce sonteneffet légers, petits, résistants etnon
périssables. Ce faible coût, combiné à la facilité d’effectuer desmisesà jour (pourla correction de bogues,
le colmatage de failles de sécurité ou l’évolution de fonctionnalités), y compris pour des appareils plus
passifs tels que des téléviseurs, permet également une meilleure gestion du risque de mise sur le marché
d’un produit défectueux ou inadapté. Seuls les systèmes embarqués autonomes dans lesquels le logiciel
réside uniquement en mémoiremorte peuvent nécessiter unrappel pluslourd.
8. Certaines productions écrites, graphiques, audio et audiovisuelles, qui tendent également àse
dématérialiseretquiutilisentlesmêmesvecteursdediffusionquelelogiciel,sontdecepointdevuecomparables.
L’industrie pharmaceutique a elle aussi des coûts de recherche et de développement extrêmement élevés,
alors quela fabrication de médicaments asouvent uncoût marginal presque nul.22 Ingénierie delaspécialisation-I
9logicielspartéléchargementenaccentueencorela dématérialisation . Laseule borne
concrèteàlareproductiondelogiciel(productiondeplusieursexemplairesd’unmême
logiciel)estunebornepratique:c’estlenombredemachinescapabledelesexécuter.
Par ailleurs, dans le cas des systèmes embarqués, notamment autonomes, le coût
et la qualité du logiciel ne se conçoivent que globalement, en relation avec le coût
et la qualité du matériel associé. Par exemple, réorganiser les calculs peut permettre
deréduirelaconsommationélectriqueetdonclesbesoinsd’autonomiedelabatterie.
De même,réduirela taille des programmeset des donnéespermetde réduirela taille
mémoire matérielle nécessaire, importante source de coût dans le cas par exemple
descartesà puce.Alternativement,à taillemémoireégale,unetelle réductionpermet
d’offrirdavantagedefonctionnalitésouuneplusgrandecapacitédetraitement.
La spécialisation de programmes joue indirectement sur le coût du logiciel dans
la mesure où,grâceà son caractèreautomatisé,elle peut éviter,à qualités extérieures
égales, de faire des développements spécifiques pour accroître la vitesse d’un
programmeoupourenréduirelataille.Deplus,grâceauxqualitésintérieurespréservées
(cf.§1.1.1),elleréduitaussilecoûtsurlelongtermeenpermettantlamaintenanceet
l’évolutiond’uncodeplussimple.
1.1.3. Tempsdeproduction
Outrela qualitéet le coût,untroisièmeparamètrepeutêtre
déterminantdanscertaines circonstances : le temps de mise sur le marché (time to market). En effet, en
pénétrantlesproduitsetservicesdegrandeconsommation,l’industriedulogiciels’est
vuimposerunrythmequ’ellepeineparfoisàsuivre—sil’onenjugenotammentpar
lafragilitédecertainsproduitsmisprématurémentsurlemarché.
Dans des contextes très concurrentiels, la stratégie des entreprises est en effet de
rapidement prendre des parts sur les marchés émergents puis, une fois ces marchés
établis, de proposer fréquemment de nouveaux produits et services pour générer de
nouveaux revenus, conquérir de nouvelles parts, ou simplement préserver leur
posi10tion.Ilpeutdoncêtrecruciald’avoiruntempsdeproduction aussibrefquepossible.
9. Selon Apple, en septembre 2010, de l’ordre de dix-huit millions d’applications étaient chaque jour
téléchargées sur l’App Store, parmi un choix de plus de 250.000. En janvier 2011, le cap des 10 milliards
detéléchargements au total estatteint. Enmai2011, le choix dépasse les500.000 applications.
10. Par temps de production nous entendons ici le temps de réalisation du premier exemplaire d’un
programme, car la production de copies est non seulement quasi gratuite (voir note de bas de page n°6,
p. 21) mais également quasi instantanée, par comparaison à la durée des autres tâches liées au logiciel.
C’est bien sûr le cas pour les procédés dématérialisés : le temps de téléchargement d’un logiciel va de
quelques millisecondes ousecondesàquelques minutes. Maismêmepourlesprocédés matériels, lesdélais
sont relativement brefs. Ainsi, après création d’un disque matrice, en quelques heures ou quelques jours,
la cadence de fabrication d’un CD-ROM est hors du commun pour un produit de cette complexité : uneIntroduction : spécialiserpour adapter 23
Du fait de son caractère automatique, la spécialisation de programmes altère peu
ou pas le temps de mise sur le marché. Plus précisément,dans l’état actuel des
techniquesetdesméthodologies,lamiseenplaced’unprocessusdespécialisationefficace
peutparfoisdemanderunpeudetempsàl’échelledela productiond’unprogramme,
maislagénérationmêmed’unprogrammespécialiséperformantestquasiinstantanée.
Maisd’uncertainpointdevue,onpeutmalgrétoutconsidérerquelaspécialisation
deprogrammesréduitaussiletempsdeproductiondesprogrammes:commeilssont
plussimples,ilssontaussiplusfacilesàconcevoir,àdévelopper,àvalider,àréutiliser
etàfaireévoluer.
1.1.4. Équationéconomiqueetgénielogiciel
11Produirevite,àbascoût,avecunequalitéminimum
:telleestl’équationéconomique universelle,que l’industrie du logiciel se doit égalementde résoudre.Certains
paramètrespeuventêtre fixés,commele seuil de qualitéminimumoula limite
maximum de prix pour qu’un produit se vende sur le marché visé, les autres paramètres
étantà optimiser.Entoutétatdecause,qualités’opposeà coûtetà
tempsdeproduction:améliorerl’undégradel’autre.
Certains critères de qualité peuvent également être contradictoires entre eux. En
12particulier,commeindiquéci-dessus,les optimisations quivisentà
améliorerlavitesse
d’exécutiond’unprogrammealtèrentgénéralementsonécritureetsonarchitec-
ture,etdétériorentparlàmêmed’autresqualitéstellesquelamodularité,laportabilité,
lalisibilité,lafacilitédevalidation,lafacilitédemaintenanceetd’évolution,lafacilité
deréutilisation,etc.Enoutre,ladifficultédemettreenœuvrecesoptimisations(opérationquiresteprincipalementmanuelle)favoriseégalementl’introductioninaperçue
deboguesetdevariantesdecomportementinvolontairesdanslecode,cequiaffaiblit
d’autantlesgarantiesdebonfonctionnementdulogiciel.
Afin de maîtriser tous ces paramètres,le génie logiciel s’efforcede rationaliser le
processusdeproductiondesprogrammes:étudedesbesoins,réalisationpréalablede
seule presse à injecter peut sortir un CD-ROM toutes les 3 secondes, soit plusieurs dizaines de milliers
par jour. Pour de plus petits volumes, de l’ordre de quelques centaines d’exemplaires, on a recours à la
gravure de CD-R, qui ne nécessite pas la création préalable d’une matrice. Elle demande une dizaine de
minutes par pièce et est généralement effectuée en parallèle sur plusieurs graveurs. En ce qui concerne les
systèmesembarqués,l’écrituresurmémoirepersistantevarietypiquementdequelquescentainesàplusieurs
millions d’octets àlasecondesuivant latechnologie utilisée (EEPROMordinaire, mémoireFlash).Quantà
la fabrication de mémoiresmortes, la programmation de quelques milliers d’EPROMdemande enpratique
unjouroudeux,etilfautallerjusqu’àunedizainedejoursenpratiquepourlaproductiondeROMmasquée.
11. Qualité minimum au sens d’au moins un certain niveau fixé — que ce niveau soit faible ou élevé au
regard d’une certaine échelle de référence.
12. Nous employons le terme d’optimisation dans le sens courant d’amélioration de performance. Le
résultat d’une «optimisation »n’est généralement pas optimal enunquelconque sens.24 Ingénierie delaspécialisation-I
spécifications et de prototypes, planification des délais et des coûts, organisation du
travail collectif, mise en œuvre de méthodes et d’outils pour le développement et le
contrôledelaqualité,etc.
Dans ce paysage, la spécialisation de programmes n’est pas juste une «
moulinette » à rendre les programmes plus efficaces. Il faut la voir dans un cadre plus
général. Elle a bien sûr sa place dans la boîte à outils du développeur, mais elle vient
égalementenappuideméthodologiesdegénielogiciel.
1.2. Variabilitéetlignesdeproduits
À ces paramètres de production s’ajoute une difficulté supplémentaire, qui n’est
pas spécifique au logiciel mais qui est particulièrement marquée dans ce domaine :
la diversitédesdemandes.Surce plan-làégalement,la spécialisationde programmes
apportedessolutions.
1.2.1. Variabilité
Les besoins des utilisateurs sont extrêmementvariés : usage généralou
dédié,intensif ou occasionnel, fixe ou embarqué, local ou distribué, interactif ou différé,
critique ou de confort, fermé ou ouvert, sans compter les demandes pour de multiples
possibilitésdepersonnalisationdecomportementetd’apparence.Ilyaégalementune
grande variété dans les plates-formes d’exécution du fait de l’hétérogénéité des
machines et des systèmes d’exploitation. Mais produire davantage de variantes allonge
etrendpluscomplexeslesprocessusdeproductionetdegestiondelaqualité,etdonc
augmenteaussilecoûtetletempsdeproduction.
Surcette question,l’exemplesuivant,citédans lemagazineCapital(N°187,avril
2007),est particulièrementfrappant.Gameloft,numéro2 mondialdes jeuxvidéosur
téléphones mobiles, adapte chacun de ses jeux pour qu’il fonctionne sur tous les
téléphonesdu marché,ce qui représentait en 2007près de 800 versionsdifférentes.Ce
travaildetitanmobiliseàluiseullestroisquartsdel’entreprise(2700salariés).Alors
que la création d’un jeu prend de six mois à un an, cette phase d’adaptation
nécessite deuxmois supplémentaireset engloutitjusqu’à90% ducoût de développement:
autourde800000euros.
Cette variabilitéatoujoursexisté,ainsiquedesmoyenspourrépondreàcertaines
variations. Les systèmes d’exploitation,par exemple, n’ont pas comme seul objet de
fournirdesabstractionsdehautniveaupourexploiterlesressourcesd’uneplate-forme
matérielle;ilsconstituentégalementunecouched’abstractionquiisoleetquimasque
certaines hétérogénéités afin qu’un même programme, portable, puisse fonctionner
de manière plus ou moins transparente sur des machines différentes. Les intergicielsIntroduction : spécialiserpour adapter 25
(middleware) font de même sur un autre plan en simplifiant l’écriture des
communicationsentreplusieursapplications,ainsirenduesinteropérables.
Pourtant, jusqu’à récemment encore, l’industrie du logiciel raisonnait
principalement en terme de produits individuels spécifiques : un programme, puis un autre,
tentaient de satisfaire (oude créer)les besoins variés et évolutifs d’unmarché,d’une
entreprise.Mêmesil’onpratiquaitdéjàlaréutilisationdecode,biensûr,c’étaitencore
relativementoccasionnel et opportuniste.L’objectif principal que se donnait le génie
logiciel était le bon développementd’un programmeunique, solution à un problème
bien posé, généralement énoncé dans un cahier des charges rigide, lors d’une phase
préliminairededéfinitiondesbesoins.
En fait, si cette variabilité est effectivement ancienne, son ampleur et son poids
sontenrevanchedesphénomènesrelativementrécents,apparusnotammentdufaitde
lamultiplicationetdeladiversificationdesplates-formesd’exécution.Cepoidsdela
variabilitéestégalementlefruitd’unetendancecommercialeplusgénéraleconsistant
àoffrirdesproduitsetdesservicesplussegmentésetdavantagepersonnalisés.
L’ingénieur logiciel doit s’interroger sur les méthodes et les instruments dont il
peutdisposerpourmaîtrisercettevariabilité.
1.2.2. Familledeprogrammes
Identifierl’importancede la variabilité et vouloiry répondre,c’est d’unecertaine
manièredéjàl’intégrercommeparamètredeproductiondansl’équationéconomique.
Celle-ci devient alors : produire vite, à bas coût, une variété de produits, avec
une
qualitéminimum.Lechangementdeperspectiveestconséquent:l’objetn’estplusun
produitunique,maisunegammedeproduits,quiontcecideparticulierqu’ilsontdes
traitscommuns.
Cestraitscommunsappellentnaturellementàunpartage:danslecasdugénielogiciel,principalementunpartagedecode,doncaussi deconception,d’architectureet
de maintenance, mais égalementun partage de validation et de connaissances.
Comparéeàlaproductionindépendantedechaqueproduit,laréutilisationdeceséléments
partagés permet d’espérer une réduction du coût et du temps de réalisation des
produits (moins de développements) sans perte de qualité (capitalisation sur la qualité
éprouvéedes parties communes).Un des objetsdu génielogicielest de fairede cette
réutilisation non pas quelquechose d’accidentel,mais une pratique organisée— une
sortedegénielogicieldelaréutilisation.
Ainsi,depuisuncertainnombred’annéess’estpeuàpeuimposéel’idée,aumoins
dans certains secteurs, de concevoir d’emblée de véritables familles de produits
(ou
lignesdeproduits),aulieud’unéparpillementdeproduits,dérivésplusoumoinsfortuitement les uns des autres. Dans ce contexte, le génie logiciel se doit désormais26 Ingénierie delaspécialisation-I
d’envisager le développement de familles de programmes (ou de composants
logiciels). En pratique,ces familles sont souvent « ouvertes» car évolutives : on connaît
plus ou moins leur premiers membres, mais l’étendue exacte de la famille n’est
pas
bornée.
L’idéen’estpasneuve[PAR76],maisn’avraimentprissonessorquedanslesannées1990.L’industrielogiciellen’enpoursuitpasmoinslàunparallèleavecd’autres
secteursindustriels,oùl’onsait
depuislongtempsrépondreviteetefficacementàdes
gammesdebesoinsspécifiquesetévolutifsgrâceàlaréutilisationdecomposantsstandardsetdelignesd’assemblageadaptables,plusoumoinsautomatisées[CZA00].
13Ilfautnoterquece«nouvel»objectifdugénielogiciel ,oucegénielogicieldes
familles de programmes, suppose des capacités d’investissement. En effet,
envisager
unelignedeproduitsetréaliserdescomposantssusceptiblesd’êtreréutilisésestinitia-
lementpluscoûteux.Uneentreprisequiamorceunefamilledeprogrammesenproduisant un premier membre de cette famille (ou un petit nombre de premiers membres)
doit donc avoir la capacité de se projeter sur les membres suivants : elle accepte le
coût supplémentaire que représente l’organisation d’une hypothétique
réutilisation
dansl’espoird’unerentabilisationfuture,lorsdelaproductiondenouveauxmembres.
Touteslesentreprisesneprennentpascegenrederisque;ellessontmêmeenfaitsouventfrileusessurlesinvestissementsliésaugénielogiciel(voiraussiII-§8.3).
Des solutions concrètes ont néanmoins été proposées au problème du
développement des familles de programmes. En particulier, les générateurs d’applications
offrent des cadres ou environnements d’assemblage (frameworks) où se
combinent
automatiquementdesfragmentsdecodeplusoumoinsfigésenfonctiondedirectives
decompositiondonnées.Certainscadresd’assemblagevisentenparticulierlagénération de codespécifiqueadaptéà diversesplates-formesd’exécution,notammentavec
desappelsàdesbibliothèquesdifférentes.
13. Il faut aussi noter qu’envisager ainsi le développement de familles de programmes n’est que le
prolongement d’une vue relativement traditionnelle du génie logiciel. Une approche plus récente comme la
programmation extrême (extreme programming, XP) [BEC04] considère la réutilisation non pas comme
une question a priori mais plutôt comme un épiphénomène a posteriori : c’est au cours de développements
nouveaux que sont identifiés des similitudes et, uniquement alors, via un remaniement de code
(réingénierie, refactoring), qu’une mise en commun est effectuée. L’avantage est qu’on ne crée pas de composant
inutile (employé zéro ou une fois). L’inconvénient est qu’on doit passer du temps supplémentaire à
extraire un code générique à partir d’un premier usage spécifique. Un autre inconvénient à l’absence d’une
étude préalable focalisée sur les points communs est que des similitudes peuvent rester inaperçues du fait
du manque de vision globale sur le code. Le « pari » néanmoins de la programmation extrême est que, en
pratique, le bilan global de cette stratégie est positif. En fait, la programmation extrême remet en cause
quantité d’autresprincipestraditionnels dugénielogiciel etlesétudesactuelles nepermettent pasdestatuer
sur la question particulière de la réutilisation. La réponse n’est d’ailleurs probablement pas catégorique,
mais dépend du type d’applications. Malgré cette différence radicale de point de vue, une grande partie de
ce que nous présentons dans ce livre reste néanmoins pertinent dans le cas de la programmation extrême
(voiraussi §7.5.2).Introduction : spécialiserpour adapter 27
Laspécialisationdeprogrammespeutjouerunrôleprépondérantdanscecontexte.
On peut en effet développer (et maintenir, faire évoluer) un programme chapeau
unique qui recouvre la totalité de la famille de programmes, chaque membre étant
représenté par un jeu de paramètres particulier du programme chapeau. Un membre
peut ensuite être individualisé (produit) automatiquement par spécialisation du
programme chapeau en fixant le jeu de paramètres qui caractérisent ce membre
particulier. Cette approche a l’avantage de permettre une grande réutilisation du code, mais
aussiuneréutilisationdesméthodologiesetoutilsdedéveloppementordinaires(pour
ledéveloppementduprogrammechapeau).
Le point capital est que le programme chapeau (programme générique) n’a pas
nécessairement à être très efficace. Ce qui importe, c’est qu’il soit bien conçu, qu’il
couvre tous les besoins de la famille de programmes, et qu’il puisse être facilement
étendupourfaciliter l’arrivéedenouveauxmembresimprévus.Les questionsde
performance incombent ici à un processus automatique (supposé sûr) plutôt qu’au
développeur (supposé faillible). La vitesse d’exécution en particulier ne se gagne plus
alorsauxdépensdelaqualitédel’écritureetdel’architectureduprogramme;elleest
obtenueautomatiquement,àcoûtréduit.
1.3. Réutilisation
Sansmêmefairel’analyseentermesdevariabilitéetdelignesdeproduits,onpeut
constater que, sauf exception (pures innovations),la part du réellement neuf dans un
nouveauproduitestsouventmodeste;elleestégalementmodérémentprévisible.Pour
répondreviteetàmoindrecoûtàladiversitédesdemandesd’unmarchéenévolution,
c’estdoncsurlacapacitéderecyclagedel’ancienquedoitporterl’effort,aveccomme
guidel’expériencedudomaineetlestendancesvisiblesdumarché.
Laréutilisationestenfaitpossible—etavantageuse—pourlaplupartdestâches
qui concernent le développement logiciel, de la conception jusqu’à la maintenance
évolutive:réutilisationdeconnaissances,d’architectures,detests, etc.Dansles faits,
laréutilisationse matérialisetoutefoislaplupartdutempssousformederéutilisation
decode.
Il est importantde noter que le gain de la réutilisation ne concernepas seulement
l’économiedu coût de production,en évitant les redéveloppements.En effet, chaque
réutilisation renforce aussi la suivante, en offrant à chaque fois des composants plus
aguerris,de meilleurequalité. En particulier,dans la mesure où les
composantsexistants ont déjà fait l’objet d’une optimisation et d’une validation, et surtout ont été
mis à l’épreuve du terrain, la réutilisation améliore également la performance et les
garantiesdefonctionnement.28 Ingénierie delaspécialisation-I
1.3.1. Lesmoyensdela réutilisationdecode
Pour réutiliser du code, il est nécessaire d’avoir identifié des fonctionnalités et
traits récurrents, de les avoir factorisés sous forme de schémas de programmation et
de composants réutilisables, et d’architecturer les programmes sur la base d’un
assemblagedecescomposants.Enoutre,pourpermettreunforttauxderéutilisation,on
chercheaussiàdévelopperdescomposantsplusgénéraux,paramétrables,conçuspour
s’appliqueretfonctionnerdansungrandnombredecirconstances.Laréutilisationde
code s’articule ainsi autourde deux concepts relativementindépendants: composant
etparamètre.Unebonneréutilisationjouesurlesdeuxplans.
1.3.1.1. Composants
Les composants logiciels sont des fragments de code préexistants que l’on inclut
dans le code spécifique d’un nouveau programme à réaliser. Les formes en sont
variables, selon la granularité de ces fragments (de quelques lignes de code à de larges
portionsdeprogrammes)etdeleurmoded’inclusiondanslenouveauprogramme.
Historiquement, les langages de programmationont tout d’abord permis d’écrire
desroutinesindividuelles,appelablesdepuisn’importequelendroitducode,puisdes
bibliothèquesdetellesroutines,avantquelegénielogicieldelaréutilisationorganise
la production de véritables composants réutilisables, non seulement dans un
même
programmemaisaussietsurtoutentreprogrammesdifférents.
Unpasimportantpourl’essordelanotiondecomposantaétédereconnaîtreque,
dansbonnombredecas,ilvalaitmieuxorganiserunsystèmeautourdesdonnéesplutôtqu’autourdesfonctions,etced’autantplusquelesdonnéessontcomplexes:c’est
l’apportdelaprogrammationorientéeobjet(object-orientedprogramming,OOP).
Par ailleurs, la reconnaissance de patrons de conception (design patterns)
récurrents dans le code, moins locaux et à grain plus fin que celui d’une procédure ou
d’un composant ordinaire, a permis un partage du savoir-faire à défaut d’un partage
decode[GAM95].
La programmation par aspects (aspect-oriented programming, AOP) s’est quant
à elle affranchie de la contrainte d’atomicité des briques logicielles : le code d’un
composant, au lieu d’être un tout compact localisé, peut désormais être dispersé
automatiquement à travers le code de tout un programme afin de rendre des services
transversaux,enparticulierpourajouterdestraitsnonfonctionnels[FIL04].
1.3.1.2. Paramètres
Les paramètres d’un composant sont des données que l’on peut faire varier pour
déterminerlecomportementducomposantàl’exécution.Introduction : spécialiserpour adapter 29
La dimension temporelle de la variation (le moment de la variation) est
importante ici. Certains paramètres peuvent être fixés une fois pour toutes, à l’écriture du
nouveau programme, lorsque le composant est intégré. Ils font alors office de
configuration pour une instance particulière du composant. D’autres paramètres peuvent
varier à l’exécution (arguments de routines, variables d’état du composant) et en ce
cas conditionnerun comportementdépendantdu contexte d’utilisation particulier du
composantdansleprogramme.
Plusuncomposantadeparamètres,plusilestgénérique,etdoncréutilisabledans
descirconstancesdifférentes.Inversement,moinsiladeparamètres,plusilest
spécifique,etplusilestrestreint(maisapproprié)pourunusagedéterminé.
Lescaractèresopposésdegénéricitéetdespécificité,ontchacunleursavantageset
leursinconvénients.Commeexpliquédanslasuite,cetteantinomiepeutêtredépassée
grâce à la spécialisation de programmes, qui donne des moyens pour bénéficier des
avantagesdechaqueorientationsansensubirlesinconvénientsrespectifs.
1.3.2.
Spécificitévsgénéricité
Onasouventlechoixentreréaliserunemultiplicitédecomposantsspécifiquesqui,
chacun,remplissentunefonctiondifférente,oubienréaliseruncomposantgénérique,
objetuniquemaisparamétrable(oudontchaqueinstanceestparamétrable)etcapable
deremplirl’ensembledecesfonctions.Danslepremiercas,réutiliserunefonctionnalitérevientàréemployerunouplusieurscomposantsparticuliers;danslesecondcas,
cela consiste à réemployer le même composant générique, paramétré différemment
pourchaqueinstance,suivantlafonctionnalitévisée.
Ce sont là deux antipodes entre lesquels ils ne faut pas choisir mais qu’il faut au
contrairetenterd’équilibrer.
1.3.2.1. Inconvénientsd’unetropgrandespécificité
En effet, si l’on veut trop multiplier le nombre de composants, on est conduit à
fragmenter les fonctionnalités, ce qui réduit le niveau d’abstraction et augmente le
nombre de réutilisations à organiser et à réaliser. La tâche du développeur est de ce
faitplusdifficile(recherchedesbonscomposantsàréutiliser),pluslongueetsujetteà
erreur(multiplicitédes instances deréutilisations)et plus
hasardeuse(risqued’omissions de réutilisations possibles). Les méthodologies de développement logiciel sont
encore de peu d’aide sur ces questions. En particulier, elles ne garantissent pas une
réutilisation maximale des composants; la réutilisation est le plus souvent laissée au
bonvouloirouàl’expérienceduprogrammeur.
Dans le cas extrême de composants très petits et nombreux,une trop
grandespécificité peut égalementêtre nuisible pour la performance.En effet, toute réutilisation30 Ingénierie delaspécialisation-I
d’uncomposantnécessiteaussiducodespécifiqueafindemettreenœuvrel’instance
particulière visée; s’il y en a beaucoup,cela peut augmenterla taille du programme.
Par ailleurs, un composant est typiquement employé via un appel de fonction ou
de
méthode,auquels’ajoutelepositionnementdeparamètres;celapeutaugmenterd’autantletempsd’exécution.
Sil’onveutaucontraireéviterdetropmorcelerlesfonctionnalitésetconserverun
niveaud’abstractionélevé,touten offrantdes composantsspécifiques,onest conduit
à limiter le partage et donc à se priver de possibilités de réutilisation. Cette question
est liée également à la nature récursive du problème du partage : un composant peut
lui-mêmeêtreconstruitàl’aidede(sous-)composantsréutilisables.
1.3.2.2.
Inconvénientsd’unetropgrandegénéricité
Inversement,unetropgrandemultiplicationdesparamètresd’uncomposantgénérique ou des paramètres trop complexes réduisent également le niveau d’abstraction.
Latâchedudéveloppeurestdanscecas plusdifficile(recherchedesbonsparamètres
deconfiguration)etsujetteàerreur(complexitédelaconfiguration).Descomposants
excessivementparamétrablespeuventdevenirinutilisablescartropcomplexesoutrop
nombreux.Certainesbibliothèquessontd’ailleursparfoissous-exploitées,c’est-à-dire
réduitesseulement,dansl’usagecourant,àunsous-ensemblepraticable.
De plus, une trop grande généricité nuit aussi à la performanceen augmentant
le
tempsd’exécutionetlatailledesprogrammes.Eneffet,unepartiedutempsd’exécutiond’uncomposantgénériqueestconsacréeautraitementdesparamètres,plutôtqu’à
laréalisationdesfonctionnalitésmême.Deplus,leprogrammerésultantpeutcontenir
du code mort (toujours inexécuté, quelles que soient les circonstances) car tous les
casdefonctionnementd’uncomposantgénériquenesontpasforcémentutilesdansle
contexted’uneconfigurationparticulièredonnée.
En revanche,le partageque
contientl’implémentationmêmed’uncomposantgénérique est d’une certaine manière systématique, fourni par construction, alors qu’il
est de la responsabilité du programmeurdans le cas d’un assemblage de composants
spécifiques.
1.4. Génielogicieldel’adaptation
Cequisedessineauvudecequiprécède,cen’estpasseulementungénielogiciel
dela réutilisation,voireungénielogicieldes familles deprogrammes,mais un génie
logicieldel’adaptation.
Eneffet,il nes’agitpasseulementd’organiser,destructurer,defavoriserla
réutilisation. Il faut aussi pouvoir offrir des possibilités et des choix de réutilisation qui
sont pertinents en fonction de la variation des besoins et des contextes d’exécution.
Autrementdit,ilfautaussiorganiser,structureretfavoriserl’adaptation.Introduction : spécialiserpour adapter 31
1.4.1. Langagesdespécificationdel’adaptation
La spécialisation de programmes offre un cadre où le processus d’adaptationest
écrit dans le programmemême (le programmegénérique),et surtout avec les mêmes
termes:mêmelangagedeprogrammation,mêmecode,mêmedonnées.Danscecadre,
les alternatives de comportementdu programmegénériquesont autant d’expressions
de l’adaptation,qui disparaissentaprès spécialisation. L’avantageest de permettreau
programmeur de rester dans le même monde (qu’il connaît bien), et aussi de
faciliter des transitions douce entre des systèmes monolithiques rigides et des systèmes
modulairesadaptatifs(réécritureprogressive).
Mais le processus d’adaptation, s’il n’est pas restreint aux seules
recommandations d’une méthodologie de développement mais accompagné d’outils spécifiques,
peut alors aussi être exprimédans des termes propres,autres que ceux du langagede
programmation. En particulier, il peut être spécifié à l’aide d’un langage formel ad
hoc, conçuspécifiquementpourexprimerl’adaptation[BOI00]. L’avantageest alors
de disposerde directivesd’adaptationspécifiques, limitées car conçueexclusivement
pour cette problématique, mais inversement particulièrement appropriées pour cette
usage.
Cela peut permettre notamment de mieux raisonner sur l’adaptation, en tant que
développeur,voire de vérifier automatiquementla cohérencedes
directivesd’adaptation et de systématiser des optimisations d’adaptationqu’il serait impossible de faire
(pour des questions d’indécidabilité) avec une adaptation exprimée dans les mêmes
termesqueleprogramme.
1.4.2. Langagesdédiés
La notion de langage dédié pousse encore plus loin ces idées en donnant un
véritable statut de langage aux directives d’adaptation et en encapsulant totalement la
réutilisationausenslarge[MAR07].
Les langagesdédiés (domain-specificlanguages, DSL) sont des langagesde
spécificationoudeslangagesdeprogrammationdetrèshautniveaucibléssurundomaine
et/ouunproblèmeparticulier.D’ordinaire,les langagesdédiés n’ontpas la puissance
d’expression des langages généralistes « à tout faire » comme C ou Java. Mais ce
qu’ilsperdentengénéralité,ilslegagnentenspécificitéetenpouvoirprédictif.
Ilsapportentuneréponseàlaquestiondel’interfaçaged’applicationscomplexes:
configuration et paramétrisation deviennent programmation dans le langage dédié.
Dans ce cadre, un paramètre complexe est exprimé comme un programme du
langagedédié, objet structuré qui décrit le comportementattendu de l’applicationou du
composantgénérique.32 Ingénierie delaspécialisation-I
Grâce à leur adéquation avec la classe de problèmes visée, les langages dédiés
conduisent à des gains de productivité, avec des temps de développementraccourcis
(code à écrire parfois divisé par dix). Comme les termes du langage sont basés sur
des abstractions et un vocabulaire issus du domaine concerné, donc avec ici aussi
uneréutilisationdeconnaissances,cesdéveloppementspeuventêtreeffectuéspardes
non-experts,doncàmoindrecoût,voirepardesnon-programmeurs.
Commeilssontrestreints,leslangagesdédiéspeuventaussioffrirdesgarantiesde
fonctionnementqui sont d’ordinaireimpossibles à obtenir avec des langages
généralistes(toujourspourdesquestionsd’indécidabilité).Toujoursgrâceaucadrerestreint,
l’implémentationdes langagesdédiés peutégalementoffrirdes
garantiesd’optimisationquiseraitinaccessibleàuncompilateurouunoptimiseurdelangagegénéraliste.
Enfin, les langages dédiés organisent complètement la réutilisation de code : ils
l’automatisent et la systématisent. Cela peut inclure également des schémas de
programmationquicorrespondentplusàdes«idiomes»d’unlangagedeprogrammation
(ou d’une classe de langages) qu’à des fonctionnalités véritables qu’on peut isoler.
On a ainsi la possibilité de réutiliser des fragmentsde code qu’on ne pourrait,sinon,
encapsulerdansuncomposantpourenréutiliserlecode.
Dans ce contexte aussi la spécialisation de programmes a encore son mot à dire.
Elle peut en effet être utilisée pour implémenter efficacement des compilateurs
de
langagedédiéàpartird’unsimpleinterprètedulangage,beaucoupplusfacileàdévelopper, à maintenir et à faire évoluer (cf. §7.3). Cet usage fait d’ailleurs partie d’une
méthodologiededéveloppementdelangagesdédiés[CON98c].Chapitre2
Préliminairessurleslangages
etlesprogrammes
Computer,if youdon’topenthat exithatchprettydamnpronto,
Ishallgostraighttoyourmajordatabankswithaverylargeaxe
andgiveyouareprogrammingyouwillneverforget.
—DouglasAdams,TheHitchhiker’sGuidetotheGalaxy
Ce livre se focalise sur la spécialisation de programmesC. Cependant, beaucoup
desquestionsquiysontsoulevéesetdesréponsesproposéesontenfaituneportéequi
va au delà de ce seul langage.L’objectif de ce chapitre préliminaire est de poser une
terminologieetdesnotationsrelativementneutresparrapportauxdifférentslangages
et paradigmes de programmation,afin de permettre des discussions générales qui ne
concernentpasseulementlelangageC.
Cette terminologie et ces notations n’ont rien que de très standard et le lecteur
avertipourrapasserdirectementauchapitre3.
Toutefois, nous précisons particulièrement ici les notions d’entrée (§2.1.4) et
de
sortie(§2.1.5et§2.2.9),notionscléspourlaspécialisationdeprogrammes.Nousétudions également un certain nombre de problèmes généraux de définition sémantique
(§2.2),problèmessensiblespourdéfinirl’équivalencedeprogrammes.Nousdétaillons
enoutrelanotiond’interprétation,sourced’applicationsmajeureenspécialisationde
programmes, et présentons des exemples d’interprétation en couche (§2.4.2) et
de
compilation(§2.4.3)quiserontreprisauchapitre3pourillustrerlaspécialisation.Enfin,nousévoquonsl’influencedel’architecturedesordinateurssurlaperformancedes
33