Les approches ad hoc

les problèmes rencontrés régulièrement par les développeurs d’applications de gestion. Les premières tentatives d’approches plus formelles vis-à-vis de MDD (appelées alors CASE pour computer-aided software engineering) furent pour la plupart de coûteux échecs.

Bien que les générateurs d’applications appréciés par le passé n’aient peut-être pas le genre d’architecture formelle, multicouche, que l’on trouve dans les approches OMG et Microsoft, les produits ont démontré qu’ils peuvent atteindre les objectifs MDD : élever le niveau d’abstraction et augmenter l’usage de l’automatisation pour améliorer la productivité et la qualité des applications.

Comment les comparer ?

OMG et IBM ont beaucoup travaillé pour créer des standards (et, dans le cas d’IBM, des outils) afin qu’UML fonctionne comme, essentiellement, un langage polyvalent de très haut niveau. Par exemple, les profils UML concentrent le langage sur des domaines spécifiques, et les actions sont une tentative de mieux exprimer le comportement des applications au travers d’UML. Mais, à mon avis, au moment où IBM ou tout autre fournisseur fera tout ce qui est nécessaire pour produire un générateur d’applications vraiment automatisé respectant les standards MDA, le résultat sera tellement propriétaire, que la standardisation sur UML sera un avantage marginal. Et, à en croire Microsoft, les limitations d’UML pourraient encore se manifester au travers de l’outillage.

Microsoft, de son côté, a ajouté de nombreuses couches architecturales à sa description de software factories et de DSL, ainsi qu’un important support d’outillage. Cela afin d’inciter les fournisseurs d’outils de développement à créer des générateurs d’applications qui amélioreront nettement la productivité sur les plates-formes Microsoft. A l’évidence, cette stratégie ne favorise pas beaucoup l’indépendance visà- vis des plates-formes, un avantage potentiel important de MDD.

En outre, malgré le label accrocheur, on voit mal comment la software factory de Microsoft est fondamentalement différente des approches d’IBM et des autres fournisseurs, pour créer l’infrastructure nécessaire dans l’environnement Eclipse permettant aux fournisseurs de délivrer des outils de développement d’applications. Le principal argument en faveur du développement System i est que l’approche de Microsoft ne produira probablement pas de nouveaux outils basés sur MDD pour les applications tournant sur un System i.

Pour les applications System i développées localement, il me semble que l’approche IBM Rational (c’est-à-dire RSA) est trop complexe à ce stade pour que de nombreuses organisations IT l’adoptent, sans parler de l’adéquation d’UML au développement d’applications polyvalentes.

Je n’ai pas non plus constaté beaucoup d’intérêt vis-à-vis de l’approche MDA OMG de la part des fournisseurs établis de générateurs d’applications pour le System i. Beaucoup d’entre eux ont beaucoup investi dans leurs propres architectures et IDE, et le coût et le risque d’un redéveloppement généralisé sous les standards MOF et UML sont probablement assez dissuasifs pour que ces vendeurs adoptent MDA. Il n’est pas non plus certain que ces fournisseurs réimplémentent leurs IDE sur un socle Eclipse ou Visual Studio. J’estime cela improbable, sauf pour les fournisseurs dont les produits ciblent MS Windows ou Unix/Linux, ainsi que le System i.

Je prévois une importante amélioration des possibilités des générateurs d’applications, mais pas une coalition autour d’un standard MDD complet, de la même manière que de vastes segments du monde de développement à l’extérieur de la sphère Microsoft, ont adopté les standards Java pour la programmation HLL.

Je pense aussi que les cinq prochaines années verront apparaître de nouveaux générateurs d’applications. Ces produits seront basés sur Eclipse ou Visual Studio, augmentant la pression sur les fournisseurs établis pour qu’ils remanient leurs propres produits.

Sans une solution MDD ayant le genre d’acceptation généralisée sur toutes plates-formes dont jouit Java, les groupes de développement System i qui songent passer du développement centré sur le code à plus d’automatisation et à plus d’indépendance vis-à-vis des plates-formes, resteront confrontés à une décision difficile. Les principaux facteurs à considérer resteront le palmarès du fournisseur et les possibilités du générateur d’applications, et ce, qu’un produit soit ou non basé sur MDA.