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. Plus d'information sur les modules livrés pour la version 2.0.0 :
- Générateur CSharp : objets métiers, mapping objet/relationnel via NHibernate, scripts de création de base de donnée, interfaces, fabriques et implémentations.
- Générateur JEE : objets métiers, mapping objet/relationnel via Hibernate, scripts de création de base de donnée, classes d'accès aux données (DAO), contraintes d'integrité, couche d'IHM et de navigation via Struts, tests unitaires (JUnit et HTMLUnit).
- Générateur Java : gestion complète du diagramme de classe, paramétrage de la génération via un profil spécifique.
- Générateur Python : objets métiers, contraintes spécifiques (relations opposées, unicité...) et tests unitaires.
- Générateur PHP : architecture standard 3 couches, accès aux données via PearDB, objets de transferts (DTO), templates Smarty et actions/formulaires PhpMVC.
- Mindmap : génération de slides XHTML depuis une carte mentale.
Tous ces modules disposent d'une description détaillée sur la page de la ferme de modules.
D'autres modules sont en préparation pour différentes technologies, n'hésitez pas à rejoindre l'équipe du projet Acceleo !
Rappel : Acceleo permet de mettre en oeuvre une démarche dirigée par les modèles. Cette démarche positionne le modèle (UML par exemple) au centre du développement. Un modèle + un module et Acceleo est alors capable de générer une grande partie du code du projet.
Exemple : un modèle UML détaillant les objets métiers et les écrans permet la génération des classes métiers, d'une classe pour chaque écran, des contrôleurs, des classes d'accès à la base de donnée. À la charge ensuite au développeur de compléter le code, lors de la prochaine génération ce dernier ne sera pas perdu.
La mise au point d'un module de génération pour une technologie donnée (Zope, KDE, Gnome...) passe par la création de templates. Acceleo fournit tous les outils nécessaires à la mise au point d'un tel template (éditeur avec complétion syntaxique, pré-visualisation du code généré).
Aller plus loin
- Téléchargement d'Acceleo 2.0.0 (789 clics)
- Ferme de modules (129 clics)
- Démonstrations et captures d'écran (653 clics)
- Planète Acceleo (39 clics)
# utilité ?
Posté par Antoine . Évalué à 2.
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é ?
Posté par Cédric Brun (site web personnel) . Évalué à 3.
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é ?
Posté par Philippe F (site web personnel) . Évalué à 5.
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é ?
[^] # Re: utilité ?
Posté par Cédric Brun (site web personnel) . Évalué à 6.
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".
# Avancement module J2EE
Posté par Xavier Poinsard . Évalué à 2.
il apparaît que le module J2EE (avec struts et hibernate) en est à 0% pour la partie struts/hibernate justement.
Alors qu'en est-il vraiment ?
[^] # Re: Avancement module J2EE
Posté par Goulwen Le Fur . Évalué à 2.
Pour ce qui est de la génération Struts et Hibernate elle est déjà fonctionnelle.
Une demo est en ligne pour illustrer les résultats et j'en prépare d'autre dans la journée.
# Génération de code ?
Posté par zlnix . Évalué à 1.
Un terme comme plate-forme d'intégration répondrait mieux.
La génération de code, au sens large, c'est d'avoir un formalise dynamique suivant l'idée de départ, hors ici nous avons encore quelque chose qui se calque à un environnement statique de composants.
[^] # Re: Génération de code ?
Posté par Alf (site web personnel) . Évalué à 1.
Si tu veux dire qu'Acceleo est plus un environnement pour créer des générateurs, je suis d'accord, mais sinon, je comprends pas.
Je suis en train de faire un générateur/framework PHP, au même titre que symphony, sauf qu'avec Acceleo, EMF et GMF, j'ai une plateforme qui me permet de créer mon métamodèle et mon générateur facilement. Alors que les frameworks existants doivent définir un formalisme pour instancier leurs modèles (il faut apprendre la syntaxe spécifique à chaque framework pour créer une classe par exemple) et ils doivent maintenir leur moteur de génération qui parse les fichiers de modèle.
Aujourd'hui, si je voulais définir un générateur pour zope à partir d'un modèle symphony, il faudrait déjà que je comprenne/trouve leur métamodèle.
http://helpmequ.it: arrêter de fumer pour la bonne cause, http://mapetiteautoentreprise.fr : facturation libre pour les auto-entrepreneurs
# Et spring dans tout ça !
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
[^] # Re: Et spring dans tout ça !
Posté par Goulwen Le Fur . Évalué à 1.
Cette contribution traite la partie Hibernate. Pour ce qui est de la partie présentation spring mvc ce n'est pas abordé (c'est déjà énorme d'avoir la partie persistance de couverte).
Perso je ne connais pas cette techno, je ne serais donc pas capable tout de suite de l'intégrer mais si quelqu'un est motivé, je suis tout à fait disposer à intégrer cela.
Tu parles de spring-mvc mais je pense que du JSF serait intéressant aussi. Bref, bien que le module soit relativement mature, le domaine est loin d'être couvert, et l'accès à un nombre important de techno est un but du module.
Maintenant que le module est ouvert à tous, j'espère que je vais être rejoins par des connaisseurs JEE car à moi tout seul je suis pas prêt d'arriver au bout de JEE :)
[^] # Re: Et spring dans tout ça !
Posté par Jérôme BENOIS . Évalué à 1.
# Appel à contribution !
Posté par Cédric Brun (site web personnel) . Évalué à 2.
Avis aux amateurs :
- Générateur PyQT/PyKDE
- Générateur Zope3
[^] # Re: Appel à contribution !
Posté par Alf (site web personnel) . Évalué à 2.
http://helpmequ.it: arrêter de fumer pour la bonne cause, http://mapetiteautoentreprise.fr : facturation libre pour les auto-entrepreneurs
# zope3
Posté par ccomb (site web personnel) . Évalué à 1.
[^] # Re: zope3
Posté par Cédric Brun (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.