August 2010 - Eugene-devel - mailman.cloud.codelutin.com

[ANN] - EUGene 2.1.2 released
by nuiton.org Release Notification Aug. 29, 2010

Aug. 29, 2010

1 0

Écriture des méta-transformeurs (CR réflexion avec Ben)
by Brendan Le Ny Aug. 18, 2010

Aug. 18, 2010

Comme je suis en train de ré-écrire toute la génération de Wikitty en utilisant des transformeurs, je dois écrire un méta-transformeur pour faire la tuyauterie. Le problème que j'ai est de pouvoir exprimer quels modèles sont générés à partir de quels autres. Il faut vraiment gérer les instances de modèles générés de façon fine parce qu'on peut vouloir passer à deux transformeurs différents exactement un même modèle. Par exemple, j'ai un transformeur qui fait de la résolution de conflits, un même modèle passé en entrée peut donner des sorties différentes (pour peu que Eugene air passé dans le transformeurs les différents éléments du modèle d'entrée dans des ordres différents). Actuellement, pour décrire un méta-modèle : on fait public WikittyMetaTransformer() { super(WikittyContractGenerator.class, WikittyAbstractGenerator.class, WikittyImplementationGenerator.class, WikittyHelperGenerator.class ); } C'est tout à fait suffisant quand on a que des générateurs, mais avec les transformeurs, ça ne suffit pas. Dans cette exemple, j'ai deux générateurs qui instancient le transformeur de gestion de conflit, du coup, j'ai deux gestions de conflits différentes et on risque d'aboutir à deux résolutions différentes. transform(Model model) { WikittyPurifierTransformer purifier = new WikittyPurifierTransformer(); Model purifiedModel = purifier.transform(model); WikittyContractGenerator contractGen = new WikittyContractGenerator(); WikittyAbstractGenerator abstractGen = new WikittyContractGenerator(); Model contracts = contractGen.transform(purifiedModel); Model abstracts = abstractGen.transform(purifiedModel); // enfin, pour générer le Java un truc du genre ObjectModelToJava toJava = new ObjectModelToJava(destDir); toJava.transform(contracts); toJava.transform(abstracts); } Quelque chose du genre permet de chaîner les transformeurs comme on veut et de répondre à l'essentiel des besoins. On pourrait également imaginer les choses suivantes, afin de faire de la transformation à partir du texte généré (XML ?) et chaîner les méta-transformers toJava.transform(contracts) par exemple retourne une List<GeneratedFile>, les éléments de ces listes permettent d'accéder au nom du fichier générer, au contenu. Éventuellement, on pourrait ne pas spécifier de destDir à la construction et récupérer les GeneratedFile pour les écrire soi-même et les envoyer vers un reader. Ainsi un peu chaîner des transformeurs, et dans des situations exceptionnelles faire passer le chaînage par du texte, par exemple, pour réutiliser un métatransformer qui attend un objectmodel en sortie, je peux sortir un objectmodel et chaîner les méta-transformeurs Réflexions et commentaires bienvenus, je crois que c'est en gros ce qu'on a déjà dit avec Tony mais ce serait bien que d'autres se prononcent vu qu'il s'agit quand même d'un aspect important de Eugene en général et des transformeurs, en particulier.

2 1

réflexions sur l'API de ObjectModelTransformerToJava
by Brendan Le Ny Aug. 12, 2010

Aug. 12, 2010

addAttribute(Classifier, ObjectModelAttribute) existe alors que addOperation(Classifier, ObjectModelOperation) n'existe pas Je crois que le premier ne devrait pas exister, et qu'il devrait plutôt s'agir d'un cloneAttribute. ObjectModelAttribute.getVisibility() retourne String, on devrait pas plutôt retourner un ObjectModelModifier ? Quelques méthodes manquantes : setDescription(ObjectModelElement element, String description) addComment(ObjectModelElement element, String comment) addStereotype(ObjectModelElement element, String stereotypeName) setMinMultiplicity(ObjectModelAttribute attribute, int multiplicity) setMaxMultiplicity(ObjectModelAttribute attribute, int multiplicity) et aussi, en fonction de ce que je dis plus haut setVisibility(ObjectModelAttribute attribute, ObjectModelModifier visibility); // et pas String visibility

2 2

Méthodes exotiques ? ou pas
by Tony Chemit Aug. 12, 2010

Aug. 12, 2010

Salut, Dans la classe ObjectModelElementImpl, il y a deux méthodes : public ObjectModelImplRef addStereotype(ObjectModelImplRef stereotype) { if (stereotype == null) { return new ObjectModelImplRef(); } stereotypes.add(stereotype.getName()); return stereotype; } public ObjectModelImplTagValue addTagValue(ObjectModelImplTagValue tagValue) { if (tagValue == null) { return new ObjectModelImplTagValue(); } addTagValue(tagValue.getName(), tagValue.getValue()); return tagValue; } Ce code est des plus étrange : on crée un objet pour ensuite utiliser juste leur élément (clef-valeur pour les tag values). Ce qui me dérange plus c'est d'avoir une méthode add qui crée des objets et les renvoie. Je ne parle pas ici des noms des objets avec des Impl au milieu des noms (c'est un autre débat). Je suppose que ce code a une raison d'être, même si je ne la comprends pas, de plus aucune javadoc, donc impossible de savoir pourquoi c'est là. si quelqu'un a un souvenir (moi je pense fortement à digester mais sans conviction), qu'il parle :) cordialement, tony. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit(a)codelutin.com http://www.codelutin.com

2 1