[troll inside]
Excellent, à l'aide d'outil tels qu'Acceleo on va enfin pouvoir migrer de ce satané PHP vers une vrai techno !
[/troll inside]
Plus sérieusement je n'arrive pas à trouver dans la documentation la version d'UML (1.3, 1.4 ou 2.0 ?) et de XMI (2.1, ...) du modèle fournit, qu'en est-t-il ?
Est-ce que l'implémentation du méta-modèle se base sur un composant existant ? (EMF et le plugin UML2 ou bien le monde MDR ? )
Quel est le niveau de couverture du méta-modèle ? on récupère les classes ? les composants ? les d'états-transitions et diagrammes de séquences ?
Plusieurs remarques, déjà en terme d'outillage, le monde open source fournit des alternatives intéressantes.
>- le logiciel d'édition UML est lourd à utiliser (utilisation >mémoire, licence,...)
Le projet Topcased fournit un modeleur UML plus que correct directement au sein d'Eclipse. Cela facilite le passage code/modèle modèle/code car tout est intégré dans le même environnement.
> - changer un prototype de méthode demande d'abord de >faire le changement dans le modèle UML, puis regénérer le >squelette de code (travail manuel)
Des outils comme Acceleo (et plus particulièrement la version pro) permettent de faire ce genre de round-trip : je renomme ma classe générée, l'outil me propose de mettre à jour le modèle et de re-générer.
>- le logiciel UML s'interface mal avec des bibliothèques >externes déjà existantes, ce qui ajoute du travail manuel, >comme par exemple ouvrir une fenêtre de dialogue pour >spécifier un type particulier, ou inclure un fichier header .hpp >au bon endroit.
Là le problème est plus lié à l'utilisation d'UML. Le modèle doit rester un modèle de conception et par conséquent abstrait. Tout ce qui est technique est très bien dans le code source mais n'a rien à faire dans le modèle. Ainsi utiliser UML avec un outil de génération qui va faire : "une classe UML" => "une classe CPP" incite à l'utiliser comme cela, mais la plus value est alors quasi-nulle. On pourrait utiliser une retro-ingénierie java vers UML (comme en propose Topcased) ou autre et on a le même résultat : un diagramme représentant le code source. Cela n'aide pas à la compréhension, et le modèle était alors fait de nombreuses classes techniques sa modification est ardue.
Vive les modèle UML qui restent abstrait, et où chaque élément modélisé provoque la génération de 4 ou 5 fichiers !
Il y'a plusieurs démonstrations sur le site Acceleo avec des modèles UML dont les éléments sont stéréotypés "métier", "écran" et qui permettent ainsi de générer une architecture de grande qualité pour les frameworks actuels.
J'ai dû installer linux sur un portable ASUS un peu trop récent pour les autres distributions (pas de wifi, pas de réseau, pas de webcam) l'OpenSuse 10.3 beta s'en est sortie à merveille, depuis je l'utilise et les améliorations depuis la 10.2 sont notables.
Pour ce qui est des choses connues :
J'ai été mainteneur d'un pilote de tablette graphique pour Linux, j'ai réalisé un logiciel libre de vidéo-conférence pour KDE pour le réseau d'éducation et de recherche chinois, j'ai pas mal bidouillé avec Soya (moteur 3D en python), je suis maintenant leader d'un projet Eclipse (EMF compare) et en charge du générateur Acceleo.
J'ai bien sûr réalisé une tripotée de petits projets persos au fur et à mesure de mes pérégrinations, ils sont disséminés sur tuxfamily, sourceforge ou encore berlios.
J'ai aussi contribué à travers des petits patchs ou des remontées de bugs sur les logiciels que j' utilise au jour le jour.
Tout d'abord parce que c'est une énorme partage de connaissance et j'aime pouvoir lire le code source de ce que j'utilise (pour comprendre "comment?").
Parce que je sais que tous les logiciels libres que j'utilise m'*appartiennent*, que je peux en faire ce que je veux, que si ils ne me conviennent pas je peux les adapter à mes besoins.
Aussi pour la qualité technique de l'ensemble. Je m'extasie à chaque boot et démarrage du parcours réalisé en une dizaine d'années, et de la manière dont il a été réalisé : une collaboration mondiale d'individus indépendants qui arrive à obtenir un résultat si consistant!
* 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.
Évidemment ce que tu détaille là ressemble bien plus au MDA tel qu'il est définit par l'OMG cependant ce processus, basé sur un PIM suivi d'une transformation de modèles vers un PSM à depuis longtemps montré à quel point il était inefficace.
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 ?
Dites moi si je me trompe, mais si je veux générer une classe (une Action Struts par exemple) je dois remplir tous les champs du wizard ( le package, le nom de l'action, le répertoire de sortie, le fichier de sortie) ?
Comment se passe l'ajout de code dans l'action, le générateur va-t-il garder ce que j'ai ajouté ?
Lorsque je veux mettre à jour cette action, dois-je relancer le wizard ?
Puis-je garantir la cohérence entre mes actions, mes pages jsp, mes forms et mon struts-config avec Akrogen ?
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 .
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".
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 :)
On essaye d'être honnètes vis-à-vis de ce que ça fait et de ce que ça permet. De plus le fait qu'il s'agisse d'un logiciel libre garantit un certain dynamisme, on cherche vraiment à s'ouvrir un maximum aux contributions et jusqu'à maintenant ça se passe plutot bien.
Pour ce qui est de la dépendence à Eclipse, il est intéressant de savoir que EMF n'a aucune dépendance envers Eclipse, on peut tout à fait utiliser EMF au sein de n'importe quel programme, sans Eclipse.
Pour ce qui est d'Acceleo la donne est différente, il dépend à la fois d'EMF et d'Eclipse mais on pourrait tout à fait envisager d'isoler le moteur de génération et de faire en sorte qu'il ne dépende que d'EMF.
N'hésites pas à effectuer un retour sur les mailling-list ou sur le forum.
Une version beta de la ferme de module sera mise en ligne demain, elle permettra de tester l'installation d'un module depuis internet et sa mise en oeuvre en quelques clics.
La traçabilité permet de contrôler à posteriori que le code généré puis modifié à la main n'est pas en incohérence avec les modèles ou les templates de génération.
Acceleo n'est pas une version bridée de la version pro. Concrètement Acceleo est un générateur de code qui fonctionne très bien tout seul, il comprend le runtime (qui permet d'exécuter des générations) et tout l'environnement de développement de modules qui permet de construire ses propres modules de génération.
Les fonctionnalités supplémentaires offertes par la version pro sont particulièrement pertinentes lors de la réalisation de projets volumineux utilisant donc des modèles conséquents (une centaine de classes par exemple..) et particulièrement sensibles lors d'une utilisation concurrente. En terme de génération de code la couverture fonctionnelle est similaire, c'est l'intégration et la gestion du travail en équipe qui est l'atout principal de la version pro. La version Pro s'adresse donc plutôt au professionnels qui passent à l'échelle avec l'approche MDA.
Notre business model est orienté plutôt service mais aussi édition. Notre rôle est d'abord d'apporter notre savoir faire autour des approches modèles pour aider les entreprises à gagner en productivité. Nous proposons donc des prestations de conseil, des formations autour du MDA et d'Acceleo ou de technologies Eclipse (EMF, GMF...) et des des adaptations sur mesure d'outils orientés modèles. Nous travaillons aussi beaucoup à la création d'une dynamique autour de l'outil Open-Source; ce dernier permet de mettre en oeuvre la démarche de manière efficace. Et nous proposons aussi des choses complémentaires à l'approche service : des modeleurs spécifiques, des modules de génération "clefs en main" et la traçabilité.
Pour compléter ma réponse précédente, j'ajouterai qu' actuellement Acceleo est fourni avec deux exemples de génération qui
concernent Java (Servlet + DAO) et Xhtml.
Mais l'équipe Acceleo est en train d'initier un ensemble de projets
complémentaires à Acceleo qui visent à proposer à la communauté un
ensemble de modules de génération par défaut. Pour l'instant, nous avons recueilli des proposition pour Php, .Net, JEE, et Python entre autre.
La mise en place de ces modules devrait intervenir fin janvier ou février.
Toute personne intéressée pour participer à la constitution de ces
modules est la bienvenue !
Par ailleurs la société Obeo commercialise quelques modules pour JEE, .Net, Php et eclipse RCP.
Pour ce qui est de la transformation de modèle Acceleo peut tout à fait être utilisé conjointement avec ATL par exemple.
ATL est un langage de transformation développé par les chercheurs Français qui s'avère être le projet officiel d'Eclipse pour la transformation de modèles.
Il faut bien distinguer deux choses : les langages permettant de compléter la syntaxe des templates de génération, et les langages qu'il est possible de générer.
Il est possible actuellement d'ajouter du code Java que l'on appelle directement du template lors de la génération. Grâces aux projets tels que Jython ou Jruby il doit être possible d'utiliser ces langages également, à tester donc :)
Pour ce qui est du code généré il n'y a aucune limite. Le système étant basé sur des templates on peut aussi bien générer du Java que du Python ou du C, il suffit de faire les templates et l'outil offrant tous les éditeurs nécessaires la difficulté de réalisation des templates est très faible.
Il est vrai que les modules (ensemble de template) fournis à titre d'exemple sont orientés Java mais d'autres projets existent ou démarrent pour d'autres langages/technologies.
De manière assez basique les approches sont similaires, Acceleo est cependant différents sur certains points :
- OpenMDX génère effectivement vers différents frameworks (pour la persistance, la présentation) via ce qu'ils appellent des "plugins". À ce jours Acceleo ne dispose pas d'une base de module de génération open-source en dehors des modules d'exemples mais c'est clairement dans ce sens que l'on compte évoluer.
- OpenMDX ne supporte pas la génération incrémentale. Autrement dit avec cet outil on génère le code, si on le modifie il devient impossible de fusionner les modifications après une éventuelle re-génération. Acceleo permet de re-générer sans perdre les modifications apportées au code.
- Acceleo facilite la création de templates de générations (ce qu'OpenMDX appelle "plugins"). Ainsi on peut réaliser son propre template ou encore étendre un template existant en profitant d'un outillage complet (prévisualisation de la génération, complétion syntaxique, synchronisation entre le texte généré et l'élément du modèle correspondant)
- OpenMDX ne gère qu'UML. Il n'est pas possible de définir ses propres concepts et de s'en servir pour générer du texte. Acceleo est compatible avec plus de modeleurs (en particulier des modeleurs libres tels que Umbrello) et permet l'utilisation de méta-modèles personnalisés
- son intégration à un IDE (Eclipse) qui permet d'intégrer l'approche générale avec le développement du logiciel.
ça permet de mettre en place rapidement le principal du jeu après avoir décrit son fonctionnement. Il reste alors à spécifier les modèles 3D correspondants à chaque objet actif du jeu.
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 ? :)
[^] # Re: Lien vers WISSS
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/pages/rapporter-un-bug/
# Lien vers WISSS
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.
WISSS : http://www.acceleo.org/pages/module-wisss/
# Version d'UML ?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche PHiMX : outil de reverse engineering UML pour PHP5. Évalué à 1.
Excellent, à l'aide d'outil tels qu'Acceleo on va enfin pouvoir migrer de ce satané PHP vers une vrai techno !
[/troll inside]
Plus sérieusement je n'arrive pas à trouver dans la documentation la version d'UML (1.3, 1.4 ou 2.0 ?) et de XMI (2.1, ...) du modèle fournit, qu'en est-t-il ?
Est-ce que l'implémentation du méta-modèle se base sur un composant existant ? (EMF et le plugin UML2 ou bien le monde MDR ? )
Quel est le niveau de couverture du méta-modèle ? on récupère les classes ? les composants ? les d'états-transitions et diagrammes de séquences ?
# La conception est différente de la réalisation !
Posté par Cédric Brun (site web personnel) . En réponse au journal Conception de logiciel et UML. Évalué à 3.
>- le logiciel d'édition UML est lourd à utiliser (utilisation >mémoire, licence,...)
Le projet Topcased fournit un modeleur UML plus que correct directement au sein d'Eclipse. Cela facilite le passage code/modèle modèle/code car tout est intégré dans le même environnement.
http://www.topcased.org/
> - impossible de faire des diff entre 2 versions
EMF compare permet de le faire directement depuis Eclipse,, qu'elle que soit le type de modèle.
http://www.eclipse.org/modeling/emft/?project=compare#compar(...)
> - changer un prototype de méthode demande d'abord de >faire le changement dans le modèle UML, puis regénérer le >squelette de code (travail manuel)
Des outils comme Acceleo (et plus particulièrement la version pro) permettent de faire ce genre de round-trip : je renomme ma classe générée, l'outil me propose de mettre à jour le modèle et de re-générer.
>- le logiciel UML s'interface mal avec des bibliothèques >externes déjà existantes, ce qui ajoute du travail manuel, >comme par exemple ouvrir une fenêtre de dialogue pour >spécifier un type particulier, ou inclure un fichier header .hpp >au bon endroit.
Là le problème est plus lié à l'utilisation d'UML. Le modèle doit rester un modèle de conception et par conséquent abstrait. Tout ce qui est technique est très bien dans le code source mais n'a rien à faire dans le modèle. Ainsi utiliser UML avec un outil de génération qui va faire : "une classe UML" => "une classe CPP" incite à l'utiliser comme cela, mais la plus value est alors quasi-nulle. On pourrait utiliser une retro-ingénierie java vers UML (comme en propose Topcased) ou autre et on a le même résultat : un diagramme représentant le code source. Cela n'aide pas à la compréhension, et le modèle était alors fait de nombreuses classes techniques sa modification est ardue.
Vive les modèle UML qui restent abstrait, et où chaque élément modélisé provoque la génération de 4 ou 5 fichiers !
Il y'a plusieurs démonstrations sur le site Acceleo avec des modèles UML dont les éléments sont stéréotypés "métier", "écran" et qui permettent ainsi de générer une architecture de grande qualité pour les frameworks actuels.
PHP : http://www.acceleo.org/pages/module-uml2-vers-php
CSharp : http://www.acceleo.org/pages/module-uml-vers-csharp/
JEE : http://www.acceleo.org/pages/module-uml2-vers-jee-java-strut(...)
# ça marche plutôt bien :)
Posté par Cédric Brun (site web personnel) . En réponse au journal Sortie de openSUSE RC1. Évalué à 2.
Que du bonheur !
# Dans la série "participation au libre" ...
Posté par Cédric Brun (site web personnel) . En réponse au journal Et vous, avez-vous déjà participé à un LL?. Évalué à 2.
J'ai été mainteneur d'un pilote de tablette graphique pour Linux, j'ai réalisé un logiciel libre de vidéo-conférence pour KDE pour le réseau d'éducation et de recherche chinois, j'ai pas mal bidouillé avec Soya (moteur 3D en python), je suis maintenant leader d'un projet Eclipse (EMF compare) et en charge du générateur Acceleo.
J'ai bien sûr réalisé une tripotée de petits projets persos au fur et à mesure de mes pérégrinations, ils sont disséminés sur tuxfamily, sourceforge ou encore berlios.
J'ai aussi contribué à travers des petits patchs ou des remontées de bugs sur les logiciels que j' utilise au jour le jour.
# Pour plein de raisons....
Posté par Cédric Brun (site web personnel) . En réponse au journal Quelle est LA raison qui vous pousse à utiliser Linux ?. Évalué à 9.
Parce que je sais que tous les logiciels libres que j'utilise m'*appartiennent*, que je peux en faire ce que je veux, que si ils ne me conviennent pas je peux les adapter à mes besoins.
Aussi pour la qualité technique de l'ensemble. Je m'extasie à chaque boot et démarrage du parcours réalisé en une dizaine d'années, et de la manière dont il a été réalisé : une collaboration mondiale d'individus indépendants qui arrive à obtenir un résultat si consistant!
[^] # Re: MDA ? Mon c** !
Posté par Cédric Brun (site web personnel) . En réponse au journal Generate Early, Generate Often !. É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 Cédric Brun (site web personnel) . En réponse au journal Generate Early, Generate Often !. É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 ?
# Oups
Posté par Cédric Brun (site web personnel) . En réponse au journal Generate Early, Generate Often !. Évalué à 1.
http://www.acceleo.org/pages/telechargement-acceleo-2-1-1/
Merci :)
# On saisie le code dans un wizard ?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Akrogen, greffon Eclipse de génération de code, avec wizard pages décrits en XML/XUL. Évalué à 1.
Comment se passe l'ajout de code dans l'action, le générateur va-t-il garder ce que j'ai ajouté ?
Lorsque je veux mettre à jour cette action, dois-je relancer le wizard ?
Puis-je garantir la cohérence entre mes actions, mes pages jsp, mes forms et mon struts-config avec Akrogen ?
[^] # Re: zope3
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.0.0 : génération de code PHP, JEE, Java, CSharp et Python. Évalué à 1.
# Appel à contribution !
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.0.0 : génération de code PHP, JEE, Java, CSharp et Python. Évalué à 2.
Avis aux amateurs :
- Générateur PyQT/PyKDE
- Générateur Zope3
[^] # Re: utilité ?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.0.0 : génération de code PHP, JEE, Java, CSharp et Python. Évalué à 6.
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".
[^] # Re: utilité ?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 2.0.0 : génération de code PHP, JEE, Java, CSharp et Python. Évalué à 3.
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: Super !
Posté par Cédric Brun (site web personnel) . En réponse au journal Acceleo 2 en "release candidate" et ferme de modules. Évalué à 3.
Pour ce qui est de la dépendence à Eclipse, il est intéressant de savoir que EMF n'a aucune dépendance envers Eclipse, on peut tout à fait utiliser EMF au sein de n'importe quel programme, sans Eclipse.
Pour ce qui est d'Acceleo la donne est différente, il dépend à la fois d'EMF et d'Eclipse mais on pourrait tout à fait envisager d'isoler le moteur de génération et de faire en sorte qu'il ne dépende que d'EMF.
N'hésites pas à effectuer un retour sur les mailling-list ou sur le forum.
Une version beta de la ferme de module sera mise en ligne demain, elle permettra de tester l'installation d'un module depuis internet et sa mise en oeuvre en quelques clics.
[^] # Re: A essayer absolument
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 1.2. Évalué à 2.
Acceleo n'est pas une version bridée de la version pro. Concrètement Acceleo est un générateur de code qui fonctionne très bien tout seul, il comprend le runtime (qui permet d'exécuter des générations) et tout l'environnement de développement de modules qui permet de construire ses propres modules de génération.
Les fonctionnalités supplémentaires offertes par la version pro sont particulièrement pertinentes lors de la réalisation de projets volumineux utilisant donc des modèles conséquents (une centaine de classes par exemple..) et particulièrement sensibles lors d'une utilisation concurrente. En terme de génération de code la couverture fonctionnelle est similaire, c'est l'intégration et la gestion du travail en équipe qui est l'atout principal de la version pro. La version Pro s'adresse donc plutôt au professionnels qui passent à l'échelle avec l'approche MDA.
Notre business model est orienté plutôt service mais aussi édition. Notre rôle est d'abord d'apporter notre savoir faire autour des approches modèles pour aider les entreprises à gagner en productivité. Nous proposons donc des prestations de conseil, des formations autour du MDA et d'Acceleo ou de technologies Eclipse (EMF, GMF...) et des des adaptations sur mesure d'outils orientés modèles. Nous travaillons aussi beaucoup à la création d'une dynamique autour de l'outil Open-Source; ce dernier permet de mettre en oeuvre la démarche de manière efficace. Et nous proposons aussi des choses complémentaires à l'approche service : des modeleurs spécifiques, des modules de génération "clefs en main" et la traçabilité.
J'espère que cela réponds à la question !
[^] # Re: Langage supporté ?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 1.2. Évalué à 2.
concernent Java (Servlet + DAO) et Xhtml.
Mais l'équipe Acceleo est en train d'initier un ensemble de projets
complémentaires à Acceleo qui visent à proposer à la communauté un
ensemble de modules de génération par défaut. Pour l'instant, nous avons recueilli des proposition pour Php, .Net, JEE, et Python entre autre.
La mise en place de ces modules devrait intervenir fin janvier ou février.
Toute personne intéressée pour participer à la constitution de ces
modules est la bienvenue !
Par ailleurs la société Obeo commercialise quelques modules pour JEE, .Net, Php et eclipse RCP.
[^] # Re: A essayer absolument
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 1.2. Évalué à 2.
ATL est un langage de transformation développé par les chercheurs Français qui s'avère être le projet officiel d'Eclipse pour la transformation de modèles.
http://www.sciences.univ-nantes.fr/lina/atl/ ATL et l'équipe ATLAS
http://www.eclipse.org/m2m/atl/ ATL sur Eclipse
[^] # Re: Langage supporté ?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo 1.2. Évalué à 2.
Il est possible actuellement d'ajouter du code Java que l'on appelle directement du template lors de la génération. Grâces aux projets tels que Jython ou Jruby il doit être possible d'utiliser ces langages également, à tester donc :)
Pour ce qui est du code généré il n'y a aucune limite. Le système étant basé sur des templates on peut aussi bien générer du Java que du Python ou du C, il suffit de faire les templates et l'outil offrant tous les éditeurs nécessaires la difficulté de réalisation des templates est très faible.
Il est vrai que les modules (ensemble de template) fournis à titre d'exemple sont orientés Java mais d'autres projets existent ou démarrent pour d'autres langages/technologies.
[^] # Re: Un projet d'avenir...
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Sortie de Acceleo 1.1. Évalué à 4.
- OpenMDX génère effectivement vers différents frameworks (pour la persistance, la présentation) via ce qu'ils appellent des "plugins". À ce jours Acceleo ne dispose pas d'une base de module de génération open-source en dehors des modules d'exemples mais c'est clairement dans ce sens que l'on compte évoluer.
- OpenMDX ne supporte pas la génération incrémentale. Autrement dit avec cet outil on génère le code, si on le modifie il devient impossible de fusionner les modifications après une éventuelle re-génération. Acceleo permet de re-générer sans perdre les modifications apportées au code.
- Acceleo facilite la création de templates de générations (ce qu'OpenMDX appelle "plugins"). Ainsi on peut réaliser son propre template ou encore étendre un template existant en profitant d'un outillage complet (prévisualisation de la génération, complétion syntaxique, synchronisation entre le texte généré et l'élément du modèle correspondant)
- OpenMDX ne gère qu'UML. Il n'est pas possible de définir ses propres concepts et de s'en servir pour générer du texte. Acceleo est compatible avec plus de modeleurs (en particulier des modeleurs libres tels que Umbrello) et permet l'utilisation de méta-modèles personnalisés
- son intégration à un IDE (Eclipse) qui permet d'intégrer l'approche générale avec le développement du logiciel.
# Utilisation d'Acceleo pour les logiciels open-source
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Sortie de Acceleo 1.1. Évalué à 2.
http://gamedsl.tuxfamily.org/
et le premier prototype:
http://svnweb.tuxfamily.org/listing.php?repname=gamedsl+%28g(...)
ça permet de mettre en place rapidement le principal du jeu après avoir décrit son fonctionnement. Il reste alors à spécifier les modèles 3D correspondants à chaque objet actif du jeu.
[^] # Re: Générateur de code OpenSource ?
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo sort en version 1.0. Évalué à 2.
# Intérêt dans le monde du libre
Posté par Cédric Brun (site web personnel) . En réponse à la dépêche Acceleo sort en version 1.0. Évalué à 2.
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 ? :)