Méthodes de génie logiciel avec Ada/Conclusion

Arrivé à ce point, le lecteur que nous avons pu convaincre de l'intérêt d'Ada se posera certainement la question : pourquoi n'est-il pas plus répandu ? On pensait au début qu'Ada remplacerait rapidement les langages alors principalement utilisés : FORTRAN, Pascal et, dans une moindre mesure, COBOL. Si le langage s'est bien introduit dans les domaines sensibles (aéronautique, aviation, domaine militaire, nucléaire, contrôle de processus), sa diffusion est restée modeste dans les domaines de la programmation traditionnelle : scientifique, gestion, programmation système, alors qu'on assistait à une montée en force du langage C, et plus récemment de C++.

Méthodes de génie logiciel avec Ada

1. Avant propos, préface, introduction
2. Une présentation rapide du langage Ada
3. Langages et méthodes
4. Méthodes avec Ada
5. Composants logiciels
6. Organisation de projet et choix fondamentaux
7. Une méthode orientée objet pour les projets
8. Conclusion
9. Annexes
10. Bibliographie
11. Glossaire

Conclusion

Pourtant, toutes les mesures effectuées sur des projets réels ont montré que les bénéfices que l'on pouvait espérer d'Ada étaient obtenus ou dépassés : meilleure qualité de la conception, réutilisation, augmentation de la productivité des programmeurs, infléchissement de la courbe des coûts en fonction de la taille des logiciels, effondrement du taux d'erreurs résiduelles et des coûts d'intégration, efficacité du code produit ; et ceci, quel que soit le domaine d'application concerné : on trouvera par exemple dans [Leb94] une étude complète sur l'impact de l'utilisation d'Ada en gestion. Mais le choix d'un langage de programmation fait intervenir de nombreux éléments, qui touchent plus à la psychologie qu'à l'économie.

Tout d'abord, l'expansion de C est liée au développement du système UNIX. Il est de tradition de fournir gratuitement le compilateur C avec les outils standard d'UNIX. Pourquoi alors acquérir un autre langage ? D'autant plus que C a pour lui une extrême simplicité (d'aucuns disent même pauvreté) de concepts. Remarquons au passage que ces arguments ne s'appliquent plus à C++ : les compilateurs sont payants, et le langage est devenu très compliqué !

Historiquement, UNIX a été développé par un petit nombre d'individus, sans souci de politique d'ouverture commerciale. Les interfaces ont donc été pensées uniquement en fonction des particularités du C ; c'est ainsi qu'une fonction peut retourner soit un pointeur, soit la valeur False (c'est-à-dire en fait zéro, qui est également le pointeur nul !). De telles hérésies de typage sont incompatibles avec la plupart des langages évolués, mais fréquentes avec C. Il en résulte des difficultés à faire des interfaces abstraites, propres, pour beaucoup de fonctionnalités UNIX, ce qui accentue le retard, en particulier au niveau de la standardisation, des autres langages par rapport à C. Et puis la « sagesse populaire » affirme que l'on doit programmer en C sous UNIX, sans plus d'explication. Bien sûr, il existe de nombreux composants et de nombreuses interfaces adaptés à Ada. Mais les vendeurs font rarement un effort commercial conséquent pour leur promotion, et il faut les acheter en plus, alors que beaucoup de bibliothèques C sont fournies avec le système. Là encore, l'effort initial est plus important avec Ada, même s'il est aisé de prouver que ce surcoût au départ est largement amorti sur le long terme.

En dehors de ces considérations pratiques, l'attirance du programmeur moyen pour C, et la peur instinctive qu'il éprouve vis-à-vis d'Ada, plongent leurs racines bien plus profondément. Beaucoup de programmeurs actuellement en fonction ont été formés à une époque où l'assembleur était roi. Nous avons connu des centres de calcul où les « nobles » (ceux qui étaient capables d'écrire tous leurs programmes en langage machine) regardaient de haut les novices qui n'étaient bons qu'à programmer en FORTRAN… Avec le temps, la programmation en assembleur tend à disparaître, car les problèmes de fiabilité, de maintenabilité et de portabilité sont vraiment devenus trop importants. Que sont devenus ces programmeurs ? Ils font du C. Ils ont trouvé un langage qui n'est en fait, selon la définition de ses auteurs, qu'un assembleur portable. Comme nous l'avons vu, il permet de faire (presque) tout ce que l'on pouvait faire en langage machine et n'implique aucune remise en cause ni des méthodes ni de la façon de programmer. Inversement, Ada a été spécifiquement conçu pour obliger les programmeurs à modifier leurs habitudes ! En particulier, la programmation Ada s'accompagne d'une description plus abstraite des traitements. Outre que ceci nécessite un effort de réflexion plus important, le programmeur tend à perdre le contact direct avec la machine. Il doit faire confiance au compilateur pour la génération de code efficace, et ne doit plus se préoccuper du parcourt exact du programme. Il n'est guère étonnant que l'inertie naturelle ne rende pas Ada très attrayant a priori au programmeur qui n'a pas saisi (car il n'a jamais essayé) les bénéfices d'une approche de plus haut niveau. Mais bien sûr, l'attirance naturelle du programmeur ne saurait être un critère pour un choix technologique dont dépendra tout le projet ! Comme il a été remarqué :

C++ ressemble à un énorme gâteau à la crème, ruisselant de sucreries ; Ada ressemble plus à un poisson poché / pommes vapeur.

Les questions intéressantes sont 1) quel est le meilleur pour votre santé et 2) qu'est-ce que les gens ont tendance à choisir spontanément ?

