Attention quand je parle de méta-modèle spécifiques je suis bien loin d'UML ! Le module JEE utilise un modèle UML stéréotypé qui est exploité pour piloter la génération, si l'on regarde la démo on voit bien que le paramétrage reste simple et permet d'obtenir un résultat respectant un les bonnes pratiques d'architectures et d'utilisation des frameworks.
Acceleo ne masque rien et les décisions ne sont pas arbitraires, on est bien sur une "boite blanche" !
'Par exemple, comment agréger plusieurs contrats d'objet métier en un seul service si on masque ce modèle intermédiaire => intervention au niveau du code généré et reverse au lieu de personnaliser le modèle)
Nop, tout l'inverse ! 2 possibilités :
1 - Le module de génération gère déjà ce cas, donc on paramètre soit via un stéréotype soit via un fichier de paramétrage.
2 - Le module de génération n'a pas prévu ce cas : on l'étend en ne redéfinissant que ce que l'on souhaite changer pour qu'il exploite un stéréotype ou un fichier de paramétrage.
D'où la syntaxe simple et l'outillage qui facilite la prise en main !
Avec une transformation M2M on obtient l'équivalent de la première étape et on laisse apparaître ce modèle intermédiaire que l'on peut enrichir et ce sans recourir à de la programmation EMF basique.
CF mon commentaire au dessus, la transformation M2M est parfois intéressante et dans ce cas Acceleo fonctionne parfaitement bien avec ATL/QVT, souvent elle séduit le décideur mais alourdi considérablement le processus de développement.
Quid de la mise à jour et de la maintenance de ce modèle intermédiaire ? Quand je change le modèle métier de départ, qu'est-ce qui change dans le modèle intermédiaire ? Quels réglages sont conservés au risque de fournir un résultat non correct ? Toutes ces questions sont importantes à traiter dans le cas d'une mise en oeuvre M2M, on peut citer par exemple Eclipse GMF avec les fichier gmfgen qui sont issus du fichier gmfmap. Leur maintenance/mise à jour peut vite tourner au casse tête et on en vient vite à préconiser de faire les changements dans le code et non pas dans le modèle de paramétrage !
[^] # 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é à 3.
Acceleo ne masque rien et les décisions ne sont pas arbitraires, on est bien sur une "boite blanche" !
'Par exemple, comment agréger plusieurs contrats d'objet métier en un seul service si on masque ce modèle intermédiaire => intervention au niveau du code généré et reverse au lieu de personnaliser le modèle)
Nop, tout l'inverse ! 2 possibilités :
1 - Le module de génération gère déjà ce cas, donc on paramètre soit via un stéréotype soit via un fichier de paramétrage.
2 - Le module de génération n'a pas prévu ce cas : on l'étend en ne redéfinissant que ce que l'on souhaite changer pour qu'il exploite un stéréotype ou un fichier de paramétrage.
D'où la syntaxe simple et l'outillage qui facilite la prise en main !
Avec une transformation M2M on obtient l'équivalent de la première étape et on laisse apparaître ce modèle intermédiaire que l'on peut enrichir et ce sans recourir à de la programmation EMF basique.
CF mon commentaire au dessus, la transformation M2M est parfois intéressante et dans ce cas Acceleo fonctionne parfaitement bien avec ATL/QVT, souvent elle séduit le décideur mais alourdi considérablement le processus de développement.
Quid de la mise à jour et de la maintenance de ce modèle intermédiaire ? Quand je change le modèle métier de départ, qu'est-ce qui change dans le modèle intermédiaire ? Quels réglages sont conservés au risque de fournir un résultat non correct ? Toutes ces questions sont importantes à traiter dans le cas d'une mise en oeuvre M2M, on peut citer par exemple Eclipse GMF avec les fichier gmfgen qui sont issus du fichier gmfmap. Leur maintenance/mise à jour peut vite tourner au casse tête et on en vient vite à préconiser de faire les changements dans le code et non pas dans le modèle de paramétrage !