Articles précédents : Logiciel
- [8] Zen, le CRM open source (GPL)
- [26] Sortie du CMS Drupal en version 4.7
- [15] Projet DJMix
- [76] Modifier le firmware d'une Freebox grâce à OpenFreeBox
- [45] Sortie de Open-Xchange 0.8.2
- [40] Sortie d'ejabberd 1.1.0
- [64] Virtualisation de Serveur : Linux sous Windows
- [13] PTT : outil de trace pour la NPTL
- [18] eGroupWare 1.2
- [22] Sortie de Git 1.3.0
Liens connexes
- Site du projet (623 hits)
- Captures d'écran (946 hits)
- Site de la société française qui a initié le projet (161 hits)
- Définition du MDA (162 hits)
Dépêche modérée par
Dépêche éditée par
Logiciel : Acceleo sort en version 1.0
Posté par Etienne Juliot (page perso, ). Modéré le 03 mai 2006.
Acceleo est nativement intégré à Eclipse et EMF (Eclipse Modeling Framework) ; il comprend toute une panoplie d'outils et d'éditeurs permettant de simplifier sa prise en main et son adaptation à tous types de projets ou de technologies.
Acceleo vient de sortir en version 1.0 et propose déjà de nombreuses innovations : génération incrémentale, interopérabilité des méta-modèles d'entrée, syntaxe arborescente, personnalisation par templates...
![[fr]](../../../images/fr.png)
Site du projet (623 hits)-
Captures d'écran (946 hits)
-
Site de la société française qui a initié le projet (161 hits)
-
Définition du MDA (162 hits)
> Lire la dépêche (30 commentaires, moyenne: 2,3).
Acceleo permet ainsi de gagner en productivité et en fiabilité tout au long du cycle de développement notamment grâce à ses fonctionnalités avancées :
- génération incrémentale,
- support de tous types de technologies en sortie,
- support d'UML 1 / UML 2 et tout type de méta-modèle compatible EMF ou MOF,
- capacité élevée de personnalisation,
- syntaxe intuitive et dédiée à la manipulation de modèles.
Acceleo est sous licence GPL. Il a été créé et diffusé en OpenSource par une société française : Obeo.
Sa mise en oeuvre est rapide grâce à son intégration native dans Eclipse :
- éditeur de templates de génération avec colorisation syntaxique et complétion,
- éditeur réflectif de prévisualisation du résultat en temps réel,
- système de paramétrage de génération,
Acceleo étant indépendant de la techno de sortie, on peut facilement envisager à terme la réalisation de modules de génération vers nos frameworks chéris : Gnome, Qt, SWT, XUL, Zope...
Quelques définitions :
- MDA (Model Driven Architecture) : démarche proposée par l'organisme de normalisation OMG (à qui on doit déjà UML et Corba) pour normaliser la réalisation de logiciels à partir de modèles.
- EMF : Framework intégré dans Eclipse permettant la manipulation de modèles
- MOF : standard OMG de représentation et d'échanges de modèles (et de méta-modèles)
- Eclipse : environnement de développement à base de plugins permettant de centraliser dans un seul outil l'ensemble des outils nécessaires aux projets informatiques
Générateur de code OpenSource ?
Il génère du code OpenSource ? C'est trop fort :=)
Au début j'ai été surpris de cette caractéristique, puis j'ai compris : c'est un générateur OpenSource de code ... Dommage, c'était sympa comme fonction.
-
[^]Re: Générateur de code OpenSource ?
Posté par DArt (Jabber id, page perso, ) le 03/05/2006 à 12:42. (lien). Évalué à 2.Je me suis fait avoir comme toi au début :o))
-
[^]Re: Générateur de code OpenSource ?
Posté par baud123 (Jabber id, page perso, ) le 03/05/2006 à 14:12. (lien). Évalué à 4.vi, la formulation initiale s/générateur de code OpenSource de dernière génération/générateur OpenSource de code de dernière génération/ a été modifiée après publication pour clarifier :p
Sinon il faut saluer cette initiative, qui démontre une nouvelle fois que le code peut tout à fait être libéré, une fois qu'il a été payé, voire dès qu'il a été payé une fois...
Cette dépêche aurait peut-être mérité la première page (PP) si le nombre de buzzwords ne nous avait fait craindre un concours de business loto :-) (foutaises !)
Plus sérieusement, si quelqu'un dans l'assistance peut contribuer avec un retour d'expérience / stabilité du produit / intérêt concret [1] ça en intéressera plus d'un et aidera à comprendre ce que ça apporte. (notamment, en terme de méthodologie si j'ai bien tout saisi).
[1] oui, oui, c'est donné dans les fonctionnalités, mais bon les MDA, EMF, MOF et consors j'aurais pu croire que c'était Mon Disclosure Agreement, Enhanced Meta-File, voire Marc-Olivier Fogiel euh là non :p ce pourquoi j'ai tout de même ajouté la signification en toutes lettres à chaque fois (+ les liens wikipedia : à étoffer si nécessaire, la partie française semblant plus complète pour une fois).-
[^]Re: Générateur de code OpenSource ?
Posté par Etienne Juliot (page perso, ) le 03/05/2006 à 16:48. (lien). Évalué à 4.C'est vrai que la formulation initiale est carrément anbigü.
Pour info, Acceleo a été pensé dès le début pour être en OpenSource. Et désolé si le ton était trop buzzword. A force d'être quotidiennement au milieu de termes barbares de métamodèles et autres joyeusetés du genre, on en oublie que c'est encore aujourd'hui assez peu répandu.
Par contre, je ne suis pas d'accord avec toi que ce sont des foutaises.
C'est clair que c'est éloigné du réseau ou de la programmation système, et que ce n'est pas trop le sujet du discussion que tu abordes autour de la dinde de Noël. Mais MDA et EMF ne sont pas des termes commerciaux ou marketing, mais des réalités technologiques.
Et justement, la raison d'être d'Acceleo c'est ça : permettre de faire du MDA sans pour autant avoir à connaître toute la complexité des concepts qui sont dessous.-
[^]Re: Générateur de code OpenSource ?
Posté par Christophe Garault (page perso, ) le 04/05/2006 à 07:21. (lien). Évalué à 3.Par contre, je ne suis pas d'accord avec toi que ce sont des foutaises.
Comme je m'étais moi aussi fait avoir en mon temps, je me permet de te suggérer la lecture de la page suivante pour comprendre cette petite plaisanterie:
http://www.admiroutes.asso.fr/action/bb/loto.htm
-
[^]Re: Générateur de code OpenSource ?
Posté par Alexandre Garel () le 04/05/2006 à 07:36. (lien). Évalué à 1.Ne te méprends pas, foutaise ! est en référence à l'excellent business loto : http://www.admiroutes.asso.fr/action/bb/loto.htm
-
[^]Re: Générateur de code OpenSource ?
Posté par baud123 (Jabber id, page perso, ) le 04/05/2006 à 13:31. (lien). Évalué à 4.ok, je vais poser la question autrement...
et ne pas faire de MDA, ça me prive de quoi ? (autrement dit aussi : quels sont les apports du MDA)
Pour un néophyte du sujet, quels sont les concepts-clés ajoutés ? Est-ce efficace pour les SOA notamment ? (que tu traduiras de toi-même...).
PS : et je confirme : foutaises c'est référence au business loto (cité juste avant...).-
[^]Re: Générateur de code OpenSource ?
Posté par Alexis Muller (page perso, ) le 04/05/2006 à 18:12. (lien). Évalué à 3.Salut,
Je connais plutôt bien l'approche MDA (voir mon site web) et je pense
pouvoir apporter quelques précisions.
Pour résumer, l'idée de MDA c'est de décrire (à l'aide d'un modèle) une
solution à ton problème métier indépendamment des considération
techniques propre à une plate-forme ou un langage particulier.
Le bénéfice attendu est de pouvoir capitaliser la description de ta
solution et ainsi pouvoir passer d'une plate-forme à l'autre au fil des
évolutions.
On sait très bien qu'en informatique les langages et les plates-formes
changent très vite par des phénomènes de modes et des évolutions
technologiques. Alors que la solution à une préoccupation métier
(gestion de stock, de client, ou même le "métier" d'un wiki par exemple,...)
n'évolue de très peu.
L'apport des outils qui vont avec c'est de ne pas devoir se taper à la
main la mise en oeuvre de nos solutions génériques sur la nouvelle
plate-forme.
On peut voir un peu ça comme de l'idée des langages de programmation de
haut niveau : quand tu écris un programme en C tu peux obtenir de
l'assembleur pour différent processeurs sans modifier ton code.
Mais le MDA (Model Driven Architecture) c'est dépassé, la nouvelle
évolution c'est le MDE (Model driven Engineering) qui généralise l'idée
de capitaliser les modèles. Mais alors qu'a l'origine le MDA n'est
qu'une approche descendante (du modèle métier vers l'implantation)
l'approche MDE propose "toutes sortes" de manipulation sur les modèles
à tous les niveaux (composition, traduction, vérification,\ldots).-
[^]Re: Générateur de code OpenSource ?
Posté par Cédric Brun (page perso, ) le 04/05/2006 à 19:35. (lien). Évalué à 2.MDA c'est surtout une marque déposée (par l'OMG) contrairement à MDE.
-
[^]Re: Générateur de code OpenSource ?
Posté par Alexis Muller (page perso, ) le 05/05/2006 à 05:53. (lien). Évalué à 2.C'est vrai que c'est une différence, mais ce n'est pas la différence
fondamentale. Il suffit de lire les documents de l'OMG et les papiers
fondateurs du MDE.
Même si maintenant (forcement) l'OMG à fait évoluer ses idées (il ne faut
pas oublié que des académiques font aussi parti de l'OMG).
D'ailleurs il ne faut même plus parler de PIM (Platform Independent Model)
et PSM (Platform Specific Model) alors qu'à l'origine c'était la "killing
feature" du MDA ;)
-
-
[^]Re: Générateur de code OpenSource ?
Posté par Barnabé () le 05/05/2006 à 05:52. (lien). Évalué à 2.Et le MDE, il sera dépassé dans combien de temps ?
-
[^]Re: Générateur de code OpenSource ?
Posté par Alexis Muller (page perso, ) le 05/05/2006 à 05:57. (lien). Évalué à 3.Vu que le MDE est une voie de recherche et non un "produit"...
Je dirais dans 10 ans. Mais si cette voie est aussi prometteuse
qu'elle n'y parait, alors dans 10ans on compilera des modèles ;)
-
-
[^]Re: Générateur de code OpenSource ?
Posté par Antoine () le 06/05/2006 à 10:43. (lien). Évalué à 0.Le bénéfice attendu est de pouvoir capitaliser la description de ta
solution et ainsi pouvoir passer d'une plate-forme à l'autre au fil des
évolutions
Je vois :
au lieu de réécrire quand il faut changer de "plateforme", on réécrit quand il faut changer de "modèle", de "langage de spécifications", voire d'"approche" ou de "technologie"
Hum... super...-
[^]Re: Générateur de code OpenSource ?
Posté par Alexis Muller (page perso, ) le 07/05/2006 à 07:47. (lien). Évalué à 2.??
Non justement, tu n'as pas très bien compris. Un modèle est quelque chose qui
représente ta solution métier. Si tu veux uniquement changer le langage avec
lequel il est décrit, des outils automatiques peuvent le faire pour toi.
En effet, le modèle de ta solution doit être suffisamment précis pour ne pas
être ambigu, d'où la possibilité d'automatiser sa traduction.
Attention, je parle de traduction, on passe d'un langage de modélisation (ou
de spécification) à un autre sans ajout (et normalement perte) d'information.
Donc dans l'idée du MDE on ne modifie le modèle "du départ" UNIQUEMENT si le
métier change.
Le but est justement de capitaliser la CONNAISSANCE indépendamment de la
technologie.-
[^]illusions de la traduction
Posté par Antoine () le 08/05/2006 à 13:50. (lien). Évalué à 1.Attention, je parle de traduction, on passe d'un langage de modélisation (ou
de spécification) à un autre sans ajout (et normalement perte) d'information.
Et alors ?
On pourrait imaginer la même chose pour passer de Java à .Net, etc.
En pratique ce n'est pas souhaitable car cela donne des résultats ne tirant pas partie des idiomes de la plateforme cible, et donc très lourds (relecture difficile, etc.).
Pourquoi serait-ce différent avec les langages de modélisation ?
J'imagine que s'il y a plusieurs langages de modélisation, c'est qu'ils ont des idiomes et particularités différentes, donc qu'un processus de traduction souffrirait des mêmes défauts que cités au-dessus.
J'ai écrit il y a très longtemps un outil de traduction entre deux langages destinés à l'écriture de tests d'équipements réseaux, la traduction marchait effectivement mais le résultat était forcément loin du style de code que des êtres humains écrivaient et comprenaient dans le langage cible.-
[^]Re: illusions de la traduction
Posté par Alexis Muller (page perso, ) le 08/05/2006 à 17:33. (lien). Évalué à 1.En pratique ce n'est pas souhaitable car cela donne des résultats ne tirant pas partie des idiomes de la plateforme cible, et donc très lourds (relecture difficile, etc.).
Dans ce cas, le problème vient soit du traducteur qui était mal fait, soit du
fait qu'en partant d'une implantation (Java par exemple) on ne dispose pas
d'assez d'éléments "de haut niveau" sur le problème pour faire une
transformation efficace. En effet, avec une implantation on peut trouver le
comment mais pas le pourquoi.
Lorsque tu lis du code, si tu es comme moi, tu cherches à trouver ce que fait
le programme. Le code lui même ne suffit pas, il faut déjà savoir quel est le
problème qui doit être résolu, dans quel contexte... bref tous les éléments qui
était avant décrit comme de la documentation (nom des variables,
commentaires,...)
L'idée pour pouvoir faire des transformations de qualités c'est de prendre ces
éléments en compte, et donc de partir du modèle et non du code.
Pourquoi serait-ce différent avec les langages de modélisation ?
Justement parce-qu'un modèle est sensé avoir une sémantique de plus haut niveau
que du code.
J'imagine que s'il y a plusieurs langages de modélisation
En pratique, pas vraiment. Le langage UML est considéré comme le langage de
modélisation standard (et MOF le langage de méta-modélisation) et a part
Microsoft (qui à dit comme d'hab ? ;), les académiques et industriels le
suivent. C'est la plus belle réussite de l'OMG je pense.
Mais il est vrai qu'on ne peut pas tout modéliser en UML, comme des systèmes
mathématiques ou physiques.-
[^]Re: illusions de la traduction
Posté par Etienne Juliot (page perso, ) le 09/05/2006 à 12:30. (lien). Évalué à 1.Je ne suis pas à 100% d'accord avec toi.
Antoine a raison de dire que UML sera peut être dépassé un jour et que dans ce cas on pourrait se retrouver dans le même cas qu'avec un langage devenu désuet.
C'est d'ailleurs une des principales raisons d'être de la notion de méta-modèle.
Ainsi, un modèle réalisé en UML peut facilement être transformé en un autre formalisme, sans pour autant perdre le sens de ce qui a été modélisé.
Pour compléter ce que tu dis, il n'y a pas que UML dans la vie, et je pense justement qu'on va très bientôt assister à une nouvelle vague d'outils et de normes qui compensent ses faiblesses et ses lourdeurs.
Je ne remet pas en question UML qui est très bien : je dis juste que ce n'est pas une solution universelle pour tous les besoins de la Terre.
C'est ce qu'on appelle l'approche DSL, et justement, à Obeo, nous travaillons fortement sur ce sujet afin de proposer une alternative à la solution Microsoft.-
[^]Re: illusions de la traduction
Posté par Alexis Muller (page perso, ) le 10/05/2006 à 07:36. (lien). Évalué à 1.Antoine a raison de dire que UML sera peut être dépassé un jour et que dans ce cas on pourrait se retrouver dans le même cas qu'avec un langage devenu désuet.
Oui, je ne dit absolument pas que UML est le parfait langage de modélisation,
je ne le pense même pas. C'était juste une précision sur l'état actuel des
choses.
C'est d'ailleurs une des principales raisons d'être de la notion de méta-modèle.
Ainsi, un modèle réalisé en UML peut facilement être transformé en un autre formalisme, sans pour autant perdre le sens de ce qui a été modélisé.
C'est ce que je veux faire comprendre à Antoine. Le but est de capitaliser la
connaissance, peut importe le langage et modélisation utilisé.
Ca ne pouvait fonctionner avec les langages de programmation, parce-que le code
prend en compte beaucoup de préoccupation technique et fait "disparaître" une
grande partie de la connaissance qui reste dans la tête du programmeur.
C'est ce qu'on appelle l'approche DSL
Cette approche à été étudiée en profondeur pour les langages de programmation.
On devrait plutôt appeler ça l'approche DSML (Domain Specific Modelisation
Language) ;)
-
-
-
-
-
-
-
-
-
-
Ca a l'air chouette
Et ils font pas les choses a moitie:
- support de tous types de technologies en sortie,
Ca c'est de l'exhaustivite :)
-
[^]Re: Ca a l'air chouette
Posté par Etienne Juliot (page perso, ) le 03/05/2006 à 16:00. (lien). Évalué à 2.En fait, ca veut surtout dire que Acceleo n'est pas spécialisée dans un langage cible.
Il existe déjà d'autres générateurs pour tel ou tel framework, mais à chaque fois, ils réinventent la roue et sont spécialisés dans la techno ciblée.
Là, Acceleo est architecturé lui même sous forme de plugins de génération. Tu peux ainsi rajouter ton propre module de génération vers la techno de ton choix. Et tu gardes un seul système de génération. Ca permet d'avoir quelque chose de cohérent et plus simple à maintenir.-
[^]Re: Ca a l'air chouette
Posté par Thomas Douillard () le 04/05/2006 à 12:46. (lien). Évalué à 2.Pour compléter, d'après ce que je connais de MDA, c'est tout à fait adapté pour ce genre de chose, on part d'un modèle de haut niveau (UML, typiquement) pour le transformer (littéralement je crois) en des modèles de niveaux plus bas, niveau langage de prog en particulier.
Ce genre de techno basées sur les modèles est très utile dans tout ce qui est migration par exemple, basiquement, on fait un modèle du programme dans un langage, et on applique des transformations pour le transformer en un modèle du même programme dans un autre langage.-
[^]Re: Ca a l'air chouette
Posté par Ontologia (page perso, ) le 04/05/2006 à 15:29. (lien). Évalué à 2.Pour faire ça, à la limite tu as mieux : CodeWorker.
CodeWorker est une sorte de compilateur de compilateur. Il peut faire plein de choses : manger une grammaire BNF et recracher du code à partir de l'arbre syntaxique, faire de l'injection de code, etc...
Un tutoriel de son auteur aseez accessible.
http://cedric-lemaire.developpez.com/DecouverteCW/index.php
A la lmite, on pourrait faire marcher les deux : Avec CodeWorker on extrait un modèle (UML par exemple) du programme à migrer à partir du code et on se sert de Acceleo pour faire la migration.-
[^]Re: Ca a l'air chouette
Posté par Thomas Douillard () le 04/05/2006 à 15:36. (lien). Évalué à 2.En fait, si j'ai bien compris, la grammaire BNF peut être considérée du point de vue model engeniering comme un meta-modèle des programmes écris dans le langage qu'elle décris. L'approche modèle est cependant plus puissante, quelque part, elle permet de manipuler plusieurs niveaux d'abstractions.
-
-
-
Compatibilité Linux
Pour info, la version 1.0 n'est pas compatible Linux.
On peut dire "qu'elle marchote", mais elle n'est pas utilisable concrètement.
C'est principalement dû au framework EMF qui gèrait mal l'encoding et les chemins dans les fichiers XMI. Il y avait aussi plusieurs problèmes dans Acceleo.
Tout ça sera corrigé dans la prochaine version compatible avec Eclipse 3.2 et la nouvelle version EMF (la fondation Eclipse prévoit de la sortir en juin).
Premières impressions
Je viens d'essayer Acceleo et ca déchire.
J'avais essayé il y a quelques temps d'autres générateurs comme AndroMDA ou ModFact, et je n'ai pas été du tout convaincu. Là, le projet est pas mal du tout, surtout pour une V1.
Déjà, un premier truc bienvenue est la facilité d'installation. Pas de fichier de conf, de scripts à 2 balles, de paramétrage : ca larche directe et c'est directement utilisable dans Eclipse.
Et perso, j'aime bien les softs Eclipse qui sont peu intrusifs. Genre, les applis qui ont des centaines de menus / wizards / boite de dialogue, ca me gave un peu. Là, c'est dans la mentalité de l'environnement standard d'être 100% intégré.
J'ai fait un peu mumuse avec la syntaxe et le générateur d'exemple livré, et ca marche bien.
-
[^]Re: Premières impressions
Posté par Antoine () le 06/05/2006 à 10:44. (lien). Évalué à 0.Je viens d'essayer Acceleo et ca déchire.
Tu utilises une Suse et tu es J2EE Lead Architect ? ;)-
[^]Re: Premières impressions
Posté par Altani Xavier () le 12/05/2006 à 13:34. (lien). Évalué à 0.Je ne vois pas le rapport.
Je l'utilise sous Windows (c'est quand même génant qu'Acceleo ne soit pas compatible Linux, mais bon, il paraît que ca ne devrait pas tarder).
Après 2 semaines d'utilisation, ca marche bien. J'ai eu quelques problèmes mineurs d'encoding que j'ai soumis aux dév. Ca devrait être corrigé dans la prochaine version.
-
Intérêt dans le monde du libre
Ce genre de technologies est clairement pertinent dans le monde du libre où les modules permettant de générer du code (sous licence libre) peuvent être ré-utilisés d'un projet à un autre.
En effet on peut tout à fait générer un squelette complet d'application QT ou GTK, avec classes d'accès au données, prototype d'IHM, Makefiles et autres à partir du modèle de conception.
On obtient alors un prototype fonctionnel de l'application, de plus il sera forcément très cohérent en terme de syntaxe.
La création de modules de génération est simple, il s'agit d'un système utilisant des templates. On retrouve bien la structure du code généré dans les templates de génération.
À quand un premier module de génération vers PyQT avec une petite persistance ZODB ? :)
Quelques questions
Tout d'abord, bravo pour le travail fournis et pour le choix de la licence; bravo pour l'ambition du projet, il donne envie :-) !
Maintenant, quelques questions et remarques :
- La doc sur le systeme de template ne permet pas de se faire une idée du produit, et encore moins de l'exploiter. C'est normal car le projet est jeune, mais dommage, on reste un peu sur sa faim.
- Les sources du plugin fournis ne sont pas très intéressants (= exploitables). Ce qui le serait, ce serait de fournir un zip du projet eclipse de ce plugin, ce qui permettrait de le modifier, voir de vous faire des retours. C'est un des buts de la mise en GPL, non ?
- Pourquoi avoir fait le choix d'un langage spécifique pour le template ? Pourquoi pas un langage existant ? Pourrait-on imaginer avoir des templates sur un langage standard ou l'on manipulerait le modèle au travers d'une API générée à la volée à partir du méta-modèle choisi ou créé ?
- Je n'ai pas trouvé trace de GMF sur le site du projet. Ca me semble pourtant être LE projet intéressant du moment dans ce domaine, mais j'ai du mal à voir comment les deux s'interfacent/se completent/se concurrencent. Quelle est votre vision des choses ?
Merci pour les réponses et bon courage et bonne chance à Obeo :-)
Cédric
-
[^]Re: Quelques questions
Posté par Etienne Juliot (page perso, ) le 04/05/2006 à 13:57. (lien). Évalué à 6.1) La doc sur le système n'est pas suffisante pour démarrer ? Peut être n'as tu pas vu la page référence http://www.acceleo.org/pages/reference/fr .
Ca devrait normalement suffire pour démarrer quelques templates.
2) En fait, on a utiliser le mode inclus dans eclipse pour exporter un plugin avec ses sources. C'est comme ça aussi qu'est proposé en téléchargement l'ensemble des projets Eclipse. On a voulu rester cohérent.
Mais pour faire plus pratique, on est en train de voir pour mettre un Subversion public. Les journées ne font que 24h, et ca viendra dès que possible.
3) Très bonne question pour le langage spécifique. On se l'est d'ailleurs beaucoup posée.
Les syntaxes existantes sont génériques, et peuvent servir à tout et n'importe quoi. Là, l'objectif est d'avoir une syntaxe dédiée au parcours et à la manipulation de modèles.
Ainsi, les problèmes de parcours de listes, d'éléments vides ou null, les liens (contenus ou référencés) sont transparents.
Exemple : si tu veux faire un constructeur avec la liste de paramètres, en tant normal, tu dois faire un iterateur + regarder le premier / dernier élément + gérer les cas d'erreur. Avec Acceleo, tu fais :
MaClasse {
construct(<%attribute.name.sep(",")%>);
}
Pour ce que tu proposes d'avoir un template sur une API générée : c'est exactement ce que fait Acceleo !!!
En gros, les étapes sont : tu crées ton métamodèle, tu génères l'API et les implémentations pour manipuler les modèles, tu manipules directement ces classes dans Acceleo et/ou dans les services Java associés.
4) Tu as raison, GMF a beaucoup d'avenir. Et je peut déjà te dire que Acceleo peut prendre en entrée des modèles conçus par GMF.
Ainsi, tu as un environnement de modélisation paramétrable, et un système de génération paramétrable. Que du bonheur.
Faudra faire une news quand GMF sortira, c'est à dire dans pas longtemps.
Cette page a été générée par Templeet en 0.1404s (dont 0.0236 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.