En outre, les compilateurs Ada ont parfois mauvaise réputation. Les premiers n'étaient disponibles que sur un petit nombre de machines, et peu efficaces, quand ils n'étaient pas franchement « buggés ». Les premières années, l'effort des fabricants s'est plus porté sur la conformité à la norme, vérifiée par l'incontournable suite de validation, que sur l'efficacité pour laquelle il n'y avait aucune obligation légale. Des compilateurs sont maintenant disponibles sur quasiment toutes les machines du marché, et des mesures objectives ont montré qu'ils étaient au moins aussi performants et fiables que les compilateurs C. Il n'en reste pas moins que le langage continue à traîner quelques vieilles « casseroles », d'autant qu'il est difficile de supprimer de la littérature les comptes rendus des premières expériences. C'est ainsi que [Bur85] signale qu'un rendez-vous prend 100 ms sur un Vax, ce qui rend le mécanisme inapte au temps réel serré. De nos jours, un rendez-vous prend moins de 100 µs (jusqu'à 4 µs sur certains systèmes spécialisés) , mais le livre de Burns (excellent au demeurant) est toujours en vente et n'a pas été réactualisé…

Un langage ne peut se répandre que s'il est enseigné ; force est de reconnaître qu'Ada n'a pas encore réussi à séduire tous les universitaires. Le prix des compilateurs, justifié en milieu industriel par le gain de productivité apporté, est un obstacle certain. C'est ce qui a conduit le DoD à financer le compilateur GNAT, pour mettre à la disposition de tous un compilateur Ada 95 gratuit. Ensuite, chercheurs et enseignants ont généralement des contraintes différentes des industriels : les logiciels sont rarement maintenus, mais doivent souvent être développés très rapidement. Même si les cours prônent le génie logiciel et l'importance de favoriser la maintenance au détriment de la facilité de développement, les universitaires appliquent rarement ces bons principes à eux-mêmes… Inversement, les langages orientés objet sont à la mode et semblent offrir des facilités supplémentaires (mais cet argument n'a plus lieu d'être avec Ada 95). Enfin, le fait que le DoD ait financé le développement d'Ada lui a créé une certaine antipathie dans les milieux universitaires, traditionnellement antimilitaristes.

