Bonjour,

Je suis en train d'étudier Acceleo et AndroMDA comme solutions pour faire de la génération de code.

J'ai trouvé des avantages et des inconvénients des deux cotés. D'après ce que j'ai pu voir, les points faibles d'Acceleo par rapport à AndroMDA sont les suivants :
* Pas de générateurs de code gratuits
* Pas vraiment de communauté
* Projet très jeune
* Projet open source, mais très lié à Obeo d'après ce que j'ai compris. Le projet ne risque-t-il pas de s'arrêter du jour au lendemain si Obeo change de stratégie?
* Pas d'accès CVS/Subversion

A coté de ça, j'ai trouvé l'utilisation d'Acceleo extremement intuitive comparée à AndroMDA, et les templates Acceleo sont bien plus lisibles que les templates Velocity d'AndroMDA.

J'ai donc du mal à faire mon choix et j'aimerais avoir vos avis et retours d'expériences sur le sujet :)

Merci!

Bonjour et merci beaucoup pour ce message,

Je vais reprendre les points un à un :

* Pas de générateurs de code gratuits

Il y a juste des templates d'exemple sur le site, mais il ne tient qu'à vous, membre de la communauté, de contribuer aussi, et de nous proposer des modules vers des technos cibles de génération, on mettra en place sur le site un systeme de contribution de modules

* Pas vraiment de communauté, Projet très jeune

elle grossit, et c'est avec ce genre de message qu'elle grossira, alors merci, nous en sommes à presque 2000 téléchargements, les retours sont tres positifs, c'est prometteur, il ne faut pas oublier qu'androMDA a été jeune et on se repose sur Eclipse+EMF qui est quand même un gage de fiabilité

* Projet open source, mais très lié à Obeo d'après ce que j'ai compris. Le projet ne risque-t-il pas de s'arrêter du jour au lendemain si Obeo change de stratégie?

Les projets Open Source qui fonctionnent sont souvent soutenus par une ou plusieurs sociétés, c'est le cas d'Acceleo, c'est grace à Obeo qu'on en est là aujourd'hui, et ca ne serait pas vraiment une bonne stratégie pour Obeo de laisser tomber Acceleo, la version 1.1 est en cours de finalisation.....


* Pas d'accès CVS/Subversion
Ca va venir, un peu de patience, pour information on travaille avec Subversion...

A tres bientot

Jonathan

L'accès SVN/Subversion va arriver avec l'intégration du projet dans ObjectWeb qui est en cours...

A+

Merci pour ta réponse si rapide!

Mis à part le coté intuitif et facile d’utilisation, quels sont les avantages d’Acceleo par rapport à AndroMDA ? J’ai pour l’instant noté les points suivants :
* Syntaxe des templates (plus lisible que Velocity)
* Intégration dans Eclipse (on utilise déjà Eclipse)
* Possibilité de définir ses propres méta-modèles en plus de ceux déjà fournis
* Transformation modèle vers modèle
(Les deux derniers points ne nous seront pas utiles dans un premier temps)

Qu’en penses-tu ? As-tu d’autres idées ?

Je cherche des arguments les plus percutants possibles pour convaincre les gens avec qui je travaille d’utiliser Acceleo :).

slacrampe > C'est super, si Acceleo fait parti d'un consortium comme ObjectWeb, ça ne peut jouer qu'en sa faveur niveau crédibilité!

Je rajouterais les points suivants :
- support de la génération incrémentale (je ne suis pas sur que androMda le supporte ausi bien que Acceleo)
- Open Source (comme androMda) mais aussi français... ce qui est pas mal pour un français !
- Prévisualisation en temps réel du résultat de génération (éditeur réflectif)
- Système de lancement de génération (.chain)

A+

Merci pour les arguments :)

En ce qui concerne la génération incrémentale, AndroMDA traite le problème différemment :

Les fichiers qui ne sont pas sensés être modifiés manuellement, sont placés dans un répertoire « target » et sont écrasés à chaque regénération, il s’agit en générale des interfaces et des classes abstraites… Les autres fichiers, ceux destiné à être modifiés/complétés, sont générés qu’une seule fois dans un répertoire « src », de cette manière, les modifications ne sont jamais perdues.

Dans la pratique, je n’ai pas assez de recul pour juger de la meilleure stratégie. Peut être un mixe des deux ?



Modifié 1 fois. Dernière modification le 12/07/06 10:40 par Olivier.

Effectivement, rien n'empêche d'utiliser la stratégie AndroMDA avec Acceleo.
Mon point de vue là dessus est simple : ce n'est pas le générateur de code qui doit dicter l'architecture et l'implémentation du code généré. Utiliser des détours d'héritage et de déléguation parce que l'on fait de la génération de code n'est pas une bonne stratégie à mon sens. Le générateur de code doit être capable de générer la même chose que ce qui aurait été codé à la main, pour deux raisons :
- on doit pouvoir débrancher la génération si on le souhaite !
- on risque arriver à des architectures très complexes si on va dans cette direction, et après on se dit que l'on aurait jamais réussi sans génération de code, mais qu'en est-il des performances résultantes, du debug, du déploiement, etc...

donc attention à ne pas passer du coté obscur : la génération de code est là pour automatiser des tâches manuelles et doit être aussi transparente que possible !

