 |
 |
 |
|
|
SUR LE CHEMIN D'EIFFELLe langage Eiffel, qui a été créé par Bertrand Meyer et son équipe, figure aujourd'hui parmi les quelques environnements de programmation purement par objets destinés au développement d'applications industrielles de grande taille. Comme langage, Eiffel s'est tout d'abord présenté comme l'intégration de deux cultures informatiques : celle des environnements à objets graphiques interactifs popularisés par Smaltalk, outil mono-utilisateur puissant de prototypage rapide, et celle de la tradition génie logiciel parachevée par Ada, la vision du développement à grande échelle pour la production de logiciel fiable, assurant une plus grande sécurité de fonctionnement. Ensuite, arrivé à maturité, Eiffel est passé sous le contrôle du consortium NICE (Non-Profit International Consortium for Eiffel) afin de lui donner un statut de langage public. Clivage entre "techniques traditionnelles" et techniques à ObjetsLes langages de programmation classiques, aussi appelés procéduraux, manipulent des données et des procédures sans qu'il y ait de contrainte sur les relations entre les procédures et les données qu'elles manipulent. Les données ou les procédures évoluent inévitablement de façon désynchronisée. Une modification dans l'une des parties du logiciel peut finalement avoir des répercussions inattendues dans une autre partie et inversement. Des études sur la maintenance ont d'ailleurs montré qu'environ 40 % des coûts étaient dus aux changements de spécifications et 20 % aux changements de format dans les données. Ajouter un champ à un enregistrement implique de modifier toutes les parties du programme qui exploitent cette donnée : dans les passages de paramètre, les formats d'entrée/sortie, etc. Dans un langages à objets, dit Orienté Objet, les programmes sont construits autour des données (structures de données, compte en banque, matrice, simulateur de vol, ... ). Les données regroupent les primitives qui y accèdent, les exploitent et les modifient. En Eiffel, ces manipulations de données sont, en outre, garanties par des règles d'intégrité assurant la cohérence des objets. Cette notion nouvelle, popularisée par Eiffel et nommée " conception par contrat ", permet à chaque objet de n'accéder aux primitives d'un autre objet qu'en respectant des règles de visibilité et de contraintes de validité découlant de la spécification elle-même. Chaque objet devient ainsi responsable d'une délégation d'opération à un autre objet qui lui-même s'engage à ne réaliser une opération que conformément à ce qu'on en attend. Trop de temps est souvent passé à ré-inventer des structures classiques de programme ou plus simplement à refaire moins bien ce que des spécialistes ont écrit une fois pour toute de la façon la plus efficace possible. Dans la technique à objets, avant d'attaquer un moindre développement, il est judicieux de se demander avant tout s'il n'existe pas déjà quelque chose de similaire, même s'il ne s'agit pas exactement de la même chose, dans un domaine d'application proche ou analogue. La technique à objets permet de travailler par adaptation et modification, dans le respect de la modularité existante. Il est aujourd'hui hors de question de donner le code source d'une application de plusieurs milliers (voire plusieurs millions) de lignes à une ou plusieurs personnes en leur demandant de se plonger dans les détails techniques. Pour cette raison, des mécanismes de structuration et de classification puissants sont indispensables pour maîtriser la complexité. La structure d'un système Eiffel est définie par les constituants suivants:
Une autre idée véhiculée par Eiffel est qu'un logiciel doit contenir sa propre documentation afin de minimiser les incohérences. Pour ce faire, il existe un mécanisme d'abstraction de classes qui extrait automatiquement à partir du code source l'information minimale nécessaire à sa compréhension et à son utilisation. Au cours d'une démarche de construction de systèmes logiciels par objets, la notion de bibliothèques de composants réutilisables est primordiale. Il s'agit à la fois du principal matériau disponible et de l'une des finalités de l'activité de développement. De quoi s'agit-il ? Principalement de se poser systématiquement la question de savoir si ce que l'on est en train de produire est susceptible d'être réutilisé par d'autres développeurs. Il s'agit ensuite de rendre véritablement réutilisables les composants concernés, c'est-à-dire testés, documentés, généralisés et publiés. Les bibliothèques disponibles avec Eiffel sont le fruit d'un patient processus d'affinement. Les classes qui forment ces bibliothèques ont été intensivement testées et utilisées dans le cadre de divers développements réutilisant ces composants. On trouve des bibliothèques pour la manipulation des structures de base de la programmation, pour la gestion de la mémoire, pour le traitement des exceptions ainsi que pour l'analyse lexicale et syntaxique. Des bibliothèques plus spécialisées concernent la gestion de bases de données et la construction d'applications graphiques. Ces deux dernières bibliothèques ont d'ailleurs été bâties en respectant une même philosophie de conception : fournir, d'une part, des classes très générales utilisables par les programmeurs d'applications et, d'autre part, fournir des classes d'implémentation spécifiques d'un SGBD ou d'un serveur graphique à interface constante. Eiffel vise tous les domaines d'applications informatiques où la fiabilité et la sécurité des logiciels produits jouent un rôle prédominant. Curieusement, les réticences les plus fréquentes viennent souvent de l'informatique technique, domaine dans lequel les développeurs sont encore très soucieux de préserver leur chasse gardée : celle des optimisations de très bas niveau ou celle de la connaissance des mécanismes d'implémentation des compilateurs. Les exigences de réutilisation imposent désormais de faire reposer les problèmes très pointus d'implémentation sur les seuls spécialistes et non sur les concepteurs des architectures logicielles de demain. Eiffel n'intéresse en fait pas seulement l'informatique technique, mais aussi et surtout l'informatique de gestion puisque la maintenance de données cohérentes en est le pain quotidien. Très fréquemment, le choix d'Eiffel intervient dans des applications caractérisées par une grande complexité de situations ou d'information, imposant alors un effort important de structuration et de classification appuyé par des mécanismes solides de contrôle de validité. Eiffel est actuellement disponible sur une très large gamme de stations de travail de type Unix, mais aussi sur DOS/Windows et Mac OS-10, VMS. Au-delà des objets ordinaires, les objets spécifiésQuand faut-il réutiliser des objets existants ? S'ils sont bien spécifiés, on doit les réutiliser chaque fois que leurs spécifications correspondent aux besoins du développement en cours. Si, par contre ils sont mal spécifiés voir pas spécifiés sauf par quelques commentaires qui, nécessairement, laissent beaucoup de choses telle que les conditions aux limites, dans le flou, alors, il ne faut pas réutiliser. Même, si par hasard, un tel composant fait approximativement ce que vous désirez à un moment donné, aucune garantie n'existe que la révision suivante aura toujours le même comportement. En effet, l'auteur d'un tel composant peut penser que le comportement doit être modifié pour satisfaire d'autres besoins, peut être plus généraux soit, mais qui ne sont pas les vôtres. Pour l'ingénieur, le meilleure n'existe pas. Le concept de qualité n'existe que par rapport à une spécification précise. Un composant est meilleur qu'un autre seulement s'il couvre mieux les spécifications. D'un part la sienne, d'autre part celle souhaitée. Pour satisfaire cette exigence de spécification, Eiffel incorpore la programmation par contrattm. Ceci consiste à incorporer des assertions qui forment la spécification des classes de composants (les invariants) et la spécification d'entrée sortie de chaque routine (pré-conditions et post-conditions). Certes, il existe des langages de spécification cependant, ils sont disjoints des codes d'implémentation. Ceci les rends généralement impropres à assurer la qualité des implémentations ainsi spécifiées. Le couplage fort de la spécification et du code donne bien d'avantage de garantie dans cette direction notamment parce que cette spécification est la base même du déverminage et que de surcroît, l'acquéreur peut lui même faire tourner ce composant acquis en mettant en oeuvre la spécification et ainsi vérifier par lui-même que le composant satisfait bien sa spécification. Même, si cette méthode a des limites, elle constitue un pas définitif vers des logiciels de qualité c'est à dire d'abord correct. RéférencesB. Meyer: Eiffel: the language; Prentice-Hall, Object-Oriented Series, 1992 J.-M. Nerson : Applying object-oriented analysis and design; Communications of the ACM, vol. 35, n' 9,sur le réseau UUnet (comp.lang.eiffel). Le present texte s'inspire également d'un article de JEAN-MARC NERSON & YVAN GALISSON de décembre 1991 Voir aussi sur le net
|
