L'objectif n'est pas de générer tout le code mais comme tu le dis les composantes techniques à faible valeur ajoutée.
On a renoncé depuis longtemps à spécifier les aspects dynamiques d'un système au niveau le plus bas.
Mais ce qui me fait marrer, c'est qu'on continue à dessiner des boiboites, qui sémantiquement ne valent rien : un User est une simple boiboite avec le titre User, et des champs à l'intérieur.
Sauf que tu ne critiques pas le bon outil. Ici c'est le modeleur mais on peut parfaitement définir son propre langage de modélisation dédié (Domain Spécific Language) y compris purement textuels (voir le projet xText).
Ensuite ici, il existe des modeleurs UML en mode texte qui peuvent faire l'affaire et tu n'es pas non plus obligé de faire un diagramme de classe, ca n'est qu'une démo.
Sinon cet usage des DSL en lieu et place de l'UML se démocratise maintenant que les outils commencent à arriver à maturité(voir Eclipse Modeling Framework)
Et là Acceleo et d'autre générateurs Eclipse répondent aussi à ton besoin.
Après, il y a une chose que tu oublies avec cette approche, c'est qu'elle centralise tes informations. A partir du même modèle tu peux aussi générer toute la tuyauterie pour les web services, cibler une autre architecture dans un environnement hétérogène, migrer vers un autre framework, ...
L'avantage c'est que toutes les parties prenantes partagent le même modèle et parlent le même langage. Ca facilite les échanges et c'est plus simple d'envoyer un bout de modèle à des développeurs de la couche noyau et à ceux qui sont chargés du middleware et de regénérer les docs de specs pour les AMOs, que de mettre à jour qui les WSDL, qui les contrats d'interface et qui les documents à la main.
Pire on voit à quel point c galère d'expliquer que la fonction findCategoryByName a un param String, ça prend 3 fois plus de temps que l'écrire, faut cliquer partout !
Ici, c'est comme le paradigme "convention over configuration". Ca te génère avec des présupposés. Ensuite, tu peux éditer ton code ou surcharger le modèle pour prendre en charge les spécificités. Libre à toi de choisir. Après, cette information saisie dans le modèle peut-être utile pour d'autres régénérations ultérieures (modèles qui évoluent en fonction des specs) ou pour d'autres cibles.
Mais si tu veux du "one shot", évidemment, c'est une perte de temps.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 3.
On a renoncé depuis longtemps à spécifier les aspects dynamiques d'un système au niveau le plus bas.
Mais ce qui me fait marrer, c'est qu'on continue à dessiner des boiboites, qui sémantiquement ne valent rien : un User est une simple boiboite avec le titre User, et des champs à l'intérieur.
Sauf que tu ne critiques pas le bon outil. Ici c'est le modeleur mais on peut parfaitement définir son propre langage de modélisation dédié (Domain Spécific Language) y compris purement textuels (voir le projet xText).
Ensuite ici, il existe des modeleurs UML en mode texte qui peuvent faire l'affaire et tu n'es pas non plus obligé de faire un diagramme de classe, ca n'est qu'une démo.
Sinon cet usage des DSL en lieu et place de l'UML se démocratise maintenant que les outils commencent à arriver à maturité(voir Eclipse Modeling Framework)
Et là Acceleo et d'autre générateurs Eclipse répondent aussi à ton besoin.
Après, il y a une chose que tu oublies avec cette approche, c'est qu'elle centralise tes informations. A partir du même modèle tu peux aussi générer toute la tuyauterie pour les web services, cibler une autre architecture dans un environnement hétérogène, migrer vers un autre framework, ...
L'avantage c'est que toutes les parties prenantes partagent le même modèle et parlent le même langage. Ca facilite les échanges et c'est plus simple d'envoyer un bout de modèle à des développeurs de la couche noyau et à ceux qui sont chargés du middleware et de regénérer les docs de specs pour les AMOs, que de mettre à jour qui les WSDL, qui les contrats d'interface et qui les documents à la main.
Pire on voit à quel point c galère d'expliquer que la fonction findCategoryByName a un param String, ça prend 3 fois plus de temps que l'écrire, faut cliquer partout !
Ici, c'est comme le paradigme "convention over configuration". Ca te génère avec des présupposés. Ensuite, tu peux éditer ton code ou surcharger le modèle pour prendre en charge les spécificités. Libre à toi de choisir. Après, cette information saisie dans le modèle peut-être utile pour d'autres régénérations ultérieures (modèles qui évoluent en fonction des specs) ou pour d'autres cibles.
Mais si tu veux du "one shot", évidemment, c'est une perte de temps.