@SURTITRE 1:MAINTENANCE ET ORIENTATION OBJET
@TITRE 1:Des gains certains, mais des inconvnients possibles
@CHAPO:L'orientation objet amliore toujours la maintenance volutive, parfois dans de fortes proportions (jusqu' 50%). En maintenance curative, le bilan se fait plus contrast, surtout si le langage objets n'est pas l'aboutissement d'une vraie conception par objets.
@TEXTE:Thme la mode, l'orientation objet, ds ses origines, a vis la r-utilisabilit du code. Objectif deproductivit, donc, mais du mme coup amlioration de la maintenance. Au moins la maintenance volutive, c'est dire l'adaptation au fil du temps des programmes aux volutions des besoins comme des possibilit de la technologie.
Il ne s'agit, en effet, que d'une prolongation du produit d'origine. L'exprience confirme les espoirs: aprs quelques annes de pratique, les experts font preuve d'une belle unanimit pour reconnatre les effets positifs de l'orientation objet sur la maintenance volutive. Jean-Marie Letourneux (Directeur recherche et dveloppement, GSI-IS) value 50% le gain sur la maintenance d'un gros produit bancaire (110 excutables de 800-900 K chacun, en C++ sous Unix). Il serait de 25 30% sur le projet Nemesis de la CEE (Objective C et C++, 200 000 lignes de code sous Unix sur Sun et RS 6000).
Une seule rserve: la programmation objet ne peut encore prtendre la maturit d'une technologie prouve. Les premiers compilateurs Ada valids datent de 1985, et l'exprience des problmes rencontrs ne peut donc se comparer celles des langages traditionnels (Cobol et Fortran).
@INTER:Attention la maintenance corrective
@TEXTE:En revanche, pour la maintenance curative (ou corrective) les avis divergent sur les effets de l'orientation objet. Les uns relvent les effets positifs dus une bonne structuration, d'autres observent des effets pervers dcoulant des principes mmes de la programmation objet ou des pratiques qu'elle encourage.
Baudoin Roger (directeur gnral, IGL Technologies), observe des gains trs importants. Une bogue est plus facile traquer, les donnes sont encapsules, l'interface parfaitement dfini. Habib Achkar (directeur, direction technique recherche et dveloppement, Sema Group) prcise: "Le temps pass une correction se dcompose entre identification de l'erreur (25% du temps), excution de la modification (25%) et suivi des impacts de la modification (50%). Les gains les plus importants s'observent sur ce dernier point, car les effets de bord sont explicitement dfinis.
Parmi les observateurs plus critiques se comptent les universitaires amricains intervenus en octobre dernier la Conference on Software Maintenance de Sorrente (Italie). Pour eux, la programmation objet peut fortement compliquer la tche du correcteur, surtout dans les interventions d'urgente.
En effet, l'hritage et les liens dynamiques multiplient les lieux possibles de l'erreur qui a caus le problme. Elle peut se trouver dans le code d'une classe donne mais aussi d'une de ses super-classes. Mme une fois la fonction fautive identifie, il peut s'avrer difficile de savoir exactement quelle version surcharge de cette fonction est fautive.
Ross Huitt (Bellcore), prcise "De nombreuses tches s'crivent sous forme de mthodes trs brves, qui se contentent de faire passer un message une autre mthode en accomplissant peu de traitements. Un systme peut donc se composer d'un grand nombre de trs petits modules... sur un chantillon de 2224 mthodes du systme Smalltalk V, 40,6% comprenant deux lignes ou moins... une partie de la littrature sur la bonne programmation oriente objet encourage ce style...". Pour la maintenance, cela implique que le code relatif une tche donne risque de trouver largement dispers dans l'ensemble du programme.
@INTER:Se mfier du C++ gadget
@TEXTE:Bref, les affres du "Cobol spaghetti" se retrouvent dans les hirarchies et treillis multiples qui structurent objets et mthodes. Ces constatations conduisent les experts converger vers trois recommandations.
D'abord, ne pas se croire vraiment "orient objet" si l'on se contente de programmer dans un langage portant ce label. C++ se prsente comme une extension de C par l'ajout de structures objet. Rien n'oblige le programmeur bien s'en servir (ni mme d'ailleurs s'en servir). Tout en se targuant d'une orientation objet, il peut continuer travailler en C et en conserver le laxisme permis par ce langage, voire encourag par un "esprit C" trs loign des bonnes disciplines industrielles.
Attention, inversement, vouloir trop bien faire ce niveau "L'abus de hirarchies complexes conduit des pratiques pires qu'en C", avertit Baudoin Roger.
Enfin, l'ergonomie mme des interfaces graphiques encourage l'abus du couper-coller. Ce mode de dveloppement, naturel avec la structure fonctionnelle du langage C. En maintenance volutive, il introduit le risque d'une volution mal coordonne des fonctions ainsi obtenues. En programmation objet, l'emploi mthodique de l'hritage corrige ce dfaut... mais les facilits de la programmation " la souris" peuvent le r-introduire.
@INTER:Ce qui se conoit bien se programme proprement
@TEXTE:Ces inconvnients et ces drives conduisent les spcialistes quelques recommandations pour que la maintenance bnficie vraiment des nouvelles orientations.
Point primordial: la conception compte plus que la programmation. Les applications volueront facilement si les objets ont t bien choisis. Le choix d'un langage objet en dcoulera naturellement, car il permettra de bien raliser ce qui a t conu. Encore qu'un utilisateur comme la CNRO (Caisse nationale de retraite des ouvriers du btiment) continue de programmer en PL/I, conformment ses standards maison, mme pour une grande application qu'elle reprend la base "en s'appuyant sur une mthodologie objet", comme nous l'a prcis Jean-Nol Massot, directeur informatique.
Deuxime point, ne pas multiplier les objets. Benoit Faller (responsable du ple "techniques innovatives", Cap Sesa Dfense) recommande "un dcoupage en objets taille humaine", et introduit le concept de schma, ou ensemble de classes: "Si un systme branche en rateau sur 5000 classes, impossible la maintenance de s'y retrouver. Avec trente schmas intermdiaires, a va".
@INTER:Un bon environnement n'est pas un luxe
@TEXTE:Ensuite, offrir aux concepteurs un environnement suffisamment puissant, soutenant les "deux nouveaux gestes du programmeur: navigation et coup-coll" (J.M. Letourneux) et les insrant correctement dans l'ensemble du processus de conception. La documentation papier n'arrive plus suivre la course la complexit impose par l'orientation objet. Les environnements de compilateurs commerciaux (d'Eiffel Turbo C++) apportent progressent en ce sens, de mme que les ateliers de gnie logiciel, comme l'ObjectCenter (pour C++), d'IGL.
Les outils de navigation mritent d'tre particulirement muscls pour les phases de diagnostic de panne. Ils font l'objet de recherches comme celles de Lejter, Meyers et Reiss la Brown University. Leur prototype XRef/XRefDB sont conus pour faciliter la maintenance en soutenant le suivi des graphes de dpendance entre objet et mthodes, grce une base d'informations sur des programmes C++ (mais aussi C et Pascal).
Enfin, les applications orientes objets ne pourront tre maintenues des co-ts raisonnables que si les quipes comptentes sont suffisamment toffes. Sur ce point, la situation volue favorablement, par l'effet conjugu de la formation permanente et de l'arrive de nouvelles gnrations d'informaticiens.
@INTER:Chi va piano va sano
@TEXTE:Mais les mutations culturelles prennent du temps. Baudoin Roger recommande donc la progressivit. Commencer par un petit projet. Une interface homme-machine, par exemple, a l'avantage de bien introduire la technologie objet tout en limitant les risques en cas de problme. Une fois acquise la matrise du concept, on s'attaquera des applications de plus grande envergure, et la comptence en maintenance se renforcera au rythme du dveloppement des projets.
@SIGNATURE:PIERRE BERGER
LEGENDE:Une bonne interface graphique facilite sensiblement la navigation dans l'cheveau des dpendances entre classes et mthodes (document Borland).