Le choix de l'EPL s'est imposé vis à vis de la communauté autour d'Eclipse, une grande partie des utilisateurs ne jurent que par cette license même si elle l'incompatibilité avec la GPL :'( .
Du coup ceci pose certains problèmes pour Eclipse dans son ensemble car l'inclusion d'implémentations GPL est impossible, mais l'éco-système Eclipse étant principalement constitué d'entreprises qui développe sous EPL pour ensuite décliner ces outils dans des offres commerciales il est difficile de changer ce genre de chose. Si un tel changement faisait que les développements sur Eclipse seraient fortement ralentis alors ce serait un echec pour l'utilisateur final.
"Modeling" et l'ingénierie des modèles dans Eclipse sont bien plus que Topcased. Il y'a des dizaines de projets tout aussi utiles, intéressant, et qui sont utilisés dans un cadre industriel. Ils sont issus d'individus, d'entreprises voir de chercheurs tels que l'équipe ATLAS à Nantes.
La fondation n'a *jamais* délégué quoi que ce soit à la communauté Topcased. Le modeleur Ecore est en effet intéressant et à reçu un bon accueil de la communauté mais en toute honnèteté cela représente un pouième de la totalité du code dédié à l'ingénierie des modèles dans Eclipse. Pour ce qui est d'UML il existe un certain nombre de modeleurs pour Eclipse mais celui de Topcased est probablement un des mieux finis.
on peut utiliser l'update site et directement installer la langue française. A noter que la traduction est désormais un effort entièrement communautaire (avant c'était IBM) et qu'un interface web à été mise en place pour faciliter les contributions :
A noter qu'au delà de la sortie d'Eclipse (la plateforme) on fête surtout la sortie de "Ganymede" qui représente la coopération de dizaines de projets pour sortir une version stable et cohérente à la même date.
Avec Ganymède viennent des projets extrêmement intéressants et innovants, Mylyn par exemple qui permet d'intégrer l'IDE avec bugzilla/trac ou autre. Ainsi on récupère directement les tâches/bugs et l'IDE adapte son comportement lorsqu'on lui indique que l'on commence à travailler sur une tâche donnée. Les fichiers concernés par cette tâches sont identifié au fur et à mesure du codage, si l'on passe d'une tâche à l'autre on récupère ce "contexte" qui cache les éléments non pertinents.
C'est toute l'organisation du développement qui peut s'adapter à cette philosophie "dirigée par les tâches".
Autre projet sympa : "Eclipse Communication Framework" qui permet (entre autre) de se connecter à IRC, Jabber et beaucoup d'autres IM directement depuis Eclipse. L'intérêt est - par exemple - de pouvoir éditer le même code simultanément à 2 personnes via Jabber.
Concernant la modélisation cette version apporte des améliorations remarquables, ainsi un modeleur graphique est désormais fournis pour Ecore, n'importe quel modèle peut être comparé/fusionné grâce à EMF Compare (mon projet :) ) et ATL - langage de transformation de modèles largement utilisé - est livré dans une version plus sympa pour l'utilisateur avec completion et tout le tintouin.
Autre fonctionnalité qui me change la vie : le API tooling, il est désormais possible de définir une "baseline" de l'API d'un ensemble de plugins (qui correspond à une release majeure par exemple) et l'outillage va prévenir le développeur quand ses changements sur le code source impliquent un changement d'API binaire.
Cette liste est tout sauf exhaustive, on trouve le CDT pour le développement du C et du C++, toute un ensemble d'outils dédiés au développements orientés services (SOA et SCA) sans même parler de WTP pour ce qui est du développement Web et JEE.
En bref Ganymède c'est tellement plus que ce que cette nouvelle laisse entrevoir, c'est des dizaines de personnes qui s'assurent que leurs composants respectifs sont compatibles et fonctionnent bien ensemble pour fournir une version majeure avec pléthore de fonctionnalités en Juin.
A noter qu'un plugin VI pour Eclipse existe et fonctionne superbement bien qu'il ne soit pas libre. Ainsi on a le comportement de VI dans tous les éditeurs Eclipse , que du bonheur !
Si l'on compare les outils actuels de transformations de modèle (qu'on est évidemment ammené à utiliser quand on travaille chez Obeo) ATL est sans conteste le plus agréable à utiliser :)
Je dirais que c'est probablement également pour cela qu'Obeo à choisit de travailler à partir de cette base !
Juste pour dire que le niveau de qualité de l'outillage au sein d'Eclipse pour ATL est excellent et sans conteste le meilleur actuellement en transformations de modèles.
Editeurs, complétion , tout ce qu'il faut pour transformer des modèles de manière efficace et intuitives :)
Désolé pour la latence mais j'ai profité du voyage pour prendre quelques jours en californie ;)
Cette fonctionnalité est prévue bien que clairement pas dans les priorités actuelles. Pour être plus précis on va d'abord faire un essai d'intégration avec le modeleur Ecore de "Ecore Tools". En fait notre plus gros problème c'est de présenter ces différentes versions à l'utilisateur de manière claire et utile, on est prenneur de toute idée là dessus d'ailleurs ;)
En plus des articles sur les projets open source (EMF compare pour ne citer que celui qui me concerne directement) le numéro de "programmez!" du mois de mars est résolument tourné vers les développements dirigés par les modèles, on y trouve donc un excellent article sur l'utilisation d'Acceleo pour générer du Spring.
(là encore, 100% open-source)
un module JEE plus que complet [1], un module C# pour la persistance [2] , d'autres modules un peu plus expérimentaux comme Ecore vers Python [3] ou encore Wisss [4], mais aussi un module UML vers PHP [5] et un module Zope/Plone en devenir [6]
A noter un module mindmap vers HTMl [7] qui produit des slides "à la beamer" à partir d'un modeleur graphique, et un méta-modèle dédié aux jeux vidéos, là encore en devenir [8]
C'est exactement le but, générer les 80% de taff facile à faire mais rébarbatifs et surtout les mettre à jour facilement juste en changeant ton modèle, ça n'a pas pour objectif d'éviter le codage, bien au contraire ! Par contre comme tu l'as souligné tu as, en plus du travail rébarbatif déjà effectué, un modèle métier synchronisé avec ton code.
Concernant ArchGenXML il y'a justement une ré-écriture en cours pour Acceleo au sein du module Zope/Plone :)
Ce qu'Acceleo apporte dans ces cas là c'est la possibilité de facilement personnaliser ou compléter ta génération. Tu peux venir faire un tour sur IRC, c'est "toutpt" qui s'occupe de ce module, je suis sûr qu'il serai content d'échanger à propos de cela.
Attention quand je parle de méta-modèle spécifiques je suis bien loin d'UML ! Le module JEE utilise un modèle UML stéréotypé qui est exploité pour piloter la génération, si l'on regarde la démo on voit bien que le paramétrage reste simple et permet d'obtenir un résultat respectant un les bonnes pratiques d'architectures et d'utilisation des frameworks.
Acceleo ne masque rien et les décisions ne sont pas arbitraires, on est bien sur une "boite blanche" !
'Par exemple, comment agréger plusieurs contrats d'objet métier en un seul service si on masque ce modèle intermédiaire => intervention au niveau du code généré et reverse au lieu de personnaliser le modèle)
Nop, tout l'inverse ! 2 possibilités :
1 - Le module de génération gère déjà ce cas, donc on paramètre soit via un stéréotype soit via un fichier de paramétrage.
2 - Le module de génération n'a pas prévu ce cas : on l'étend en ne redéfinissant que ce que l'on souhaite changer pour qu'il exploite un stéréotype ou un fichier de paramétrage.
D'où la syntaxe simple et l'outillage qui facilite la prise en main !
Avec une transformation M2M on obtient l'équivalent de la première étape et on laisse apparaître ce modèle intermédiaire que l'on peut enrichir et ce sans recourir à de la programmation EMF basique.
CF mon commentaire au dessus, la transformation M2M est parfois intéressante et dans ce cas Acceleo fonctionne parfaitement bien avec ATL/QVT, souvent elle séduit le décideur mais alourdi considérablement le processus de développement.
Quid de la mise à jour et de la maintenance de ce modèle intermédiaire ? Quand je change le modèle métier de départ, qu'est-ce qui change dans le modèle intermédiaire ? Quels réglages sont conservés au risque de fournir un résultat non correct ? Toutes ces questions sont importantes à traiter dans le cas d'une mise en oeuvre M2M, on peut citer par exemple Eclipse GMF avec les fichier gmfgen qui sont issus du fichier gmfmap. Leur maintenance/mise à jour peut vite tourner au casse tête et on en vient vite à préconiser de faire les changements dans le code et non pas dans le modèle de paramétrage !
La réalité c'est les désormais nombreux projets qui exploitent cette démarche, et Acceleo en particulier, au sein de SSII et d'administrations :)
Acceleo est justement né de l'expérience autour de la manipulation des autres outils que tu cite, pour "la vrai vie" et réaliser de "vrai projets", les choix effectués sont bien plus pragmatiques : simplicité, itérations courtes, intégration avec l'environnement de développement.
Les transformations de modèle, bien que séduisantes sur le papier, montrent vite leurs limites justement dans la "vrai vie". Ajouter cette étape de transformation complexifie le cycle modèle -> code et augmente les possibilité d'erreurs.
En terme de viabilité, ATL comme QVT operational et QVT relations n'ont vraiment rien à envier vis à vis des solutions propriétaires, ces langages ont été pensés par la recherche voir standardisé, ont une portée internationale et ont été éprouvés sur de nombreux projets.
Par contre, et là je te rejoins, un modèle dit de "paramétrage" peut souvent être exploité pour affiner la transformation dans la mesure où le paramétrage reste simple et que l'on peut le valider !
En effet j'ai déjà vu sur des projet des modèles de paramétrage sur un modèle UML par le biais de stéréotypes, la maintenance de cette partie du modèle UML était cruciale car toute la génération en dépendait, et il a été nécessaire de repartir sur une version "stable" du modèle de nombreuses fois pendant le projet, engendrant frustration et inefficacité.
Ces points sont primordiaux pour l'acceptation de la démarche au sein des projet, un simple fichier .properties contenant des clé/valeurs pour le paramétrage est souvent beaucoup plus efficace qu'un modèle du point du vue du développeur. Beaucoup de choses décrites par l'OMG semblent mieux de prime abord, l'expérience montre que ce n'est pas forcément le cas, ne gardons que ce qui est intéressant !
Je suis impatient d'avoir plus d'infos, n'hésites pas à échanger avec l'équipe par le biais du forum ou des mailling-list !
Pour les plugins maven ce n'est pas exactement de la roadmap à l'heure actuelle mais il y'a dejà une tâche ANT pour lancer la génération via un Eclipse "headless".
A priori une fois le mode standalone atteint ce sera "finger in the nose" pour le maven :)
UML n'est sans aucun doute pas la réponse à tout. Par contre l'intérêt d'un modèle auprès duquel tous les intervenants d'une équipe peuvent se référer ne fait aucun doute, il centralise la conception choisie et représente une abstraction dy système développé.
La génération de code rationnal rose par exemple est totalement à l'opposée de celle que l'on prône, typiquement avec rational la maintenance du modèle va être fastidieuse si l'on s'en sert pour générer car ce dernier va autant définir des éléments techniques que des éléments fonctionnels.
Ici le module de génération n'est pas une couche en plus mais bien un "assistant" pour aider à la maitrise de toutes ces couches (architectures n-tiers...) le modèle ne tient pas compte de ces choix qui sont techniques et reste centré sur les aspects fonctionnels, les objets métiers, les composants logiques...
Le module s'occupe d'orchestrer les choix techniques, si la façon dont il les orchestre ne convient pas alors il est facile de re-définir uniquement la partie qui nous intéresse pour répondre à une problématique particulière.
Quand à l'imprecision d'UML je suis tout à fait d'accord, UML est un standard basé sur le consensus "a maxima", autrement dit on peut exprimer beaucoup de choses de différentes façon voir même des choses fausses!
Il n'empèche que ça reste un formalisme bien connu des informaticiens et que c'est un excellent support pour échanger lors de la conception.
Par contre pour beaucoup de problématiques plus spécifiques la définition de son propre formalisme va être pertinente et c'est là que les méta-modèles spécifiques interviennent. Ils permettent d'avoir une modélisation plus précise, plus simple car plus proche des besoins fonctionnels et moins sujette à erreurs.
Le méta-modèle formalisant les concepts métiers d'une entreprise facilite largement les échanges MOA/MOE et du fait de sa précision est plus facilement valorisé dans une génération de code.
Nous mettons en oeuvre des approches comme celle ci régulièrement avec nos client et les résultats sont toujours intéressants, on adresse ainsi les problèmes de complexite et de précision par un langage dédié exploité par un "chef d'orchestre" qui va le traduire en architecture technique.
Pour le module UML vers Zope3 il vient tout juste d'être créée et n'a donc pas un état de stabilité suffisant pour être intégrer à la version stable, il reste cependant disponible via le SVN et toute personne intéressée et invitée à prendre part au projet !
Pour la partie commerciale avec traçabilité pour la mis en place d'une démarche alliant souplesse, transparence et ROI, les démos sont en cours de réalisation et ne vont pas tarder sur le site Obeo :)
Tout d'abord si les générateur sont évolués et qu'ils contiennent toute la logique technique (pour une classe UML je génère son interface, son implementation, une classe d'accès aux données pour MySQL, etc etc) et que par conséquent notre modèle reste purement métier, alors la correspondance entre code et modèle sera beaucoup plus facile à atteindre.
En effet dans ce cas une classe purement technique (utilitaire de formatage par exemple) ne sera ajoutée que dans le code (on ne souhaite pas l'avoir dans le modèle) et les classes métiers seront ajoutées dans le modèle car alors le développeur gagne du temps (il ajoute une classe UML, il obtient N fichiers générés).
La plupart des problèmes liés aux approches générative interviennent quand on a un mapping 1 pour 1 entre le modèle et le code, dans ce cas utiliser un modèle UML est une contrainte qui ne rapporte rien par rapport à, par exemple, faire une rétro-ingénierie du code en fin de projet.
Il n'empèche que d'avoir une traçabilité entre le modèle et le code aide énormément, surtout sur les projets impliquant de nombreuses personnes. Cela permet à tout moment de savoir d'où vient tel bout de code généré, de détecter les changements qui conduiront à une perte de code (analyse d'impact) etc etc. Pour toutes ces problématiques la société Obeo propose une version pro d'acceleo. Cette version gère la traçabilité de manière totalement transparente et intégrée à Eclipse et offre une plus grande souplesse pour la mise en oeuvre de cette démarche au sein d'une entreprise.
Tout à fait, il est possible de faire du logiciel libre comme du logiciel propriétaire avec cet outil. Acceleo comme la plupart de ses modules sont sous license EPL et peuvent par conséquent être utilisé et modifié pour à peu pret n'importe quoi.
Seul les modules WISSS et DotNet sont à l'heure actuel GPL, donc toute modification des templates de génération doit être sous GPL pour être re-distribuée, par contre cela ne bride en rien les licenses possibles pour le code généré.
Il va de soit qu'un projet GPL généré devrait fournir les modèles correspondant pour faciliter la modification par les tiers. Par contre il doit également fournir les sources car on ne cherche pas à générer 100% de l'application, une partie reste à coder !
Pour les remarques à propos du code généré verbeux et imbitable, c'est justement l'une des raisons qui ont poussé à la création d'Acceleo. Les templates sont simples à réaliser et l'on peut compléter le code généré automatiquement. Là encore l'objectif n'est pas d'avoir du 100% mais plutôt d'avoir un outil pratique et sans contraintes.
De manière générale on utilise une approche "par le bas" pour réaliser un générateur, on réalise d'abord un prototype de l'application "type" à générer, le modèle correspondant, puis on écrit les templates qui vont permettre d'avoir le même résultat automatiquement. Ainsi on est sûr d'avoir un code fonctionnel et tout aussi lisible que tu code manuel.
[^] # Re: licence Acceleo
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.3 compatible Eclipse Ganymede. Évalué à 2.
Du coup ceci pose certains problèmes pour Eclipse dans son ensemble car l'inclusion d'implémentations GPL est impossible, mais l'éco-système Eclipse étant principalement constitué d'entreprises qui développe sous EPL pour ensuite décliner ces outils dans des offres commerciales il est difficile de changer ce genre de chose. Si un tel changement faisait que les développements sur Eclipse seraient fortement ralentis alors ce serait un echec pour l'utilisateur final.
[^] # Re: UML dans les avions ?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Topcased 2.0 est sorti. Évalué à 2.
La fondation n'a *jamais* délégué quoi que ce soit à la communauté Topcased. Le modeleur Ecore est en effet intéressant et à reçu un bon accueil de la communauté mais en toute honnèteté cela représente un pouième de la totalité du code dédié à l'ingénierie des modèles dans Eclipse. Pour ce qui est d'UML il existe un certain nombre de modeleurs pour Eclipse mais celui de Topcased est probablement un des mieux finis.
[^] # Re: Français ?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Sortie de Eclipse 3.4 - Ganymede. Évalué à 5.
http://www.eclipse.org/babel/downloads.php
on peut utiliser l'update site et directement installer la langue française. A noter que la traduction est désormais un effort entièrement communautaire (avant c'était IBM) et qu'un interface web à été mise en place pour faciliter les contributions :
http://babel.eclipse.org/babel/
# Ganymède, tellement plus qu'Eclipse
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Sortie de Eclipse 3.4 - Ganymede. Évalué à 10.
Avec Ganymède viennent des projets extrêmement intéressants et innovants, Mylyn par exemple qui permet d'intégrer l'IDE avec bugzilla/trac ou autre. Ainsi on récupère directement les tâches/bugs et l'IDE adapte son comportement lorsqu'on lui indique que l'on commence à travailler sur une tâche donnée. Les fichiers concernés par cette tâches sont identifié au fur et à mesure du codage, si l'on passe d'une tâche à l'autre on récupère ce "contexte" qui cache les éléments non pertinents.
C'est toute l'organisation du développement qui peut s'adapter à cette philosophie "dirigée par les tâches".
Autre projet sympa : "Eclipse Communication Framework" qui permet (entre autre) de se connecter à IRC, Jabber et beaucoup d'autres IM directement depuis Eclipse. L'intérêt est - par exemple - de pouvoir éditer le même code simultanément à 2 personnes via Jabber.
Concernant la modélisation cette version apporte des améliorations remarquables, ainsi un modeleur graphique est désormais fournis pour Ecore, n'importe quel modèle peut être comparé/fusionné grâce à EMF Compare (mon projet :) ) et ATL - langage de transformation de modèles largement utilisé - est livré dans une version plus sympa pour l'utilisateur avec completion et tout le tintouin.
Autre fonctionnalité qui me change la vie : le API tooling, il est désormais possible de définir une "baseline" de l'API d'un ensemble de plugins (qui correspond à une release majeure par exemple) et l'outillage va prévenir le développeur quand ses changements sur le code source impliquent un changement d'API binaire.
Cette liste est tout sauf exhaustive, on trouve le CDT pour le développement du C et du C++, toute un ensemble d'outils dédiés au développements orientés services (SOA et SCA) sans même parler de WTP pour ce qui est du développement Web et JEE.
En bref Ganymède c'est tellement plus que ce que cette nouvelle laisse entrevoir, c'est des dizaines de personnes qui s'assurent que leurs composants respectifs sont compatibles et fonctionnent bien ensemble pour fournir une version majeure avec pléthore de fonctionnalités en Juin.
[^] # Re: Paquet d'aspirines...
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Sortie de Eclipse 3.4 - Ganymede. Évalué à 2.
http://www.satokar.com/viplugin/
[^] # Re: bah c est pas si mal que ça finalement
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche openSUSE 11.0 : nouvelle mouture du caméléon disponible. Évalué à 1.
[^] # Re: Outillage dans Eclipse
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Sortie de ATL 2. Évalué à 1.
Si l'on compare les outils actuels de transformations de modèle (qu'on est évidemment ammené à utiliser quand on travaille chez Obeo) ATL est sans conteste le plus agréable à utiliser :)
Je dirais que c'est probablement également pour cela qu'Obeo à choisit de travailler à partir de cette base !
# Outillage dans Eclipse
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Sortie de ATL 2. Évalué à 1.
Editeurs, complétion , tout ce qu'il faut pour transformer des modèles de manière efficace et intuitives :)
# Support EEE
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Sortie de la Mandriva Linux 2008.1 Spring. Évalué à 2.
[^] # Re: Cédric Brun est
Posté par Cédric Brun (site web personnel) . En réponse au journal EclipseCon 2008 : Modeling, Microsoft et Eclipse 4 !. Évalué à 3.
Cette fonctionnalité est prévue bien que clairement pas dans les priorités actuelles. Pour être plus précis on va d'abord faire un essai d'intégration avec le modeleur Ecore de "Ecore Tools". En fait notre plus gros problème c'est de présenter ces différentes versions à l'utilisateur de manière claire et utile, on est prenneur de toute idée là dessus d'ailleurs ;)
# Programmez ! dédié au développements pilotés par les modèles
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Revue de presse - Mars 2008. Évalué à 2.
(là encore, 100% open-source)
[^] # Re: Très interessant...
Posté par Cédric Brun (site web personnel) . En réponse au journal Démo de Wisss 0.2.0. Évalué à 2.
[1] http://www.papyrusuml.org/
[2] http://www.topcased.org/
[^] # Re: Très interessant...
Posté par Cédric Brun (site web personnel) . En réponse au journal Démo de Wisss 0.2.0. Évalué à 2.
un module JEE plus que complet [1], un module C# pour la persistance [2] , d'autres modules un peu plus expérimentaux comme Ecore vers Python [3] ou encore Wisss [4], mais aussi un module UML vers PHP [5] et un module Zope/Plone en devenir [6]
A noter un module mindmap vers HTMl [7] qui produit des slides "à la beamer" à partir d'un modeleur graphique, et un méta-modèle dédié aux jeux vidéos, là encore en devenir [8]
[1] http://www.acceleo.org/pages/module-uml2-vers-jee-java-strut(...)
[2] http://www.acceleo.org/pages/module-uml-vers-csharp/
[3] http://www.acceleo.org/pages/module-ecore-vers-python/
[4] http://www.acceleo.org/pages/module-wisss/
[5] http://www.acceleo.org/pages/module-uml2-vers-php
[6] http://www.acceleo.org/pages/module-uml2-vers-zope/
[7] http://www.acceleo.org/pages/module-mindmap-vers-html-/
[8] http://gamedsl.tuxfamily.org/index.html
Le projet est ouvert à d'autres modules ! en particulier un peu de C/C++ avec GTK/QT pourrait être top :)
# Superbe !
Posté par Cédric Brun (site web personnel) . En réponse au journal Démo de Wisss 0.2.0. Évalué à 1.
bravo Alf, c'est prometteur !
[^] # Re: Attention risque de troll inside
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.2.0 : nouveaux générateurs PHP, Python et JEE. Évalué à 1.
Concernant ArchGenXML il y'a justement une ré-écriture en cours pour Acceleo au sein du module Zope/Plone :)
Ce qu'Acceleo apporte dans ces cas là c'est la possibilité de facilement personnaliser ou compléter ta génération. Tu peux venir faire un tour sur IRC, c'est "toutpt" qui s'occupe de ce module, je suis sûr qu'il serai content d'échanger à propos de cela.
[^] # Re: Nouveaux modules ?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.2.0 : nouveaux générateurs PHP, Python et JEE. Évalué à 3.
http://www.acceleo.org/doc/obeo/fr/acceleo-2.2-guide-utilisa(...)
[^] # Re: Du code vers le modèle?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.2.0 : nouveaux générateurs PHP, Python et JEE. Évalué à 3.
Acceleo ne masque rien et les décisions ne sont pas arbitraires, on est bien sur une "boite blanche" !
'Par exemple, comment agréger plusieurs contrats d'objet métier en un seul service si on masque ce modèle intermédiaire => intervention au niveau du code généré et reverse au lieu de personnaliser le modèle)
Nop, tout l'inverse ! 2 possibilités :
1 - Le module de génération gère déjà ce cas, donc on paramètre soit via un stéréotype soit via un fichier de paramétrage.
2 - Le module de génération n'a pas prévu ce cas : on l'étend en ne redéfinissant que ce que l'on souhaite changer pour qu'il exploite un stéréotype ou un fichier de paramétrage.
D'où la syntaxe simple et l'outillage qui facilite la prise en main !
Avec une transformation M2M on obtient l'équivalent de la première étape et on laisse apparaître ce modèle intermédiaire que l'on peut enrichir et ce sans recourir à de la programmation EMF basique.
CF mon commentaire au dessus, la transformation M2M est parfois intéressante et dans ce cas Acceleo fonctionne parfaitement bien avec ATL/QVT, souvent elle séduit le décideur mais alourdi considérablement le processus de développement.
Quid de la mise à jour et de la maintenance de ce modèle intermédiaire ? Quand je change le modèle métier de départ, qu'est-ce qui change dans le modèle intermédiaire ? Quels réglages sont conservés au risque de fournir un résultat non correct ? Toutes ces questions sont importantes à traiter dans le cas d'une mise en oeuvre M2M, on peut citer par exemple Eclipse GMF avec les fichier gmfgen qui sont issus du fichier gmfmap. Leur maintenance/mise à jour peut vite tourner au casse tête et on en vient vite à préconiser de faire les changements dans le code et non pas dans le modèle de paramétrage !
[^] # Re: Du code vers le modèle?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.2.0 : nouveaux générateurs PHP, Python et JEE. Évalué à 2.
Acceleo est justement né de l'expérience autour de la manipulation des autres outils que tu cite, pour "la vrai vie" et réaliser de "vrai projets", les choix effectués sont bien plus pragmatiques : simplicité, itérations courtes, intégration avec l'environnement de développement.
Les transformations de modèle, bien que séduisantes sur le papier, montrent vite leurs limites justement dans la "vrai vie". Ajouter cette étape de transformation complexifie le cycle modèle -> code et augmente les possibilité d'erreurs.
En terme de viabilité, ATL comme QVT operational et QVT relations n'ont vraiment rien à envier vis à vis des solutions propriétaires, ces langages ont été pensés par la recherche voir standardisé, ont une portée internationale et ont été éprouvés sur de nombreux projets.
Par contre, et là je te rejoins, un modèle dit de "paramétrage" peut souvent être exploité pour affiner la transformation dans la mesure où le paramétrage reste simple et que l'on peut le valider !
En effet j'ai déjà vu sur des projet des modèles de paramétrage sur un modèle UML par le biais de stéréotypes, la maintenance de cette partie du modèle UML était cruciale car toute la génération en dépendait, et il a été nécessaire de repartir sur une version "stable" du modèle de nombreuses fois pendant le projet, engendrant frustration et inefficacité.
Ces points sont primordiaux pour l'acceptation de la démarche au sein des projet, un simple fichier .properties contenant des clé/valeurs pour le paramétrage est souvent beaucoup plus efficace qu'un modèle du point du vue du développeur. Beaucoup de choses décrites par l'OMG semblent mieux de prime abord, l'expérience montre que ce n'est pas forcément le cas, ne gardons que ce qui est intéressant !
[^] # Re: Nouveaux modules ?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.2.0 : nouveaux générateurs PHP, Python et JEE. Évalué à 1.
Pour les plugins maven ce n'est pas exactement de la roadmap à l'heure actuelle mais il y'a dejà une tâche ANT pour lancer la génération via un Eclipse "headless".
A priori une fois le mode standalone atteint ce sera "finger in the nose" pour le maven :)
[^] # Re: Du code vers le modèle?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.2.0 : nouveaux générateurs PHP, Python et JEE. Évalué à 2.
La génération de code rationnal rose par exemple est totalement à l'opposée de celle que l'on prône, typiquement avec rational la maintenance du modèle va être fastidieuse si l'on s'en sert pour générer car ce dernier va autant définir des éléments techniques que des éléments fonctionnels.
Ici le module de génération n'est pas une couche en plus mais bien un "assistant" pour aider à la maitrise de toutes ces couches (architectures n-tiers...) le modèle ne tient pas compte de ces choix qui sont techniques et reste centré sur les aspects fonctionnels, les objets métiers, les composants logiques...
Le module s'occupe d'orchestrer les choix techniques, si la façon dont il les orchestre ne convient pas alors il est facile de re-définir uniquement la partie qui nous intéresse pour répondre à une problématique particulière.
Quand à l'imprecision d'UML je suis tout à fait d'accord, UML est un standard basé sur le consensus "a maxima", autrement dit on peut exprimer beaucoup de choses de différentes façon voir même des choses fausses!
Il n'empèche que ça reste un formalisme bien connu des informaticiens et que c'est un excellent support pour échanger lors de la conception.
Par contre pour beaucoup de problématiques plus spécifiques la définition de son propre formalisme va être pertinente et c'est là que les méta-modèles spécifiques interviennent. Ils permettent d'avoir une modélisation plus précise, plus simple car plus proche des besoins fonctionnels et moins sujette à erreurs.
Le méta-modèle formalisant les concepts métiers d'une entreprise facilite largement les échanges MOA/MOE et du fait de sa précision est plus facilement valorisé dans une génération de code.
Nous mettons en oeuvre des approches comme celle ci régulièrement avec nos client et les résultats sont toujours intéressants, on adresse ainsi les problèmes de complexite et de précision par un langage dédié exploité par un "chef d'orchestre" qui va le traduire en architecture technique.
[^] # Re: Nouveaux modules ?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.2.0 : nouveaux générateurs PHP, Python et JEE. Évalué à 1.
Il y'a une démo (qui montre la version précédente) ici :
http://www.acceleo.org/pages/module-ecore-vers-python/
Pour le module UML vers Zope3 il vient tout juste d'être créée et n'a donc pas un état de stabilité suffisant pour être intégrer à la version stable, il reste cependant disponible via le SVN et toute personne intéressée et invitée à prendre part au projet !
http://www.acceleo.org/pages/developpement-introduction/
[^] # Re: Du code vers le modèle?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.2.0 : nouveaux générateurs PHP, Python et JEE. Évalué à 1.
Pour la partie commerciale avec traçabilité pour la mis en place d'une démarche alliant souplesse, transparence et ROI, les démos sont en cours de réalisation et ne vont pas tarder sur le site Obeo :)
http://www.obeo.fr
[^] # Re: Du code vers le modèle?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.2.0 : nouveaux générateurs PHP, Python et JEE. Évalué à 4.
En effet dans ce cas une classe purement technique (utilitaire de formatage par exemple) ne sera ajoutée que dans le code (on ne souhaite pas l'avoir dans le modèle) et les classes métiers seront ajoutées dans le modèle car alors le développeur gagne du temps (il ajoute une classe UML, il obtient N fichiers générés).
La plupart des problèmes liés aux approches générative interviennent quand on a un mapping 1 pour 1 entre le modèle et le code, dans ce cas utiliser un modèle UML est une contrainte qui ne rapporte rien par rapport à, par exemple, faire une rétro-ingénierie du code en fin de projet.
Il n'empèche que d'avoir une traçabilité entre le modèle et le code aide énormément, surtout sur les projets impliquant de nombreuses personnes. Cela permet à tout moment de savoir d'où vient tel bout de code généré, de détecter les changements qui conduiront à une perte de code (analyse d'impact) etc etc. Pour toutes ces problématiques la société Obeo propose une version pro d'acceleo. Cette version gère la traçabilité de manière totalement transparente et intégrée à Eclipse et offre une plus grande souplesse pour la mise en oeuvre de cette démarche au sein d'une entreprise.
Acceleo pro : http://www.obeo.fr/pages/acceleo-pro
[^] # Re: Licence de la deuxième création :)
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.2.0 : nouveaux générateurs PHP, Python et JEE. Évalué à 3.
Seul les modules WISSS et DotNet sont à l'heure actuel GPL, donc toute modification des templates de génération doit être sous GPL pour être re-distribuée, par contre cela ne bride en rien les licenses possibles pour le code généré.
Il va de soit qu'un projet GPL généré devrait fournir les modèles correspondant pour faciliter la modification par les tiers. Par contre il doit également fournir les sources car on ne cherche pas à générer 100% de l'application, une partie reste à coder !
Pour les remarques à propos du code généré verbeux et imbitable, c'est justement l'une des raisons qui ont poussé à la création d'Acceleo. Les templates sont simples à réaliser et l'on peut compléter le code généré automatiquement. Là encore l'objectif n'est pas d'avoir du 100% mais plutôt d'avoir un outil pratique et sans contraintes.
De manière générale on utilise une approche "par le bas" pour réaliser un générateur, on réalise d'abord un prototype de l'application "type" à générer, le modèle correspondant, puis on écrit les templates qui vont permettre d'avoir le même résultat automatiquement. Ainsi on est sûr d'avoir un code fonctionnel et tout aussi lisible que tu code manuel.
# Nouveaux modules ?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.2.0 : nouveaux générateurs PHP, Python et JEE. Évalué à 4.
De nombreuses autres technologies sont possibles !