Cette version de maintenance apporte la compatibilité avec Eclipse 3.3 ainsi que quelques améliorations:
- une première version stable du débogueur : il est désormais possible de positionner des points d'arrêt dans un template et de lancer une chaîne en mode "debug". Ainsi l'évaluation du template sera stoppée et pourra se faire pas à pas, permettant la vérification des objets passés en entrée et du résultat de l'évaluation d'un script.
- amélioration des éditeurs : l'éditeur de template propose encore un peu plus d'assistance par le biais de l'auto-completion sur les URI's des meta-modèles, sur l'import de services Java et l'affichage des icônes lors de la completion sur les types.
Vous pouvez jeter un oeil sur toutes ces améliorations par le biais de la page des nouveautés d'Acceleo 2.1.0 :
http://www.acceleo.org/pages/nouveautes-d-acceleo-2-1-0/
La communauté à été très active dernièrement, le débogueur, initialement prévu pour l'an prochain, à été contribué par un nouveau membre de l'équipe, les modules de génération ne sont pas en reste puis qu'un générateur C va compléter les modules JEE, CSharp, Python, Php et Java déjà présents.
Les contributions sont désormais facilitées, chaque module peut fournir un fichier de configuration qui permet à tout un chacun d'importer le module directement du dépôt SVN et ce en quelques clics: http://www.acceleo.org/pages/modifier-les-sources-d-un-modul(...)
Je rappelle qu'Acceleo est un greffon pour Eclipse, si vous souhaitez le tester sachez que cette version fonctionne à la fois avec Eclipse 3.2 et Eclipse 3.3. Vous trouverez sur la page de téléchargement des distributions Eclipse prêtes à l'emploi et fournissant Acceleo, les générateurs JEE, CSharp, Php, Java, Python, les outils de modélisation Eclipse, les modeleurs de Topcased ainsi que Mylyn.
http://www.acceleo.org/pages/telechargement-acceleo-2-1-0/
En deux mots ces bundles regroupent les meilleurs plugins pour un développement piloté par les modèles.
L' équipe est ouverte à tous les retours, tant par le biais du forum du site que par le gestionnaire de ticket. La communauté ne demande qu'à s'agrandir et à accueillir de nouveaux créateurs de modules !
# .
Posté par snt . Évalué à 2.
http://download.forge.objectweb.org/acceleo/eclipse-europa-l(...)
# Oups
Posté par Cédric Brun (site web personnel) . Évalué à 1.
http://www.acceleo.org/pages/telechargement-acceleo-2-1-1/
Merci :)
# MDA ? Mon c** !
Posté par Miguel Moquillon (site web personnel) . Évalué à 4.
Du MDA ? Non. De la simple génération d'un modèle UML vers un langage de programmation. Voilà c'est tout.
Et MDA ? C'est bien plus que ça ! Pour ceux qui ne connaissent pas, voici, grosso modo c'est qu'est MDA (Model Driven Architecture) :
- D'abord, à la source, un modèle indépendant de toute considération technique (donc de plate-forme, mais pas seulement, de frameworks aussi) : le PIM (Platform Independent Model). C'est ce que en gros on appelle le modèle d'analyse dans l'USDP (Unified Software Development Process). Le langage de modélisation utilisé pour écrire ce modèle doit respecter le MOF (un méta-langage de modélisation en gros). UML respecte le MOF. Le cycle de vie du PIM doit être géré.
- A partir du modèle PIM, peut-être généré plusieurs PSM (Platform Specific Model) à l'aide d'un ensemble de règles de transformation qui prennent en compte les choix techniques pour la future implémentation. Ceci est réalisable parce que le PSM respecte aussi le MOF. C'est en gros ce que l'on appelle le modèle du design dans USDP pour avoir une analogie. Le cycle de vie du PSM doit aussi être géré.
- A partir du PSM peut avoir lieu alors la génération vers un langage de programmation. Sauf que là, comme le langage n'est pas MOF compliant, cette partie, même si elle est indiquée (indiquer ne signifie pas spécifier) dans le MDA, ne fait pas partie vraiment du MDA. Pour s'en sortir, comme les langages de programmations ne sont pas MOF compliant, des langages MOF compliant (ce que l'on appelle aussi les profils UML) sont écrits afin de réaliser plus facilement cette génération ou plus exactement pour cacher ce problème; mais la partie transformation de ce qui est écrit dans ces derniers langages vers le langage de programmation est à la discrétion, actuellement, de l'AGL et n'entre pas dans le champs de spécification du MDA.
Vous aurez compris, les AGL ou autres outils travaillant sur les modèles UML existant sur le marché, malgrès leur "MDA compliant", ne couvrent que le dernier aspect ... et qui n'entre pas vraiment dans le champs du MDA. Cherchez l'erreur.
[^] # Re: MDA ? Mon c** !
Posté par Bozo_le_clown . Évalué à 3.
Tu es un peu réducteur.
Effectivement Acceleo ne permet pas la transformation de modèle à modèle mais juste la génération de code.
Acceleo est l'équivalent de MIA Generation mais ne propose pas l'equivalent de MIA Transformation.
Si tu veux un outil libre qui recouvre complétement le MDA, il faut t'orienter vers openArchitectureWare ( http://www.openarchitectureware.org ) sauf que pour la partie genération Acceleo est nettement plus convivial.
Le fait qu'il se base sur EMF (l'impleméntation Eclipse d'un sous ensemble du MOF) pour parser les modèles le rend donc MDA compliant.
L'avantage de cette standardisation est jutement que tous les outils même s'il ne couvre pas toute la chaîne peuvent coopérer plus simplement puisqu'il se basent tous sur le même métamodèle.
D'ailleurs au sens de MDA, le code peut lui aussi être considéré comme un modèle. La grammaire du langage est le métamodèle du code tout comme UML dipose d'un métamodèle pour decrire les modèles UML. Le MOF est le méta-méta-modèle au dessous de tous ces méta-modèles. Donc tout méta-modèle peut (devrait pouvoir) être décrit par le MOF. Du coup les profils UML que tu cites ne sont pas la seule façon d'aborder la problématique de la génération de code. Une autre école considère que plutôt que d'utiliser un langage généraliste qui s'adapte à un besoin en le spécialisant au travers d'un profil autant utiliser un langage dédié au domaine du problème et générer à partir de là.
On créé alors un Domain Specific Language.
http://en.wikipedia.org/wiki/Domain-specific_programming_lan(...)
Et là encore Eclipse fournit toutes les briques nécessaires par l'entremise de GMF (Graphical Modeling Framework).
[^] # Re: MDA ? Mon c** !
Posté par パパフラクス . Évalué à 5.
[^] # Re: MDA ? Mon c** !
Posté par Cédric Brun (site web personnel) . Évalué à 2.
D'aucune manière nous disons "Acceleo = MDA", Acceleo est une des briques nécessaires pour la mise en place d'une démarche pilotée par les modèles, concrètement c'est - selon moi - la brique la plus importante. La transformation de modèle est possible via ATL, la comparaison via EMF compare et plein d'autres projets Eclipse offrent toutes les briques nécessaires (cf les bundles).
Acceleo permet la géneration depuis un modèle abstrait (PIM) un modèle proche de la plateform (PSM) ou n'importe quel autre formalisme (DSL), c'est un projet libre dont le but n'est pas d'accumuler les buzz words mais plutôt de fournir un outil permettant aux développeurs de gagner du temps en ne s'attachant qu'aux parties du code nécessitant une vrai réflexion et de construire des applications de meilleure qualité.
Nous ne visons pas à être "conforme" MDA car cette conformité n'existe pas, comme tu l'a toi même dit la spec ne dit rien sur "Comment peut on faire pour transformer notre modèle abstrait en modèle proche de la plateforme ?", elle considère qu'il y'a un processus un peu magique qui le fait.
Ici Acceleo utilise le modèle abstrait, la description de la plateforme technique (exemple : PHP+PEAR) est dans le module de génération.
A partir du modèle abstrait et de ce module on obtient une application PHP+PEAR conforme aux specs du modèle abstrait. Ce n'est pas terminé, tout n'est pas spécifié ! Le code peut être complété par le développeur, les specs peuvent changer et l'on peut re-générer, on ne perdra pas nos ajouts successifs.
"partie transformation de ce qui est écrit dans ces derniers langages vers le langage de programmation est à la discrétion, actuellement, de l'AGL "
Ici aucune discretion, Acceleo est libre, ses modules sont libres, la transformation est joyeusement modifiable par tout un chacun.
mon avis :
Générer le code depuis un PSM n'a aucun intérêt, toutes les informations sont déjà là et modifier un modèle sera toujours plus compliqué que modifier directement le code source, une approche générative n'apporte qu'à partir du moment où l'on génère N fichiers à partir d'un élément du modèle.
Exemple : J'ai modélisé un composant, je vais générer les fichiers de description décrivant les dépendances, l'implémentation de base qui gère le cycle de vie du composant, une interface pour ceux qui veulent y accéder et une implémentation par défaut que le développeur pourra compléter.
"comme les langages de programmations ne sont pas MOF compliant,"
C'est faux, ils peuvent tout à fait l'être cependant l'intérêt est nul , en quoi manipuler un modèle conforme à un meta-modèle de code sera plus simple que de manipuler directement les fichiers de ce dernier ?
[^] # Re: MDA ? Mon c** !
Posté par Bozo_le_clown . Évalué à 2.
L'interêt du PSM vu comme ca est moindre en effet. Sauf que si tu ne passes par un PSM ca signifie que tu géneres à partir d'un modèle d'analyse ce qui est plutôt limité. L'interêt du PSM est donc bien de partir d'un modèle de conception qui introduit quand même pas mal de classes techniques. Sans compter l'interêt de modéliser et d'affiner le modèle (design patterns). Donc selon moi toutes les informations ne sont pas déjà là.
Après c'est vrai que dans la réalité la transformation PIM -> PSM ne peut pas tjs être complétement automatisée mais à mon avis cette étape intemédiaire doit apporter plus de souplesse et doit simplifier le boulot du générateur.
Après rien n'empêche d'enchaîner automatiquement la chaîne PIM->PSM->code
Mais je n'ai peut-être pas tout compris dans tes explications.
notamment
L'idée c'est que les PSM sont intégrés dans l'outil de génération et qu'on part d'un modèle métier.Si on doit revoir la conception, ca doit se faire uniquement au niveau du code selon toi.
Donc là on a directement PIM -> code.
C'est bien ça ?
[^] # Re: MDA ? Mon c** !
Posté par Cédric Brun (site web personnel) . Évalué à 3.
* Eclipse avec EMF
* Les modeleurs UML2 de Topcased et du projet MDT
* EMF compare qui permet de comparer/fusionner n'importe quel type de modèle (fonctionne aussi avec CVS et Subversion)
* Le support Subversion
* GMF qui permet de faire son propre modeleur.
* Le support OCL, de validation et de transaction d'EMF
* Acceleo avec les générateurs JEE, CSharp, Python, Php et Java
* Mylyn qui apporte l'intégration des bugzilla, trac et autres outils directement dans Eclipse
* Birt qui permet l'édition de rapports
PSM peut sembler ambigüe, je considère qu'il s'agit d'un modèle très proche du code , par exemple le modèle d'analyse définit un objet métier (une classe), pour cette classe abstraite le PSM en possèdera une douzaine d'autres : l'interface, la classe d'implémentation, le DAO qui va bien, etc etc etc.
Un PSM de ce type là n'a, selon moi, pas d'intérêt.
Cependant il me semble intéressant de paramétrer la génération (par le biais d'un modèle - que l'on peut aussi appeler PSM car il est spécifique à la plateforme technique mais généralement on l'appelle PDM) pour dire "génère selon tel ou tel motif de conception" .
Concrètement cela donne
modèle d'analyse + modèle de paramétrage => application générée.
On a donc, non pas une transformation PIM => PSM mais bien un cycle en Y où PIM et PDM permettent de cibler le code.
Cette démarche s'avère beaucoup plus profitable en pratique, un exemple dans Eclipse est l'utilisation des fichiers .ecore et .genmodel, on a bien :
.ecore : modèle d'analyse
.genmodel : modèle de paramétrage
et à partir de ces deux fichier le code Java est généré.
Le PSM peut avoir une utilité, en particulier dans l'informatique embarquée ou il est important de valider ce dernier (les coûts d'un échec n'étant pas les même). Dans l'informatique de gestion ce n'est pas le cas.
[^] # Re: MDA ? Mon c** !
Posté par Bozo_le_clown . Évalué à 2.
Tu aurais des références (livres, sites,..) qui détaillent un peu cette réflexion.
[^] # Re: MDA ? Mon c** !
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Ok, donc j'ai mal interprété le texte suivant sur la page principale :
Acceleo est un générateur de code qui permet de transformer des modèles vers du code ( approche MDA ).
Justement non. Le PIM n'a aucune information de plate-forme, PHP+PEAR par exemple. Il ne dispose donc pas d'information suffisante pour la génération de code.
D'où le PSM. De plus le PSM a un intérêt à partir du moment que l'on sache gérer son cycle de vie ... ce que n'offre actuellement aucun outil de ma connaissance; raison probable pour laquelle la transformation PIM vers PSM est vue comme inefficace.
C'est vrai, les langages de programmations ne sont pas MOF compliant : leur grammaire ne s'appuient pas sur MOF.
Par contre je suis d'accord qu'il est plus simple de modifier du code qu'un modèle.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.