|
Même les experts ne parviennent pas à se mettre d’accord sur la question de l’architecture pilotée par les modèles (MDA). Un débat récent entre deux experts reconnus de l’industrie du logiciel, Carl Zetie et David Frankel, a permis d’analyser les différences entre la « MDA pragmatique » et la MDA de l’Object Management Group (OMG). Mais comme vous le verrez, chacune de ces approches offre aux développeurs les avantages d’une productivité et d’une qualité accrues, ainsi qu’une plus grande harmonisation avec les objectifs de l’entreprise.
Récemment, Carl Zetie, Vice-président de Forrester Research, a publié un article, intitulé « La MDA est une architecture orientée vers le développement, en partie grâce à l’architecture orientée services (SOA) », dans lequel il décrivait les raisons qui contribuent au faible taux d’adoption de l’approche MDA par les équipes de développement des entreprises. Les clients de Forrester ont indiqué que la MDA, telle que décrite par l’Object Management Group, présentait des inconvénients parmi lesquels des pratiques restrictives et dogmatiques, qui étouffent la productivité des équipes de développement. L’auteur s’est prononcé en faveur d’une mise en œuvre plus pragmatique des principes MDA, avec plus de souplesse. Il a souligné à quel point des implémentations de « MDA pragmatique » permettraient de conjuguer une modélisation utile tout en conservant une certaine proportion de génération de codes dans le processus de développement. Pour lui, Compuware OptimalJ est un outil pointu de transformation et de génération [...] de codes et de modèles. Ce qui signifie qu’OptimalJ ajoute de la valeur au processus de développement, en ce sens qu’il fournit de la valeur métier à l’entreprise.
L’article a contrarié David Frankel, Responsable de l’architecture et des normes informatiques pour les laboratoires SAP, et auteur de « Model Driven Architecture : Applying MDA to Entreprise computing » (« Architecture pilotée par les modèles : Appliquer l’approche MDA à l’informatique d’entreprise »). Dès le début de son article, il affirme que Compuware OptimalJ est tout à fait conforme aux normes MDA. Une approche qui mélange la génération automatique de codes et l’écriture manuelle de codes peut être considérée selon lui comme « MDA pragmatique », mais surtout pas comme MDA tel que l’entend l’OMG. En indiquant que l’approche MDA est loin d’être difficilement applicable ou dépassée comme le suggère C. Zetie. D. Frankel réfute la notion selon laquelle l’architecture MDA est par nature un modèle en cascade dans son approche, et poursuit en expliquant de quelle manière le cycle de vie du développement de logiciels MDA est itératif. Il cite plusieurs experts qui considèrent que le MDA permet de tirer parti des découvertes de l’industrie dans le développement basé sur les composants. Il décrit également le rôle important que joue la gestion des métadonnées dans l’architecture MDA. Toutes ces définitions formelles de l’architecture MDA permettent d’améliorer la conception et la livraison des logiciels, et sont toutes présentes dans OptimalJ.
Il n’est pas question ici de débattre de la valeur des arguments de C. Zetie ou de D. Frankel. Dans leurs descriptions des meilleures pratiques, ils utilisent tous deux OptimalJ comme exemple de mise en œuvre MDA de leur approche. Il est possible de développer rapidement des applications de haute qualité de manière souple et itérative, avec l’architecture MDA. Comme vous le savez, les développeurs OptimalJ veulent des résultats. C’est là l’aspect essentiel !
Si vous souhaitez télécharger une copie d’OptimalJ 4.1, je vous invite à évaluer ce que Mike Riley, dans son étude de produits MDA publié dans le magazine Software Development, appelle « l’un des meilleurs outils MDA du marché pour le développement J2EE » et « le chef d’œuvre de Compuware ».
|
