Les environnements Eiffel

Depuis la premi`ere impl´ementation d’EIFFEL2 par la soci´et´e ISE en 1988, les environnements se sont consid´erablement am´elior´es et diversifi´es. Il existe actuel-lement quatre impl´ementations principales d’EIFFEL3 qui sont d´evelopp´ees par les soci´et´es ISE (Interactive Software Engineering, http://www.eiffel.com), OT (Object Tools, ex SIG Computer, http://www.sigco.com), Tower (Tower

Technology Co,http://www.twr.com) et l’impl´ementation SMALLEIFFEL

(LO-RIA, Dominique Colnet, ftp.loria.fr/pub/loria/genielog/SmallEiffel) qui est distribu´ee gratuitement selon la convention des produits GNU de la Free

2.9.1 Objectifs g´en´eraux

Ces environnements visent tous plus ou moins les mˆemes objectifs d’interac-tivit´e, mais avec la possibilit´e de finaliser la fin d’un projet en g´en´erant un code optimis´e dans les standards actuels (C ANSI, C++ ou bytecode JAVA). La documen-tation de toutes les classes est test´ee selon le point de vue des clients ou des h´eritiers, grˆace `a des outils comme short (§2.8.3), flat ou flat-short. L’outil flat donne la vue concr`ete et compl`ete de toutes les primitives d’une classe, en rapatriant toutes celles h´erit´ees ; l’outil flat-short applique `a cette vue un filtrage qui donne la vue abstraite de toutes les primitives disponible dans une classe donn´ee.

L’efficacit´e du code g´en´er´e peut ˆetre voisine, voire mˆeme d´epasser celle d’un programme ´ecrit `a la main en langage C [Collet et al., 1997]. En effet, les optimi-sations de la phase de finalisation suppriment les primitives h´erit´ees non utilis´ees, les liaisons dynamiques inutiles et expansent le code des petites routines lorsqu’il n’y a, ni r´ecursivit´e, ni liaison dynamique. Il est donc inutile, comme le font en-core certains langages, de demander l’aide du programmeur pour ces optimisations. Si cet avis est encore utile, comme de choisir entre une optimisation de la vitesse d’ex´ecution ou de l’espace m´emoire, sa place n’est pas dans le texte des classes. Celui-ci doit en effet ˆetre le plus possible ind´ependant du contexte d’utilisation, pour faciliter sa r´eutilisation. Dans le cas d’EIFFEL, toutes les informations n´ecessaires `a la g´en´eration d’une application sont plac´ees dans un fichier Ace (§2.3.2). De plus, la pertinence des choix du programmeur ne peut rivaliser avec celle d’un outil au-tomatique qui, seul, peut avoir toute la connaissance n´ecessaire, fiable et `a jour au moment utile pour l’exploiter.

La transportabilit´e est ´egalement un soucis marqu´e des environnements EIF

-FELqui permettent de produire des logiciels qui peuvent ˆetre compil´es et ex´ecut´es sur diff´erentes plates-formes, Unix, Windows, OS2, VMS..., et qui disposent de bi-blioth`eques de composants graphiques pour les pr´esentations favorites de ces diff´e-rents syst`emes. Pour les applications interactives qui font un usage important des m´ecanismes graphiques, il y a cependant quelques limitations qui sont dues `a cer-taines incompatibilit´e des environnements, notamment entre X11/Motif et Win-dows 95.

2.9.2 Compilation incr´ementale

D’autre part, la puissance actuelle des ordinateurs rend possible la r´econciliation des approches statiques et dynamiques pour analyser et ex´ecuter le code. Il n’est plus n´ecessaire d’utiliser un langage dont la syntaxe est limit´ee aux parenth`eses, ou absconse comme les langages postfix´es, pour avoir un d´elai acceptable entre l’instant de la derni`ere modification et celui de l’affichage des premiers r´esultats.

`

