A partir du moment où tu génères du code à partir d'un modèle tu as plusieurs voies possibles.
Si tu te lances dans du refactoring à tout va et que tu retouches le code généré en dehors des sentiers battus (balise preserved), ton modèle et ton code divergent et la moindre régénération de code suite à une évolution de ton architecture ou des specs va te lancer dans un interminable merge de ton code. Au fil du temps modèle et code sont de plus en plus éloignés et les réconciliations deviennent contre-productives.
Partant de ce constat:
Soit tu n'envisages le modèle uniquement que pour faire du one shot et tu peux effectivement douter de l'utilité des modèles (ecole du sketch modeling, on modélise sur un tableau pour des besoins ponctuels)
Soit tu essaies de ne pas trop faire diverger ton modèle et ton code
Soit tu te donnes les moyens de réconcilier les divergences.
Si tu adoptes une approche descendante. Tu te dois de respecter les zones de code non éditables et tout ce qui peut être ecrasé par le générateur.
L'aspect incrémental peut-être est assuré par l'outil de transfo (identifiants dans le code généré+balise preserve) ou par l'outil de gestion de version qui sait gérer le merge mieux que personne puisque c'est son rôle. Il est vrai que ca peut être un peu contraignant comme tu l'évoques mais une chaîne de travail bien pensée peut apporter un gain. Il faut aussi savoir se limiter sur ce qu'on veut générer.
Si on choisit de générer certaines parties du code c'est qu'on pense qu'il y un gain en terme de cohérence au niveau de ton archi. Le but n'est pas seulement de cracher un maximum de code automatiquement.
C'est toute la difficulté de l'exercice. Ne pas en faire trop.
Si malgré tout, tu veux te laisser la liberté de diverger au niveau du code en cassant les associations, en refactorant les classes ou les packages, en modifiant tes contrats de WSDL à la mano, ... tu as besoin de mettre en place une transformation inverse c'est à dire du code vers le modèle. Le problème est: que se passe t'il si ton modèle a aussi évolué entretemps. Tu te retrouves avec 2 versions de modèles à réconcilier, l'une modifiée à la main, l'autre obtenue par rétro-ingénierie.
Sans un bon outil qui te permet (cf. EMF Compare pour te faire une idée) de faire des merges de modèles et qui t'évite de te répeter tu es dans l'impasse (merge tracking)
Là où c'est assez drôle c'est que la suite que tu critiques (RSM + Clearcase je suppose) est à ma connaissance la seule qui prenne en charge ca à peu près correctement mais je l'opensource avance de son coté (cf Expand, Acceleo, EMF Compare, ...).
Tout ceci nous ramène une problématique classique de versionning.
Il faut y aller petit pas par petit pas pour ne pas faire de merge big-bang.
El là où ca devient intéressant c'est qu'on peut créer des modèles adaptés et compréhensibles par ceux à qui on s'adresse (modèle de processus métiers pour les Business Analyst, modèles d'analyse, modèles de conception, maquettes d'IHM, ...) tout ça grâce aux DSLs (Domain Specific Language) y compris textuels (cf. Xtext) ou à l'UML profilé. Si on dispose de transformations Modèle vers Modèle et d'un bon outillage ceci n'est pas hors d'atteinte et l'aspect incrémental consolide la chaîne.
Après je suis d'accord que ca peut devenir complexe, mais la réalité de ces projets est complexe et les gains se font sur l'échelle.
Je sais que je ne te convaincrai pas mais j'ai la faiblesse de croire que ca marche pas trop mal pour certains projets que j'ai pu croiser.
[^] # 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é à 2.
Si tu te lances dans du refactoring à tout va et que tu retouches le code généré en dehors des sentiers battus (balise preserved), ton modèle et ton code divergent et la moindre régénération de code suite à une évolution de ton architecture ou des specs va te lancer dans un interminable merge de ton code. Au fil du temps modèle et code sont de plus en plus éloignés et les réconciliations deviennent contre-productives.
Partant de ce constat:
Soit tu n'envisages le modèle uniquement que pour faire du one shot et tu peux effectivement douter de l'utilité des modèles (ecole du sketch modeling, on modélise sur un tableau pour des besoins ponctuels)
Soit tu essaies de ne pas trop faire diverger ton modèle et ton code
Soit tu te donnes les moyens de réconcilier les divergences.
Si tu adoptes une approche descendante. Tu te dois de respecter les zones de code non éditables et tout ce qui peut être ecrasé par le générateur.
L'aspect incrémental peut-être est assuré par l'outil de transfo (identifiants dans le code généré+balise preserve) ou par l'outil de gestion de version qui sait gérer le merge mieux que personne puisque c'est son rôle. Il est vrai que ca peut être un peu contraignant comme tu l'évoques mais une chaîne de travail bien pensée peut apporter un gain. Il faut aussi savoir se limiter sur ce qu'on veut générer.
Si on choisit de générer certaines parties du code c'est qu'on pense qu'il y un gain en terme de cohérence au niveau de ton archi. Le but n'est pas seulement de cracher un maximum de code automatiquement.
C'est toute la difficulté de l'exercice. Ne pas en faire trop.
Si malgré tout, tu veux te laisser la liberté de diverger au niveau du code en cassant les associations, en refactorant les classes ou les packages, en modifiant tes contrats de WSDL à la mano, ... tu as besoin de mettre en place une transformation inverse c'est à dire du code vers le modèle. Le problème est: que se passe t'il si ton modèle a aussi évolué entretemps. Tu te retrouves avec 2 versions de modèles à réconcilier, l'une modifiée à la main, l'autre obtenue par rétro-ingénierie.
Sans un bon outil qui te permet (cf. EMF Compare pour te faire une idée) de faire des merges de modèles et qui t'évite de te répeter tu es dans l'impasse (merge tracking)
Là où c'est assez drôle c'est que la suite que tu critiques (RSM + Clearcase je suppose) est à ma connaissance la seule qui prenne en charge ca à peu près correctement mais je l'opensource avance de son coté (cf Expand, Acceleo, EMF Compare, ...).
Tout ceci nous ramène une problématique classique de versionning.
Il faut y aller petit pas par petit pas pour ne pas faire de merge big-bang.
El là où ca devient intéressant c'est qu'on peut créer des modèles adaptés et compréhensibles par ceux à qui on s'adresse (modèle de processus métiers pour les Business Analyst, modèles d'analyse, modèles de conception, maquettes d'IHM, ...) tout ça grâce aux DSLs (Domain Specific Language) y compris textuels (cf. Xtext) ou à l'UML profilé. Si on dispose de transformations Modèle vers Modèle et d'un bon outillage ceci n'est pas hors d'atteinte et l'aspect incrémental consolide la chaîne.
Après je suis d'accord que ca peut devenir complexe, mais la réalité de ces projets est complexe et les gains se font sur l'échelle.
Je sais que je ne te convaincrai pas mais j'ai la faiblesse de croire que ca marche pas trop mal pour certains projets que j'ai pu croiser.