Articles : Acceleo 2.0.0 : génération de code PHP, JEE, Java, CSharp et Python
Posté par Cédric Brun (page perso, ). Modéré le 07 juin 2007.
Pour suivre cette communauté une aggrégation de blogs a été ouverte : Planète Acceleo.
Le moteur de génération a lui aussi évolué, réalisant un pas supplémentaire vers la simplicité et le confort lors de la réalisation des templates de génération. La syntaxe a été modifiée et prend désormais directement en compte les prédicats de sélection, cela permet d'avoir une complétion, une colorisation et une détection d'erreurs directement lors de la saisie des prédicats. Les services de navigation ont également été remaniés pour une plus grande cohérence.
Acceleo 2.0.0 permet également l'export des générateurs en tant que greffon, cette fonctionnalité en développement depuis plusieurs mois permet de faciliter l'installation et la mise à jour des générateurs par le biais des update-site Eclipse. Enfin cette version apporte une plus grande compatibilité, en particulier avec les fichiers XML qui peuvent être exploités via EMF-XSD.
Toutes ces nouveautés sont présentées en image sur la page Acceleo 2.0.0 - Aperçu des nouveautés. À noter également qu'Acceleo a été choisi par les projets Topcased et Papyrus comme moteur de transformation « modèle vers texte ». Autre grande nouvelle simultanée à la sortie d'Acceleo, les documentations professionnelles édités par Obeo auparavant réservées à un usage non commercial sont désormais totalement libérées.
![[fr]](../images/fr.png)
Téléchargement d'Acceleo 2.0.0 (894 hits)-
Ferme de modules (413 hits)
-
Démonstrations et captures d'écran (2491 hits)
![[en]](../images/en.png)
Planète Acceleo (366 hits)
> Lire la dépêche (15 commentaires, moyenne: 2,1).
Vous avez demandé le commentaire #839615.
Run by 
Cette page a été générée par Templeet en 0.0505s (dont 0.006 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
utilité ?
Un modèle + un module et Acceleo est alors capable de générer une grande partie du code du projet.
Une grande partie du code ? Ça laisse rêveur. C'est destiné aux entreprises qui veulent réimplémenter Hello World en Java dans une architecture trois-tiers ?
(je doute de l'intérêt d'une telle approche pour un langage comme Python, mais c'est vrai que j'ai déjà vu des gens programmer en Python comme on programmerait en Java...)
[^]Re: utilité ?
Tout à fait d'accord concernant Python, ce langage à tendance à être très peu verbeux et permet généralement d'accroître la productivité en lui même.
Tout d'abord une précision : le générateur Python se base sur Ecore et non pas sur UML. Ecore permet la spécification de Méta-modèles, et à par conséquent une sémantique assez différente d'UML en définissant des relations opposées ou dérivées par exemple. De plus il est beaucoup plus compact et facile à assimiler qu'UML.
L'objectif du module est non pas d'éviter de saisir du code, ce qui, finalement en Python, se fait assez très peu. Mais plutôt de disposer d'un module Python ayant le même comportement que son équivalent Java généré avec EMF (relations opposées, contraintes d'unicités et sérialisation XMI par exemple).
Je suis bien sûr ouvert à toute critique concernant la "non pythonicité" du code généré :)
Un autre module de génération vers Python est en incubation, il permet la génération d'un (petit) jeu vidéo à partir d'un modèle spécifique. Là encore il ne s'agit pas de générer de multiples fichiers et des architectures n couches, mais plutôt de permettre à tout un chacun de modéliser un jeu vidéo (et là on est très loin d'UML), de générer et d'avoir une bonne base pour affiner son Jeu.
Concernant l'intérêt que cela peut avoir : l'existence de ces modules ne tient qu'au plaisir que j' éprouve en expérimentant de nouvelles approches avec :)
[^]Re: utilité ?
Pour les gens qui ne connaissent rien a la programmation à base de modèle (comme moi), et qui ont toujours été effrayé ou ennuyé par UML, tu as quelques recommandations ? Du genre digeste et on a l'impression qu'on pourra s'en servir un jour ?
Mon apriori très fort est que de toute façon, tu peux mettre tous les générateurs que tu veux, il bien un moment où tu dois écrire le code.
Tu parles de EMF, c'est quoi ?
Est-ce que ce type d'approche de la programmation marche réellement en pratique ? Je prends un exemple concret : je travaille sur un moteur d'édition vi ( http://www.yzis.org ). Que pourrai m'apporter la programmation à base de modèle et de code généré ?
phil.freehackers.org
[^]Re: utilité ?
Que les choses soit claires : il ne s'agit en aucune façon de remplacer l'écriture du code. Le modèle est un outil qui permet de générer la structure du code, les fichiers de configuration, en bref les parties du projet présentant peu d'intérêt, cette génération est complétée par la suite par du code manuel. Acceleo permet justement de garder ce code manuel même après une re-génération.
Pour les gens allergiques à UML, je leur conseille vivement de consulter les démonstration flash utilisant des DSL, par exemple MindMap (http://www.acceleo.org/pages/module-mindmap-vers-html-/ ).
On y utilise un formalisme simpliste : Idée/Contenu de l'idée / relations pour modéliser une carte mentale. Cette dernière est ensuite exploitée pour générer des slides XHTML.
L'approche à plusieurs avantages qui peuvent avoir un intérêt selon les projets (mais pas forcément !). En voici quelques un en vrac :
* la cohérence : si on génère des objets métiers par exemple, on a la garantie qu'ils respectent tous les mêmes règles de nommage, la même structuration. Si l'on doit effectuer un changement dans cette structuration, il suffit de mettre à jour le template et les objets métiers se conformerons alors à la nouvelle règle.
* la capitalisation de bonnes pratiques : imaginons que le projet KDE réalise un module de génération, ce dernier définira toutes les bonnes pratiques d'architectures du projet, ainsi on peut imaginer que le développeur utilisant le générateur modélise une application constituée de plusieurs composants, le module de génération va en faire autant de KParts respectant
* la séparation des préoccupations : le modèle contient les informations fonctionnelles, objets métiers, architecture fonctionnelle, l'architecture technique est définie dans le module de génération.
* la synchronisation entre le modèle, qui documente mais ici, pas seulement, et le code source de l'application. Un nouveau contributeur arrive, il dispose directement d'une vision globale du projet en phase avec le code source.
* un certaine indépendance vis à vis de la plateforme technique: même exemple que précédemment avec KDE, le développeur à un modèle de son application qu'il a générée pour KDE, un jour de grande dépression (ou ayant abusé de je ne sais quel alcool) il décide de baser son application sur Gnome. Il réalise (ou utilise un générateur) pour Gnome et dispose directement d'une application ayant une structuration équivalente à celle de KDE mais qui utilise du CORBA ^^. (on pourrait imaginer le même processus, plus probable, qui permet la mise à jours de KDE3 vers KDE4 par exemple.)
* l'apprentissage : l'utilisation d'un tel module de génération facilite grandement l'apprentissage d'un framework. En effet il est facile d'expérimenter en modifiant le modèle, et en observant le code généré.
Ce type d'approche marche réellement en pratique à partir du moment où l'outil n'ajoute pas de contraintes sur le développeur et que ce dernier y trouve son compte : il modélise 1 objet, cela génère n fichiers rébarbatif à faire manuellement.
EMF (http://www.eclipse.org/emf/) est un projet Eclipse qui permet la méta-modélisation, c'est à dire - de manière succinte - la définition d'un modèle pour définir des modèles. Concrètement cela permet de se passer d'UML, pour utiliser un langage plus réduit ou spécifique au domaine concerné. Par exemple dans le cas du métamodèle de jeu vidéo, la notion de classe, de composants, n'a aucun sens. EMF permet de définir un méta-modèle qui permet de représenter les concepts de "règle du jeu", "évènements", "états" ou encore "déplacements".