A partir du moment o `u ce d´elai est inf´erieur `a dix, voire souvent `a deux ou trois secondes, il devient inutile de gagner quelques dixi`emes de seconde. Ce court r´epit suffit maintenant largement pour faire l’analyse syntaxique compl`ete de quelques classes, les v´erifications de s´emantique statique les plus urgentes et traduire le code dans une repr´esentation interne (r´eification, bytecode, langage interm´ediaire...) qui se prˆete bien `a l’interpr´etation. Ce principe n’exige pas que tout le syst`eme en

d´eveloppement soit interpr´et´e, mais seulement les parties en cours d’´evolution,

nor-malement r´eduites `a quelques classes. C’est ce que faisait un interpr`ete d’EIFFEL

2 en EIFFEL 2 [Brissi et Gautero, 1991] et maintenant l’environnement EIFFEL -BENCHd’ISE avec sa Melting Ice Technology (m´etaphore de la glace fondante).

Ainsi, le handicap des langages compil´es peut-ˆetre quasiment ´elimin´e, mais avec le gros avantage de pouvoir b´en´eficier du typage statique qui est utile non seulement pour la fiabilit´e (§2.8), mais aussi pour l’efficacit´e. S’il est vrai que les langages interpr´et´es peuvent aussi am´eliorer nettement leur efficacit´e d’ex´ecution, grˆace `a des techniques de caches ou de traduction en C, cela est beaucoup plus difficile `a faire, `a cause des nombreux choix qui restent encore ouverts pendant l’ex´ecution. Pour la fiabilit´e en revanche, les langages interpr´et´es ne peuvent pas inventer l’information de typage qui leur manque le plus souvent.

De plus, tous les contrˆoles statiques, en particulier les plus fins, n’ont pas besoin d’ˆetre syst´ematiquement r´ealis´es `a chaque compilation : ils peuvent souvent ˆetre ef-fectu´es plus tard, avec d’autres v´erifications statiques ou dynamiques, comme des analyses globales plus fines que la r`egle des catcalls ou des ´evaluations d’assertions co ˆuteuses (tests d’int´egrit´e de bases de donn´ees, v´erifications de quantifications...). Cette perspective de d´esynchronisation des diff´erentes actions sur un programme en construction, d´ej`a initi´ee avec les premi`eres impl´ementations du langage C22, offre de nombreuses possibilit´es qui ne sont pas encore toutes exploit´ees, y compris pour EIFFEL. Ainsi, le langage OQUAL[Collet, 1997] n’est r´ealiste qu’avec la possibi-lit´e d’´evaluer ses quantifications de mani`ere incr´ementale, au fur et `a mesure de la construction des classes, ou de mani`ere diff´er´ee pour les tests d’int´egrit´e, la nuit ou les week-ends par exemple.

En prenant l’exemple de l’environnement EIFFELBENCH(Fig. 2.11), un texte EIFFELest traduit selon diff´erents niveaux de finition, dans l’une des trois formes suivantes :

• interpr´etable pour les parties en cours de mise au point, que Bertrand Meyer appelle((chaudes)),

• compil´ee, mais sans optimisation pour le reste d’une application en cours de d´eveloppement (les parties((froides))),

• ou finalis´ee, c’est-`a-dire traduite dans un langage standard (C/C++, JVMde JAVA), et sous la forme optimis´ee d’un kit portable avec ses proc´edures d’ins-tallation, sa documentation, ses tests...

Les changements de formes peuvent se faire de mani`ere interactive, en utilisant des boutons comme ceux de la figure 2.11, et en adaptant le fichier Ace pour choisir le niveau de contrˆole statique, l’armement des assertions, la gestion de l’´evolution. L’interaction est ´egalement indispensable pour tout ce qui concerne l’information du programmeur (browsing) sur les classes qu’il r´eutilise et pour le d´ebogage, d’uti-lisation assez rare en EIFFELgrˆace aux assertions. Ainsi, l’environnement EIFFEL -BENCHpermet de naviguer dans l’univers de classes d´efini par un fichier Ace, d’ex-plorer ces classes selon diff´erents points de vue (concr`ets ou abstraits, primitives

22. Comme par exemple d’utiliser une s´equence “cc -O0; lint; cc -O3” pour compiler rapide-ment, plus tard faire une v´erification statique et enfin produire un code optimis´e.

FIG. 2.11: Un exemple de session avec l’environnement EIFFELBENCH