Paradoxalement, les promoteurs du langage ont pu lui faire du tort par excès de purisme en exigeant de faire du 100% Ada. Le langage a tout prévu pour permettre d'écrire des modules en d'autres langages si c'était plus commode ; il autorise même l'écriture de modules en assembleur. Si ces éléments sont alors non portables, ce n'est pas trop grave dans la mesure où le mécanisme d'empaquetage garantit que ces non-portabilités sont répertoriées, aisément identifiées, et sans effet sur les utilisateurs des paquetages. Il n'y a donc pas de honte à écrire un corps de module en assembleur si, par exemple, il n'y a pas d'autre moyen d'obtenir les performances requises. En exigeant le « tout Ada » au-delà du raisonnable, on risque de se heurter à des problèmes tout à fait localisés, mais dont la publicité risque de discréditer le langage tout entier.

Enfin, il est remarquable de constater que les plus virulents adversaires d'Ada… ne l'ont jamais pratiqué ! Peut-être ont-ils juste fait quelques essais, sans formation appropriée, en traduisant « littéralement » des bouts de code d'autres langages avec lesquels ils étaient familiers. Au bout de quelques erreurs de compilation, ils ont décidé que le langage était difficile, et n'ont pas poursuivi. Inversement, ce n'est qu'à l'usage que l'on en apprécie tous les avantages : typage fort, exceptions, parallélisme… Il est certain que pour tirer tout le bénéfice d'Ada, il ne suffit pas d'apprendre la syntaxe ; il faut assimiler l'état d'esprit, la façon de faire qui va avec. Il faut admettre qu'un langage comme Ada joue un rôle différent dans le processus de développement et que, comme nous l'avons démontré dans la première partie, le choix du langage de codage n'est pas neutre – précisément parce qu'il peut être beaucoup plus qu'un simple outil de codage. Comme le remarquait Booch [Boo91] :

Donnez une perceuse électrique à un charpentier qui n'a jamais entendu parler de l'électricité, et il l'utilisera comme marteau.

Il tordra des clous et se tapera sur les doigts, car une perceuse fait un très mauvais marteau.

Si les mauvaises nouvelles courent vite, il est plus difficile de répandre les bonnes, et Ada n'a pas toujours su « faire sa pub ». Qui, en dehors des convaincus, sait qu'Ada a été utilisé avec succès dans de nombreux programmes de gestion, dont un projet de 2,5 millions de lignes de code qui a pu être développé avec la moitié du coût initialement prévu (STANFINS, [Leb94]) ? Qu'un logiciel qui n'arrivait pas à tenir ses contraintes temps réel en C a été récrit en Ada avec des performances satisfaisantes [Tar93] ? Qu'une entreprise gère plusieurs projets totalisant un million de lignes de code en n'employant qu'une seule personne à la maintenance [Pid93] ?

Soyons honnête cependant : les utilisateurs d'Ada 83 ont pu rencontrer des difficultés objectives, même si la plupart ont appris à « vivre avec ». On notera en particulier le manque de support des méthodes par classification, la prolifération des tâches pour de simples synchronisations, de trop nombreuses recompilations dans les grands projets, des difficultés d'interfaçage avec d'autres langages ou des bibliothèques… et le manque de fiabilité des premiers compilateurs et des environnements de programmation. Ces problèmes ont disparu avec le temps, ou ont été résolus par Ada 95 et peuvent être maintenant considérés comme résolus.

Lorsqu'une étude objective est menée, prenant en compte les principes du génie logiciel, les coûts des développements informatiques pris sur l'ensemble du cycle de vie, et les contraintes de fiabilité et de sécurité, elle aboutit toujours à la même conclusion : Ada est le seul langage qui offre le support nécessaire aux méthodologies modernes de développement. Le problème est que les facteurs objectifs ne sont souvent pas suffisants pour convaincre les utilisateurs. Le bouche à oreille, la rumeur, de mauvais résultats dus à des essais sommaires sont souvent plus crus que les études formelles. Cette attitude se résume en la formule :

« Bien sûr, l'étude a conclu qu'il fallait utiliser Ada… mais mon voisin de palier travaille en C. »

Il reste encore du chemin à parcourir pour obtenir une approche industrielle du développement logiciel !

Références

<references>