Qui peut le plus, peu le moins.

La méthode employée par AndroMDA peut sans aucun problème s'appliquer à Acceleo.
Pour avoir déjà travailler avec cette problème, plusieurs problèmes se posent à terme dont les performances car souvent, cela multiplie les héritages ou les pattern de délégation (les classes intermédiaires), ce qui implique plus d'objets en mémoire et plus de temps machine perdu.
De plus, cela "casse" l'architecte cible qui doit être pensée différemment à cause du générateur de code.

A mon tour de donner 2-3 arguments : compatibilité native à les modeleurs basés sur EMF (c'est à dire la majorité des nouveaux modeleurs et ceux à venir) et réel support professionnel (ce qui est souvent indispensable pour nombre d'entreprises et pour la pérennité du projet).

Bonjour à tous
Je tiens à remercier les dévelopeurs de ce projet, que j'ai essayé, j'ai été agréablement surpris par les possibilités qu'il offre.
Je suis en train de préparer un exposé dans le cadre de mes etudes, sur MDA et les outils MDA, j'en essayé beaucoups, dont Acceleo . j'ai compris qu'Acceleo été basé sur la GENERATION, le code source devient une feuille de style généré par un document UML.
Ce que je cherche a comprendre: oU est donc le bagage théorique MDA dans ACCELEO, comment puis je acceder aux différents spécification MOF, pour qu'un "BLEU" du MDA puisse comprendre le MDA, puis générer son code grace au moteur d'Acceleo.
Merci d'avance pour la réponse que j'éspére rapide.

Réponse dans le thread :
[www.acceleo.org]

Au sujet des templates et de la communauté :-)

Y a t il déjà un projet pour de simple template de génération de classe java commencé par la communauté ?
Sinon, comment peut on envisager cela ? est ce que ça ne va pas rentrer en concurrence avec les produits payants d'obeo ?

Si tu veux faire des templates java pour la communauté n'hesite pas.
Une section pour les communiquer devrait etre disponible sur ce site courant 2007 Q1.
A bientot

Jonathan

Pour être plus précis, je ne pense pas qu'il y ait de "simple template de génération de classe java" prévu dans la communauté pour le moment. Et Obeo ne commercialise pas cela, donc pas de risque de rentrer en concurrence avec les modules Obeo.

Motivé pour contribuer ?

Stephane



Modifié 2 fois. Dernière modification le 30/12/06 08:22 par slacrampe.

j'ai vu que topcased lançait un projet de génération de code utilisant acceleo. Je pense que je vais me rapprocher d'eux.

J'ai encore pas mal de chose à apprendre à maitriser dans acceleo avant de faire quelque chose de réutilisable avec acceleo. Donc faire petite main sur un autre projet sera plus utile je pense.

Donc, oui motivé :-)

Guillaume

Salut,

On est effectivement en contact rapproché avec Topcased et des générateurs sont en voie de gestation.
Mais tu peux tout à fait le démarrer sur la ferme des modules Acceleo. Il va y avoir plusieurs sections, avec notamment des modules en incubation, donc cela pourrait être l'endroit où tu pourrais démarrer tes travaux, si tu as envie d'aller assez vite. On peut t'envoyer les instructions pour démarrer si tu le souhaites.
De toute façon la ferme référencera aussi bien les modules internes qu'externes...

La zone d'incubation pourra recevoir le soutien d'utilisateurs de Acceleo plus éxpérimentés dans l'optique de passer dans la section des modules "officiels" qui seront en fait labellisés par l'équipe Acceleo.

Peux tu en dire un peu plus sur qui tu es et où tu es localisé ?

Stephane

Désolé de déterrer ce vieux topic, mais il correspond à ce que je recherche...

Peut-être que je me trompe, mais j'ai l'impression qu'il y a à côté des avantages, un désavantage à utiliser accéléo plutôt qu'androMDA.

J'ai l'impression que les métafacades sont beaucoup moins évoluées que celles d'androMDA.
Dans un post que j'ai fait ici récemment, je me demandais comment on pouvait récupérer une propriété d'un stéréotype affecté à une classe. C'est faisable, mais ca demande du développement supplémentaire là ou androMDA le fait sans développement.
Et j'ai peur que cela s'applique à beaucoup d'autres fonctionnalités...

Acceleo n'utilise pas de metafacade pour generer le code
seulement pour tout ce qui est bridge de conversion du monde MDR vers le monde EMF
pour le reste Acceleo a sa propre syntax de navigation dans les modeles qui repose sur EMF, apres pour certains besoin on peut redefinir des methodes java
par exemple dans le cas des stereotypes, vous avez été amené à redefinir une methode getStereotype(String), est ce bien de cela dont il s'agit?
Pourriez vous preciser le probleme car je ne comprends pas trop vos inquietudes...
Les stereotypes sont specifiques au monde UML et Acceleo n'est pas fait 'que' pour le monde UML, c'est pour cela qu'il y a 2-3 services qui n'existent pas nativement... Ils sont assez rares et isolés... Apres surtout n'hesitez pas à revenir nous faire part des problemes que vous rencontrez
N'hesitez pas egalement à regarder les exemples UML de la ferme de modules...

Cordialement