propres `a la classe ou h´erit´ees...), de connaˆıtre les super-classes ou les sous-classes d’une classe, ses clients ou ses fournisseurs. Les fonctions de d´ebogage sont clas-siques et permettent des ex´ecutions en pas `a pas et des analyses de l’´etat des objets (cf. Fig. 2.11).

S’il est vrai qu’il existe de bons environnements interactifs pour d’autres lan-gages (notamment pour SMALLTALK), mˆeme si nombre d’id´ees utilis´ees dans les environnements EIFFELsont connues et sous-exploit´ees, nous ne connaissons pas d’autres environnements actuels qui les appliquent toutes ensembles aussi bien. Cela explique les excellents taux de productivit´e que nous avons constat´e lorsqu’on d´eveloppe en EIFFEL[Rousseau et al., 1994b]. Ainsi, un mod`ele r´ecent d’estima-tion des co ˆuts de d´eveloppement avec une approche par objets [Giliberti et al., 1997] a ´et´e ´etalonn´e avec un bon coefficient de corr´elation23 sur des projets d´evelopp´es en SMALLTALKet C++ [Lorenz et Kidd, 1994]. En appliquant ce mod`ele au projet K2 [Lahire et Jugant, 1995], nous obtenons un effort d’environ 90 hommes×mois au lieu de 30 en r´ealit´e. Mˆeme si l’on peut contester la fiabilit´e de ce mod`ele d’esti-mation des co ˆuts, cela indique clairement une productivit´e tr`es ´elev´ee pour ce pro-jet qui a ´et´e d´evelopp´e avec l’environnement EIFFELBENCH. De plus, l’effort r´eel comprend la fourniture d’une documentation interne de 2 500 pages et de tests assez complets, grˆace aux assertions.

2.10 Conclusion

L’approche objet apporte des solutions potentielles `a tous les probl`emes que se pose le g´enie logiciel, pour obtenir `a moindre co ˆut des logiciels ´evolutifs, r´eutili-sables, fiables, efficaces, bien document´es, portables et interfac¸ables. Bien que cette approche manque encore s´erieusement de maturit´e, elle int´egrera probablement tous les paradigmes actuels. C’est d’ailleurs une erreur de consid´erer l’approche objet sur le mˆeme plan que la programmation imp´erative, fonctionnelle ou logique. Elle se situe en effet sur une autre dimension, celle de la structuration des programmes, ce qui permet de la comparer aux principes de la((programmation structur´ee))des ann´ees soixante-dix ou de la((modularit´e classique))des ann´ees quatre-vingt. Dans les deux cas, elle d´epasse de loin, et sans doute de mani`ere d´efinitive, les m´erites des approches classiques.

Dans la famille des langages `a objets d´edi´es au g´enie logiciel, le langage EIFFEL

tient une place paradoxale. C’est `a notre avis le langage actuel qui offre la solution la plus compl`ete et la plus coh´erente, ce qui en fait d´ej`a un excellent support pour l’en-seignement [Boussard et Rousseau, 1995]. Les environnements actuels pour EIFFEL

sont interactifs, performants et conviviaux, avec des biblioth`eques cons´equentes de milliers des primitives r´eutilisables ; ils sont certainement `a l’origine des taux ´elev´es de productivit´e que nous avons constat´es. Pourtant, le nombre des utilisateurs d’EIF

-FELreste tr`es inf´erieur `a ce que l’on pourrait imaginer, car depuis FORTRANet CO

-BOL, la plupart des utilisateurs suivent les standards du moment aujourd’hui C++ et JAVA. Il est pourtant possible de d´evelopper en EIFFELdu logiciel ´evolutif et bien document´e et de le traduire dans ces derniers standards.

Toutes les constructions d’EIFFELnous paraissent utiles, sans redondance. Les bases du langage sont solides, ce qui lui permet d’´evoluer ou de servir de support `a des extensions [Rousseau et al., 1994a] pour acqu´erir de nouvelles aptitudes [Rous-seau, 1995], pour les applications persistantes [Lahire, 1992], parall`eles [Caromel, 1993] ou r´eparties [J´ez´equel, 1993a] ou pour la sp´ecification des programmes [Col-let, 1997]. En revanche, les possibilit´es de m´etaprogrammation n’ont pas encore ´et´e suffisamment explor´ees.

Introduction `a C++ et