Demain, tous développeurs?

IV. Nous ne pouvons pas tous être développeurs

1. Le logiciel

A. Le MDA présente ses faiblesses

A. La question sur les outils

Pour rappel le but du MDA est de générer presque automatiquement les modèles PSM depuis les PIM. Mais tout cela n'est possible que pour quelques rares environnements techniques. En effet, le problème est que la technologie sous-jacente change très rapidement et le temps que les mappages automatiques se soient mis en place pour une plate-forme donnée, la technologie aura changée. De plus, pour que tout le monde y ait accès, la démarche MDA devrait être adaptée à plusieurs plates-formes, or ce n'est pas le cas. Ainsi, un utilisateur qui acquière un outil MDA se limite à travailler sur certaines plates-formes, donc il n'y aurait pas de plates-formes hétérogènes.

Chaque éditeur respecte le MDA à sa manière à l'instar de CORBA ^6(*). CORBA est une norme très complète pour les architectures distribuées, cependant les outils supportant CORBA ne l'étaient pas autant. Du coup les éditeurs implémentaient leur propre vision de CORBA, et ainsi les différents ORB^7(*) fonctionnaient mal ensemble. Ainsi ce scénario pourrait se répéter avec le MDA. Les outils seront différents et le passage d'un modèle d'un outil à un autre pourrait être délicat malgré le XMI. Par le passé, les stratégies d'intégration d'outils ont énormément échoué, il est donc fort possible que ça se reproduise avec le MDA.

B. Le MDA est trop compliqué

Une vision erronée du MDA est que les développeurs ont des compétences en modélisation. En effet, les développeurs créent rarement des diagrammes UML, ne sachant pas forcément à quoi correspondent les treize diagrammes UML.

Une approche par les modèles ne permet qu'à peu de personnes d'avoir les compétences pour modéliser complètement les systèmes. Le MDA nécessite forcément l'implication de professionnels de la modélisation, mais ces personnes sont rares dans les petites structures et chez les industriels. Du coup on peut vite faire le raccourci : MDA est seulement une approche destinée aux grands projets. Cette remarque peut nous faire penser aux similitudes qu'il y a eu avec CORBA, cette norme qui était très compliquée à mettre en place, la répartition des implémentations CORBA a diminué au profit de procédés plus aisés tels que .net ou J2EE.

C. La distinction des modèles

Le MDA différencie les objets de la plate-forme à laquelle ils sont rattachés de ceux qui en sont indépendants. Cependant cette indépendance ne reste qu'un objectif. Derrière ce concept se cache une vérité bien plus complexe. On peut se demander où se trouve la limites entre les modèles ? L'OMG n'a pas donné de définition du terme plate-forme, ainsi la limite qui sépare les modèles PIM et PSM n'est pas franche tant que la définition n'est pas spécifiée. Pour le moment, comme nous l'avons vu dans l'état de l'art, la seule définition c'est qu'un PIM n'est pas un PSM, même si l'idée de PDM aide à affiner cette définition. Cependant, bien que CIM soit apparue, l'objectif reste quand même, au travers de mise en oeuvre (en cas de logique métier conservée), d'identifier ce qui est stable. Les progrès du MDA ne permettent pas à tout le monde de l'utiliser car son utilisation est très souvent destinée à la recherche et aux sociétés impliquées dans la définition de cette norme

* ⁶ Common Object Request Broker Architecture, est une architecture logicielle, pour le développement de composants et d' Object Request Broker où ORB.Corba est un standard maintenu par l' Object Management Group.