Acceleo est un générateur de code (transformation modèle vers texte) capable d'exploiter n'importe quel modèle EMF (modèle UML mais aussi modèle métier ou encore fichier XML) pour générer du texte à l'aide d'un langage de template. Ce générateur de code a la particularité d'être incrémental, c'est-à-dire qu'il est possible de modifier le code généré puis de re-générer sans perdre ses modifications.
Cette nouvelle version améliore l'expérience utilisateur en fournissant une nouvelle fonctionnalité de "recherche des appels d'un script" (CTRL+MAJ+G), elle permet également d'appeler les méthodes définies sur un métamodèle directement depuis un script et elle améliore la compatibilité avec les modeleurs UML "non Eclipse". Pour plus de détails, jetez un oeil sur la page des nouveautés en images.
Acceleo est un outil qui permet de définir soit même son module de génération pour un langage et un framework donné, par exemple UML vers C, mais c'est aussi une ferme de modules communautaires que l'on peut ré-utiliser et modifier. Les modules présents avec la version 2.3 sont les suivants: UML vers PHP/Smarty/Pear, UML vers JEE/Hibernate/Spring, UML vers CSharp/NHibernate, mais aussi le nouveau module UML vers Dolibarr ou encore des modules exploitant des modèles beaucoup plus simples: Ecore vers Python et WISSS (modèle dédié au applications web vers PHP/Zend). D'autres modules sont présents sur le SVN et peuvent être modifiés ou améliorés, comme par exemple un module UML vers Plone et UML vers Pylons.
Tous ces modules ont différents degrés de qualité et un certain nombre sont encore considérés comme "en incubation" mais vous pouvez aussi définir le vôtre. Les éditeurs proposent la colorisation syntaxique, l'auto-complétion, la prévisualisation du code généré ainsi qu'un debugger interactif.
Pour tester Acceleo la voie royale est le pack Eclipse "tout en un": sur le site sont fournies des archives contenant Acceleo, ainsi que ses dépendances et les modules, mais aussi différents outils dédiés à la modélisation sous Eclipse comme par exemple ATL pour faire des transformations modèle à modèle, Topcased pour la modélisation UML ou encore EMF Compare pour comparer et fusionner les modèles.
Vous pouvez aussi découvrir différentes démos qui détaillent l'utilisation de certains modules.
NdM: Acceleo est publié sous licence EPL, licence libre et Open Source, non-copyleft et incompatible GPL. Acceleo permet d'exploiter un modèle pour générer du texte, cette approche peut prendre différentes formes. Certains prônent la modélisation à 100% (il devient inutile de développer), d'autres ne jurent que par les standards (UML par exemple) et d'autres encore visent à l'exploitation de modèles spécifiques à un métier. Il n'y a pas de solution parfaite, cela dépend du contexte d'utilisation et du résultat souhaité, mais en aucun cas Acceleo ne fait ce choix pour vous. Vous pouvez tout à fait faire un générateur qui va faire correspondre à une classe UML une classe Java, ou alors pour une classe UML décider de générer des entités avec par exemple une interface, une fabrique, une implémentation, un mapping objet/relationnel, etc ...
De manière générale au sein des modules de la ferme une information dans le modèle sert à produire de multiples fichiers qui sont ensuite complétés par du code manuel. L'utilisation d'Acceleo est alors particulièrement intéressante : le modèle reste métier et général, les informations techniques sont spécifiées en paramétrage de la génération et le développeur a tout intérêt à passer par le modèle qui va entraîner la génération de nombreux fichiers conformes à son architecture et à ses règles de formatage.
En 2006 sortait la première version d'Acceleo, générateur de code exploitant n'importe quel modèle compatible EMF et permettant de modifier le code généré avec la garantie que le code modifié ne serait pas perdu à la prochaine re-génération. Dès la première version l'outil était centré sur l'utilisateur avec des éditeurs, la colorisation syntaxique et une prise en main très simple comparée aux outils similaires de l'époque comme JET par exemple. Cette sortie n'est pas passée inaperçue, en effet une jeune société française libérait un outil dédié à un domaine largement occupé par les solutions propriétaires. Un outil qui plus est utilisable par le plus grand nombre.
Initialement presque exclusivement développé par la société Obeo, le projet accueille ensuite de nouveaux contributeurs pour former la "ferme de modules". Cette ferme héberge des modules de génération dédiés à différentes technologies telles que JEE, PHP, CSharp ou encore Python. La première sortie officielle de la ferme de module est réalisée lors de la sortie d'Acceleo 2.0 qui marque également le passage de la license GPL à la license EPL beaucoup plus utilisée au sein de l'écosystème Eclipse.
En plus de cet ensemble de modules prêts à l'emploi cette version majeure apporte la capacité à déployer un générateur sous la forme d'un greffon Eclipse, puis un peu plus tard apparaît le débuggeur interactif pour le langage Acceleo. Dans le même temps la communauté s'organise autour du forum, des listes de diffusion et de la planète Acceleo.
La communauté s'agrandit principalement autour de la ferme de module, des modules expérimentaux pour Plone, Zope sont créés, d'autres se basant non pas sur UML mais sur des langages spécifiques (WISSS) ou (et l'un des dernier venus) ciblant Dolibarr. Les projets étudiants et stages se multiplient autour de l'ingénierie des modèles et la vision "pragmatique" d'Acceleo. Le projet compte désormais 27 contributeurs, outillage Acceleo et modules confondus. Les équipes des différents modules coopèrent désormais plus, par exemple les profils UML utilisés par les modules JEE et PHP sont maintenant les mêmes.
Les plans de développements prévoient une version 3.0 à la fin de l'été, cette version est une ré-écriture du moteur d'évaluation afin de permettre à Acceleo de s'exécuter sans Eclipse, il sera ainsi possible d'intégrer plus facilement Acceleo à d'autres environnements de développements, voir de créer des générateurs que l'on lance en ligne de commande. La version 3.0 est en cours de développement, elle était initialement prévue pour Juillet mais a été décalée à Septembre : elle ne fournissait pas encore le niveau de qualité attendu.
La syntaxe Acceleo a été conçue pour naviguer simplement au sein de modèles, ce choix initial tourné vers la facilité d'utilisation implique que le langage en question n'est pas standard (au contraire d'OCL). Ainsi Acceleo 4.0, prévu pour Juillet 2009 permettra d'utiliser indifféremment deux types de syntaxes : la syntaxe Acceleo et la syntaxe "MOF Model To Text Langage" (MTL), normalisée par l'OMG. L'utilisateur aura alors le choix entre simplicité et standard et pourra importer un template en syntaxe Acceleo depuis un template MTL et vis-versa.
À ces fonctionnalités prévues pour le noyau d'Acceleo s'ajouteront sans aucun doute de nouveaux modules et de nouvelles fonctionnalités pour les modules existants. N'hésitez pas à rejoindre l'équipe !
Aller plus loin
- Nouveautés de la 2.3.0 en images (7 clics)
- Démonstrations flash (11 clics)
- Ferme de modules (1 clic)
- Téléchargement des bundles (5 clics)
- Participez au projet Acceleo (1 clic)
# licence Acceleo
Posté par vida18 . Évalué à 1.
http://ec.europa.eu/idabc/servlets/Doc?id=31205
[^] # Re: licence Acceleo
Posté par Cédric Brun (site web personnel) . Évalué à 2.
Du coup ceci pose certains problèmes pour Eclipse dans son ensemble car l'inclusion d'implémentations GPL est impossible, mais l'éco-système Eclipse étant principalement constitué d'entreprises qui développe sous EPL pour ensuite décliner ces outils dans des offres commerciales il est difficile de changer ce genre de chose. Si un tel changement faisait que les développements sur Eclipse seraient fortement ralentis alors ce serait un echec pour l'utilisateur final.
[^] # Re: licence Acceleo
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: licence Acceleo
Posté par Thomas Clavier (site web personnel) . Évalué à 1.
# (Eclipse + Acceleo) > XEmacs
Posté par Jérôme BENOIS . Évalué à 1.
Eclipse + Acceleo, enfin un environnement qui écrase XEmacs !
[^] # Re: (Eclipse + Acceleo) > XEmacs
Posté par Cédric Brun (site web personnel) . Évalué à 5.
[^] # Re: (Eclipse + Acceleo) > XEmacs
Posté par Goulwen Le Fur . Évalué à 1.
Emacs reste plus complet !
[^] # Re: (Eclipse + Acceleo) > XEmacs
Posté par Gniarf . Évalué à 3.
[^] # Semaine du vendredi
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
[^] # Re: Semaine du vendredi
Posté par Etienne Juliot (site web personnel) . Évalué à 2.
"en aout, le week end dure toute la semaine".
PS : à quand Acceleo intégré dans le shell ?
genre :
$apt-get install acceleo
$acceleo -gen apacheconfiggenerator -d /etc/httpd
$acceleo -gen kernelmodulegenerator -d /user/local/src
---> OK, je me rendors ....
[^] # Re: Semaine du vendredi
Posté par Victor . Évalué à 2.
Les plans de développements prévoient une version 3.0 à la fin de l'été, cette version est une ré-écriture du moteur d'évaluation afin de permettre à Acceleo de s'exécuter sans Eclipse, il sera ainsi possible d'intégrer plus facilement Acceleo à d'autres environnements de développements, voir de créer des générateurs que l'on lance en ligne de commande.
# Modelisation vs Code
Posté par Mat (site web personnel) . Évalué à 9.
D'autres encore (moi :D) pronent une modélisation modérée.
Je m'explique. Je fais du développement depuis un bout de temps. J'ai d'abord commencé en loisir, puis j'ai suivi des études d'info, et depuis qques année maintenant, j'en vis.
Dans les premiers temps, qd je codais qque chose, même si c'était un projet d'une assez grande envergure (ca m'est arrivé 2 fois avant mes études), je réflechissais un peu au départ, mais je commençais à coder assez vite. Inutile de dire que j'ai refactoré le code plusieurs fois parce qu'une évolution n'était pas possible dans la conception courante.
Ensuite à l'université j'ai appris la modélisation. Super ! En partant d'un problème assez flou, avec des méthodes ou des schémas ou les deux, je peux identifier,découper,modulariser mon problème, et même aller jusqu'à de la génération de bouts de code. J'adorais ça. Voir évoluer la résolution d'un problème du début à la fin, et l'abstraction que ca nécessite, tout ca me plaisait bien. Et avec mon point de vue de dev ca marchait plutôt pas mal. Dans les projets d'étude en tout cas.
Enfin, qd j'ai commencé à bosser, et bien la modélisation, comment dire... j'en ai jamais vraiment vu. Les types qui réfléchissent ne sont presque jamais ceux qui développent ensuite. Les rares documents de "modélisation" que j'ai eu en main étaient de sources totalement hétéroclites (majoritairement des .doc avec des bouts d'excel dedans, et des images souvent pondues par Visio). Souvent je n'ai pas pris un projet au début, donc où l'architecture générale du projet ou le code ou les deux étaient déjà commencés. L'absence de commentaires est très récurrente, et la modélisation inexistante.
Heureusement, pour mon stage j'ai eu la chance d'avoir une portion de projet où j'ai fait l'intégralité du code. Je me suis donc mis en devoir d'utiliser un logiciel UML à la fois pour bien concevoir ce que j'avais à faire, et pour avoir un beau rapport de stage.
Et les ennuis ont commencé. J'ai utilisé Rational (je bossais chez big blue) qui est réputé, et malgré une prise en main rapide, j'ai vite déchanté. Le code généré est relativement simple, et donc ne présente pas réellement d'intérêt. Il ne gérait pas très bien les modifs de schémas. En fin de compte, c'est assez difficile de modéliser un cas assez technique, pas sûr que ca ait apporté une lisibilité supplémentaire. Les graphes obtenus par des clics de souris sont longs à faire et à modifier. Et surtout j'ai perdu pas mal de temps, parce qu'une fois parti dans le code, eh bien moult problèmes que je n'avais pas bien vus à la modélisation sont apparus.
Finalement, en ce qui me concerne en tout cas, je pense qu'il vaut mieux que je commence le code assez tôt, même si la modélisation n'est pas encore terminée, quitte à la faire évoluer au fur et à mesure. On voit mieux la berge en s'en approchant que du large.
Je ne peux donc pas appuyer mon code sur celle-ci, mais à la limite c'est mieux, je préfère qu'elle soit plus haut niveau et pas trop détaillée. Le relecteur n'a pas forcément besoin de connaitre tous les points d'implémentation.
Et j'ai récemment découvert un petit outil de génération de graphiques UML bien sympa, qui évite tout clic!
http://umlspeed.sourceforge.net/
[^] # Re: Modelisation vs Code
Posté par JoeltheLion (site web personnel) . Évalué à 3.
Je suis bien d'accord si tu es tout seul, mais si tu commandes une armée de 100 développeurs très moyens, tu fais comment? AMHA c'est pour ce genre de gros projets que la modélisation prend tout son intérêt.
[^] # Re: Modelisation vs Code
Posté par Mat (site web personnel) . Évalué à 4.
Et c'est pas la peine de mettre les 100 développeurs d'entrée de jeu.
[^] # Re: Modelisation vs Code
Posté par Mithfindel (site web personnel) . Évalué à 6.
Parce que nos chefs n'ont pas encore compris qu'un développeur qui sort d'école est plus au fait des méthodes de modélisation qu'un ancien COBOListe qui a fait une formation de 3 jours à UML. C'est un peu dur dit comme ça mais c'est la réalité, ceux qui font les specs d'aujourd'hui sont ceux qui écrivaient du code hier et qui n'ont pas su (ou pas pu, ou pas voulu) s'adapter à l'évolution (rapide ces dernières années) de la technique.
Moinsez moi si vous voulez, c'est en tout cas le constat que j'ai pu faire en quelques années de SSII.
[^] # Re: Modelisation vs Code
Posté par Narmer . Évalué à 4.
entre le jeune débutant qui sort de l'école et le développeur de cobol de 50 ans il y a tout un écosystème quand même. Je suis architecte logiciel et je code également, et je peux te dire qu'avant de coder on réfléchit un peu ...
Une connaissance me racontait que des jeunes ingé sortant d'école ont "développé" une application et résultat c'est la catastrophe. Ok ils connaissent bien UML par contre c'est des bu*nes en design et en bon sens. Les principes de bases, séparations en couche, IOC, simple séparation UI / traitement, sans même parler de MVC, etc. Çe fait du code non maintenable ou difficillemement, et l'application accumule une dette technique qui va couter de l'argent tout de suite.
Donc ok pour laisser un jeune ingé coder avec un maximum de liberté sur une partie identifiée de l'application mais je le laisse pas designer/concevoir l'appli. Enfin si si l'application n'est pas critique (faut bien apprendre) ou qu'on n'a pas le choix .
C'est une peu dure dit comme ça mais c'est la réalité :)
[^] # Re: Modelisation vs Code
Posté par Mithfindel (site web personnel) . Évalué à 5.
Quand je parle de patrons de conception, de refactoring, d'approche MDA, de tests unitaires et d'intégration continue dans ma boite, on me regarde avec des yeux ronds. Ce sont des choses qui m'étaient déjà familières à ma sortie d'école il y a 4 ans (déjà...), mais il faut croire qu'en entreprise, il vaut mieux répéter les erreurs du passé plutôt qu'investir et se mettre au gout du jour...
[^] # Re: Modelisation vs Code
Posté par stephwww . Évalué à 4.
L'objectif est de fournir un résultat visuellement acceptable, ça me semble être généralisable dans les projets de type forfait (oui là je suis très nombriliste, mais...) ou il y a beaucoup de stagiaires encadrés par des vieux de la vielles qui ont, pour certains, jusqu'à 4 ans d'anciennetés si on inclut le stage.
Les expérimentés arrivent quand le client veut taper et qu'il est trop tard.
>>Quand je parle de patrons de conception, de refactoring, d'approche MDA, de tests unitaires et d'intégration continue[...]
Franchement que tu sortes ces termes alors que tu as 4 ans d'anciennetés m'impressionnent, sur les 3 dernières années (dans ma SSII actuelle) tu dois faire parti des 5 ou 6 qui savent que ça existe.
[^] # Re: Modelisation vs Code
Posté par Antoine . Évalué à 3.
Ca me rappelle cet extrait d'un article de Joel Spolsky :
« They are the kind of people who decide to refactor your core algorithms to use the Visitor Pattern, which they just read about the night before, and completely misunderstood, and instead of simple loops adding up items in an array you’ve got an AdderVistior class (yes, it’s spelled wrong) and a VisitationArrangingOfficer singleton and none of your code works any more. »
http://www.joelonsoftware.com/articles/GuerrillaInterviewing(...)
mais il faut croire qu'en entreprise, il vaut mieux répéter les erreurs du passé plutôt qu'investir et se mettre au gout du jour...
Oui, les erreurs du présent sont plus marrantes :)
[^] # Re: Modelisation vs Code
Posté par gege (site web personnel) . Évalué à 6.
C'est là qu'intervient Acceleo et les autres (JET, openArchitectureWare, MOFscript, ...), comme les outils fournis en standard avec les modeleurs UML visent la généricité, ils ne peuvent pas générer grand chose (au mieux les squelettes du code) et en plus il y a de fortes chance que ça ne colle pas à tes règles métier. Pour aller plus loin, il te faut définir un profil UML ou un DSL (Domain specific language) qui est propre à ton métier (comme ceux proposés dans la news) et développer/adapter un générateur de code maison. Aujourd'hui avec des solutions comme Acceleo ça devient un jeu d'enfant et on peut faire des générations de large parties du code (celles pénibles à codé ou source d'erreur fréquentes) simplement. Par exemple refaire un générateur du style de celui de RSM est l'affaire de qq jours (et non j'ai pas d'action chez eux ;-) )
Il faut s'enlever de l'idée (pour le moment ?) qu'un modeleur UML aussi bon soit-il va te permettre de faire du MDD sorti de la boite. Mettre en place un process orienté modèle demande des développement proprio et de l'investissement (générateur de code, transformateurs de modèles, vérif sur ces modèles, ...). Sur des projets un peu gros, ça peu être très rapidement super rentable.
Je suis assez étonné que l'approche a base de modèle n'ai pas plus de succès que ça dans les grands projets libres, pourtant c'est ceux qui ont la plus grande flexibilité pour mettre en place ces solutions et pour en tirer avantage (productivité plus forte, meilleure homogénéité du code, meilleure intégration des nouveaux, ...). De même avec des frameworks comme RoR, on pourrait faire des trucs super puissants en modélisant l'appli et ensuite en générant une grande partie du code (genre le modèle de données, une partie des contrôleurs, ...)
En fin de compte, c'est assez difficile de
modéliser un cas assez technique, pas sûr que ca ait apporté une lisibilité supplémentaire.
Les graphes obtenus par des clics de souris sont longs à faire et à modifier.
Je vais être caricatural... RSM n'a pas que des qualités, loin de là, mais le problème est que RSM n'est pas un outil de dessin... Le but à la fin est d'avoir un modèle à partir duquel tu peux faire qqch générer du code, faire des analyses, produire d'autres modèle, ...). Pour faire des "dessins UML" vaut mieux prendre PowerPoint ou Dia pour faire libre tu auras un meilleur rendu plus simplement...
Finalement, en ce qui me concerne en tout cas, je pense qu'il vaut mieux que je commence le code assez tôt, même si la modélisation n'est pas encore terminée, quitte à la faire évoluer au fur et à mesure.
Dans une approche MDE c'est la transformation du modèle vers le code qui te permet de commencer à coder (même si plusieurs itérations sont possibles). Je suis d'accord que pour le moment
les outils sont assez lourds et mal foutus, mais ça s'améliore de plus en plus et le jeu en vaut carrément la chandelle !
[^] # Re: Modelisation vs Code
Posté par goeb . Évalué à 4.
Car dans les projets du monde réel (avec de nombreux développeurs), les interfaces changent souvent. et alors c'est très lourd de modifier le modèle + le code.
De nombreux projets se font selon les principes suivants :
- avoir rapidement un logiciel qui marche partiellement
- commencer par les grandes fonctionnalités et faire les détails plus tard
- par conséquent on découvre en cours de route, et souvent, qu'il faut modifier les interfaces, etc.
Et cette approche "release often, release soon" concerne aussi bien les fonctionnalités que le code.
L'idée du logiciel tout bien pensé dès le départ est un mythe.
Donc pour moi, le plus rapide c'est de travailler au jour le jour seulement avec le code.
La modélisation ne doit être modifiée que quand une grosse modification d'architecture intervient, c'est-à-dire rarement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.