Le code généré est relativement simple, et donc ne présente pas réellement d'intérêt. Il ne gérait pas très bien les modifs de schémas.
C'est là qu'intervient Acceleo et les autres (JET, openArchitectureWare, MOFscript, ...), comme les outils fournis en standard avec les modeleurs UML visent la généricité, ils ne peuvent pas générer grand chose (au mieux les squelettes du code) et en plus il y a de fortes chance que ça ne colle pas à tes règles métier. Pour aller plus loin, il te faut définir un profil UML ou un DSL (Domain specific language) qui est propre à ton métier (comme ceux proposés dans la news) et développer/adapter un générateur de code maison. Aujourd'hui avec des solutions comme Acceleo ça devient un jeu d'enfant et on peut faire des générations de large parties du code (celles pénibles à codé ou source d'erreur fréquentes) simplement. Par exemple refaire un générateur du style de celui de RSM est l'affaire de qq jours (et non j'ai pas d'action chez eux ;-) )
Il faut s'enlever de l'idée (pour le moment ?) qu'un modeleur UML aussi bon soit-il va te permettre de faire du MDD sorti de la boite. Mettre en place un process orienté modèle demande des développement proprio et de l'investissement (générateur de code, transformateurs de modèles, vérif sur ces modèles, ...). Sur des projets un peu gros, ça peu être très rapidement super rentable.
Je suis assez étonné que l'approche a base de modèle n'ai pas plus de succès que ça dans les grands projets libres, pourtant c'est ceux qui ont la plus grande flexibilité pour mettre en place ces solutions et pour en tirer avantage (productivité plus forte, meilleure homogénéité du code, meilleure intégration des nouveaux, ...). De même avec des frameworks comme RoR, on pourrait faire des trucs super puissants en modélisant l'appli et ensuite en générant une grande partie du code (genre le modèle de données, une partie des contrôleurs, ...)
En fin de compte, c'est assez difficile de
modéliser un cas assez technique, pas sûr que ca ait apporté une lisibilité supplémentaire.
Les graphes obtenus par des clics de souris sont longs à faire et à modifier.
Je vais être caricatural... RSM n'a pas que des qualités, loin de là, mais le problème est que RSM n'est pas un outil de dessin... Le but à la fin est d'avoir un modèle à partir duquel tu peux faire qqch générer du code, faire des analyses, produire d'autres modèle, ...). Pour faire des "dessins UML" vaut mieux prendre PowerPoint ou Dia pour faire libre tu auras un meilleur rendu plus simplement...
Finalement, en ce qui me concerne en tout cas, je pense qu'il vaut mieux que je commence le code assez tôt, même si la modélisation n'est pas encore terminée, quitte à la faire évoluer au fur et à mesure.
Dans une approche MDE c'est la transformation du modèle vers le code qui te permet de commencer à coder (même si plusieurs itérations sont possibles). Je suis d'accord que pour le moment
les outils sont assez lourds et mal foutus, mais ça s'améliore de plus en plus et le jeu en vaut carrément la chandelle !
[^] # Re: Modelisation vs Code
Posté par gege (site web personnel) . En réponse à la dépêche Acceleo 2.3 compatible Eclipse Ganymede. Évalué à 6.
C'est là qu'intervient Acceleo et les autres (JET, openArchitectureWare, MOFscript, ...), comme les outils fournis en standard avec les modeleurs UML visent la généricité, ils ne peuvent pas générer grand chose (au mieux les squelettes du code) et en plus il y a de fortes chance que ça ne colle pas à tes règles métier. Pour aller plus loin, il te faut définir un profil UML ou un DSL (Domain specific language) qui est propre à ton métier (comme ceux proposés dans la news) et développer/adapter un générateur de code maison. Aujourd'hui avec des solutions comme Acceleo ça devient un jeu d'enfant et on peut faire des générations de large parties du code (celles pénibles à codé ou source d'erreur fréquentes) simplement. Par exemple refaire un générateur du style de celui de RSM est l'affaire de qq jours (et non j'ai pas d'action chez eux ;-) )
Il faut s'enlever de l'idée (pour le moment ?) qu'un modeleur UML aussi bon soit-il va te permettre de faire du MDD sorti de la boite. Mettre en place un process orienté modèle demande des développement proprio et de l'investissement (générateur de code, transformateurs de modèles, vérif sur ces modèles, ...). Sur des projets un peu gros, ça peu être très rapidement super rentable.
Je suis assez étonné que l'approche a base de modèle n'ai pas plus de succès que ça dans les grands projets libres, pourtant c'est ceux qui ont la plus grande flexibilité pour mettre en place ces solutions et pour en tirer avantage (productivité plus forte, meilleure homogénéité du code, meilleure intégration des nouveaux, ...). De même avec des frameworks comme RoR, on pourrait faire des trucs super puissants en modélisant l'appli et ensuite en générant une grande partie du code (genre le modèle de données, une partie des contrôleurs, ...)
En fin de compte, c'est assez difficile de
modéliser un cas assez technique, pas sûr que ca ait apporté une lisibilité supplémentaire.
Les graphes obtenus par des clics de souris sont longs à faire et à modifier.
Je vais être caricatural... RSM n'a pas que des qualités, loin de là, mais le problème est que RSM n'est pas un outil de dessin... Le but à la fin est d'avoir un modèle à partir duquel tu peux faire qqch générer du code, faire des analyses, produire d'autres modèle, ...). Pour faire des "dessins UML" vaut mieux prendre PowerPoint ou Dia pour faire libre tu auras un meilleur rendu plus simplement...
Finalement, en ce qui me concerne en tout cas, je pense qu'il vaut mieux que je commence le code assez tôt, même si la modélisation n'est pas encore terminée, quitte à la faire évoluer au fur et à mesure.
Dans une approche MDE c'est la transformation du modèle vers le code qui te permet de commencer à coder (même si plusieurs itérations sont possibles). Je suis d'accord que pour le moment
les outils sont assez lourds et mal foutus, mais ça s'améliore de plus en plus et le jeu en vaut carrément la chandelle !