La réalité c'est les désormais nombreux projets qui exploitent cette démarche, et Acceleo en particulier, au sein de SSII et d'administrations :)
Acceleo est justement né de l'expérience autour de la manipulation des autres outils que tu cite, pour "la vrai vie" et réaliser de "vrai projets", les choix effectués sont bien plus pragmatiques : simplicité, itérations courtes, intégration avec l'environnement de développement.
Les transformations de modèle, bien que séduisantes sur le papier, montrent vite leurs limites justement dans la "vrai vie". Ajouter cette étape de transformation complexifie le cycle modèle -> code et augmente les possibilité d'erreurs.
En terme de viabilité, ATL comme QVT operational et QVT relations n'ont vraiment rien à envier vis à vis des solutions propriétaires, ces langages ont été pensés par la recherche voir standardisé, ont une portée internationale et ont été éprouvés sur de nombreux projets.
Par contre, et là je te rejoins, un modèle dit de "paramétrage" peut souvent être exploité pour affiner la transformation dans la mesure où le paramétrage reste simple et que l'on peut le valider !
En effet j'ai déjà vu sur des projet des modèles de paramétrage sur un modèle UML par le biais de stéréotypes, la maintenance de cette partie du modèle UML était cruciale car toute la génération en dépendait, et il a été nécessaire de repartir sur une version "stable" du modèle de nombreuses fois pendant le projet, engendrant frustration et inefficacité.
Ces points sont primordiaux pour l'acceptation de la démarche au sein des projet, un simple fichier .properties contenant des clé/valeurs pour le paramétrage est souvent beaucoup plus efficace qu'un modèle du point du vue du développeur. Beaucoup de choses décrites par l'OMG semblent mieux de prime abord, l'expérience montre que ce n'est pas forcément le cas, ne gardons que ce qui est intéressant !
[^] # Re: Du code vers le modèle?
Posté par Cédric Brun . En réponse à la dépêche Acceleo 2.2.0 : nouveaux générateurs PHP, Python et JEE. Évalué à 2.
Acceleo est justement né de l'expérience autour de la manipulation des autres outils que tu cite, pour "la vrai vie" et réaliser de "vrai projets", les choix effectués sont bien plus pragmatiques : simplicité, itérations courtes, intégration avec l'environnement de développement.
Les transformations de modèle, bien que séduisantes sur le papier, montrent vite leurs limites justement dans la "vrai vie". Ajouter cette étape de transformation complexifie le cycle modèle -> code et augmente les possibilité d'erreurs.
En terme de viabilité, ATL comme QVT operational et QVT relations n'ont vraiment rien à envier vis à vis des solutions propriétaires, ces langages ont été pensés par la recherche voir standardisé, ont une portée internationale et ont été éprouvés sur de nombreux projets.
Par contre, et là je te rejoins, un modèle dit de "paramétrage" peut souvent être exploité pour affiner la transformation dans la mesure où le paramétrage reste simple et que l'on peut le valider !
En effet j'ai déjà vu sur des projet des modèles de paramétrage sur un modèle UML par le biais de stéréotypes, la maintenance de cette partie du modèle UML était cruciale car toute la génération en dépendait, et il a été nécessaire de repartir sur une version "stable" du modèle de nombreuses fois pendant le projet, engendrant frustration et inefficacité.
Ces points sont primordiaux pour l'acceptation de la démarche au sein des projet, un simple fichier .properties contenant des clé/valeurs pour le paramétrage est souvent beaucoup plus efficace qu'un modèle du point du vue du développeur. Beaucoup de choses décrites par l'OMG semblent mieux de prime abord, l'expérience montre que ce n'est pas forcément le cas, ne gardons que ce qui est intéressant !