Articles précédents : Articles
- [4] Le programme de JRES 2007
- [14] Législatives 2007 : 72h du Logiciel Libre, c'est parti !
- [2] Install Party à la Cyberbase d'Auch le 23 juin
- [47] Modèles économiques liés aux logiciels libres
- [30] RedHat annonce la Liberation des polices !
- [10] Candidats.fr Législatives - Un pacte du Logiciel Libre sur le terrain.
- [13] Microsoft n'attaquera pas la communauté Open Source
- [1] Le RGAA vient s'ajouter au RGI et au RGS.
- [10] Deux nouveaux produits embarqués sous Linux !
- [10] Sortie de la bibliothèque MAPI OpenChange 0.4
Liens connexes
- Téléchargement d'Acceleo 2.0.0 (820 hits)
- Ferme de modules (379 hits)
- Démonstrations et captures d'écran (2418 hits)
- Planète Acceleo (330 hits)
Dépêche modérée par
Dépêche éditée par
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 (820 hits)-
Ferme de modules (379 hits)
-
Démonstrations et captures d'écran (2418 hits)
![[en]](../../../images/en.png)
Planète Acceleo (330 hits)
> Lire la dépêche (15 commentaires, moyenne: 2,1).
- 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é).
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é ?
Posté par Cédric Brun (page perso, ) le 08/06/2007 à 07:54. (lien). Évalué à 3.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é ?
Posté par Philippe Fremy (page perso, ) le 08/06/2007 à 08:40. (lien). Évalué à 5.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é ?-
[^]Re: utilité ?
Posté par Cédric Brun (page perso, ) le 08/06/2007 à 09:39. (lien). Évalué à 6.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".
-
-
Avancement module J2EE
Sur la page http://www.acceleo.org/pages/module-uml2-vers-jee-java-strut(...)
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 () le 08/06/2007 à 10:16. (lien). Évalué à 2.La description de la tâche n'est peut être pas assez précise effectivement. En fait il s'agit du passage au version 2 de struts et 3.2.x de hibernate qui en est à 0%.
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 ?
Je trouve la démarche assez intéressante d'un point du vue "Open source" (encore un logiciel de plus !) mais pour moi il ne répond pas vraiment au qualificatif de "génération/generateur de code".
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 (page perso, ) le 08/06/2007 à 12:29. (lien). Évalué à 1.Je comprends pas ce que tu veux dire :-)
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.
Et spring dans tout ça !
Ce serait vachement mieux si le module de génération JEE utilisait le framwork spring (avec spring-hibernate), et donc spring-mvc (voir spring-webflow) en lieu et place de struts. Ceci en attendant que la communauté évolue et finit par accepter les couches IHM Web orientées composant comme wicket par exemple au lieu de se battre avec des taglib dans du jsp.
-
[^]Re: Et spring dans tout ça !
Posté par Goulwen Le Fur () le 08/06/2007 à 13:16. (lien). Évalué à 1.En matière d'intégration de spring, c'est en cours. Une contribution opensource nous a été envoyée mais je n'ai pas eu le temps de l'intégrer avant la release d'Acceleo. Je vais y travailler au plus vite.
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 (page perso, ) le 08/06/2007 à 21:45. (lien). Évalué à 1.En effet, j'ai soumis un module JEE pour Spring qui est en fait une extraction d'une partie du module "Enterprise Application" non publié à ce jour. Je communiquerai bientôt (à la fin du mois je pense) une news sur planet.acceleo.org pour donner un peu de visibilité sur notre projet. En tout cas il est clair que le worflow de navigation sera gérer par SWF (Spring WebFlow) quant à la vue peut-être Spring-MVC, Struts2 ... on n'a pas encore décidé ...
-
Appel à contribution !
Je profite de la news pour dire qu'il y' a quelques générateurs qui pourraient être particulièrement sympas, en tout cas qui auraient mon soutien et auxquel je participerai avec plaisir si quelqu'un se manifeste pour les démarrer .
Avis aux amateurs :
- Générateur PyQT/PyKDE
- Générateur Zope3
-
[^]Re: Appel à contribution !
Posté par Alf (page perso, ) le 08/06/2007 à 14:43. (lien). Évalué à 2.Tu sais très bien que le générateur zope3 est prévu chez nous :-)
zope3
Dans la présentation sur mindmap, j'ai vu passer subrepticement un dossier intitulé org.acceleo.demo.zope3. Il y a quelque chose de fait autour de zope3 dans acceleo ?
-
[^]Re: zope3
Posté par Cédric Brun (page perso, ) le 08/06/2007 à 14:52. (lien). Évalué à 1.Uniquement du domaine de l'expérimentation avec le framework pour le moment :) - histoire ce savoir ce que ça a un peu dans le ventre.
Cette page a été générée par Templeet en 0.0936s (dont 0.016 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.