Le problème est que la bijectivité parfaite n'existe pas.
Imagine un modèle avec une classe qui comporte des attibuts private et public.
Pour diverses raisons, tu as décidé que ton générateur de code transforme tous les attributs en public dans le code généré de la classe.
Si tu fais un reverse, tu n'as pas moyen de revenir au modèle initial en remettant les bon attributs.
Tu régenères donc une version de modèle qui a tous ses attributs à public et tu t'en remets au modeleur et à ses capacités à merger les modèles pour reconstituer le modèle que tu attends. La transfo inverse ne peut pas être automatique.
Pour une classe ca va, mais pour un projet complet.
C'est pourquoi, on privilégie une approche top down car le roundtrip est beaucoup trop complexe voire inapplicable.
L'autre solution consiste à conserver la tracabilité de la génération (modèle de marquages). La transfo modèle vers code (vu comme un modèle) mémorise chaque relation entre elt du modèle souce et du modèle cible.
Ca marche pas mal avec les modèles parce que tous les elts ont des identifiants immuables.
Avec du code source cet identifiant est dans les commentaires.
Ca reste ardu car il y a plein de cas tordu (cas des surjections: 1elt donne n elt dont 1 seul a changé dans le code , ...)
Je veux bien croire qu'on veuille contraindre son modèle, mais j'ai du mal à comprendre la pertinence de ta limite : si une classe comporte des attributs publics, qu'ils soient rendus comme tel dans le modèle, de même pour les privés, protected.
Bref la bijectivité suppose que le modèle rende compte du code pour ce qu'il sais représenter : essentiellement les prototypes de fonction et la config.
Si ça contrevient à une règle posé, genre celle que tu cite en exemple, eh bien pond un warning, mais va pas dire que c'est pas bijectif :-)
Pour RSM et ClearCase, je t'assure que j'ai jamais vu cette fonction de gestion de modification de source, mais on avait peut être une version trop vieille, je ne sais pas
Même question. Je comprend pas ce que tu veux dire. J'ai pas du être clair.
Tu me disais ds le précédent post que ces outils géraient une sorte de bijectivité, je te répondais que ds la pratique que j'en ai eu, non.
Clearcase n'a effectivement rien à voir, c'est un VCS comme tu le disais, mais tu les citaient plus haut.
C'est avec RSM que je devait faire mes boiboites (j'en ai envie de vomir rien que d'y penser, brrrrrr), et c'est une des interfaces les plus mal pensée et imbitable que j'ai jamais vu.
Tout ça décidé d'en haut par des abrutis qui n'ont jamais eu à y toucher. Voilà les dégats d'ingénieurs au poste de managment qui lisent des plaquettes de pub, et qui croient connaitre parce qu'ils ont codé 10 lignes de java ya 10 ans.
Bref, au minimum, il faut garantir la bijectivité, l'outil dusse t-il sortir une palanqué de warning pour dire qu'il ne sait pas reverser tel chose, ou que ça viole telle ou telle contrainte.
Mais croire qu'on va attirer le développeurs en lui imposant un outil où il doit se débrouiller avec du code généré à partir d'un moment x du projet, j'ai peur que ça marche mal, la pénétration dans le secteur..
PS : Votre techno a 15 ans, il va falloir 15 autres années pour que ça parvienne au cerveau des industriels, on pari ? ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Ontologia (site web personnel) . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 2.
Imagine un modèle avec une classe qui comporte des attibuts private et public.
Pour diverses raisons, tu as décidé que ton générateur de code transforme tous les attributs en public dans le code généré de la classe.
Si tu fais un reverse, tu n'as pas moyen de revenir au modèle initial en remettant les bon attributs.
Tu régenères donc une version de modèle qui a tous ses attributs à public et tu t'en remets au modeleur et à ses capacités à merger les modèles pour reconstituer le modèle que tu attends. La transfo inverse ne peut pas être automatique.
Pour une classe ca va, mais pour un projet complet.
C'est pourquoi, on privilégie une approche top down car le roundtrip est beaucoup trop complexe voire inapplicable.
L'autre solution consiste à conserver la tracabilité de la génération (modèle de marquages). La transfo modèle vers code (vu comme un modèle) mémorise chaque relation entre elt du modèle souce et du modèle cible.
Ca marche pas mal avec les modèles parce que tous les elts ont des identifiants immuables.
Avec du code source cet identifiant est dans les commentaires.
Ca reste ardu car il y a plein de cas tordu (cas des surjections: 1elt donne n elt dont 1 seul a changé dans le code , ...)
Je veux bien croire qu'on veuille contraindre son modèle, mais j'ai du mal à comprendre la pertinence de ta limite : si une classe comporte des attributs publics, qu'ils soient rendus comme tel dans le modèle, de même pour les privés, protected.
Bref la bijectivité suppose que le modèle rende compte du code pour ce qu'il sais représenter : essentiellement les prototypes de fonction et la config.
Si ça contrevient à une règle posé, genre celle que tu cite en exemple, eh bien pond un warning, mais va pas dire que c'est pas bijectif :-)
Pour RSM et ClearCase, je t'assure que j'ai jamais vu cette fonction de gestion de modification de source, mais on avait peut être une version trop vieille, je ne sais pas
Même question. Je comprend pas ce que tu veux dire. J'ai pas du être clair.
Tu me disais ds le précédent post que ces outils géraient une sorte de bijectivité, je te répondais que ds la pratique que j'en ai eu, non.
Clearcase n'a effectivement rien à voir, c'est un VCS comme tu le disais, mais tu les citaient plus haut.
C'est avec RSM que je devait faire mes boiboites (j'en ai envie de vomir rien que d'y penser, brrrrrr), et c'est une des interfaces les plus mal pensée et imbitable que j'ai jamais vu.
Tout ça décidé d'en haut par des abrutis qui n'ont jamais eu à y toucher. Voilà les dégats d'ingénieurs au poste de managment qui lisent des plaquettes de pub, et qui croient connaitre parce qu'ils ont codé 10 lignes de java ya 10 ans.
Bref, au minimum, il faut garantir la bijectivité, l'outil dusse t-il sortir une palanqué de warning pour dire qu'il ne sait pas reverser tel chose, ou que ça viole telle ou telle contrainte.
Mais croire qu'on va attirer le développeurs en lui imposant un outil où il doit se débrouiller avec du code généré à partir d'un moment x du projet, j'ai peur que ça marche mal, la pénétration dans le secteur..
PS : Votre techno a 15 ans, il va falloir 15 autres années pour que ça parvienne au cerveau des industriels, on pari ? ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker