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 (625 hits)-
Captures d'écran (947 hits)
-
Site de la société française qui a initié le projet (164 hits)
-
Définition du MDA (167 hits)
> Lire la dépêche (30 commentaires, moyenne: 2,3).
Vous avez demandé le commentaire #708274.
Run by 
Cette page a été générée par Templeet en 0.0792s (dont 0.0072 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
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 ?
Je me suis fait avoir comme toi au début :o))
[^]Re: Générateur de code OpenSource ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
MDA c'est surtout une marque déposée (par l'OMG) contrairement à MDE.
[^]Re: Générateur de code OpenSource ?
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 ?
Et le MDE, il sera dépassé dans combien de temps ?
[^]Re: Générateur de code OpenSource ?
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 ?
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 ?
??
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
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
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
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
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) ;)