Cette nouvelle version d'Acceleo apporte encore un degré de finition supérieur au meilleur générateur de code de seconde génération ;-) . L'éditeur de template a été refondu pour encore améliorer leur lisibilité et faciliter leur saisie, l'interface à désormais été totalement localisée (une version Française est disponible mais attention, les documentations se réfèrent à la version anglaise), de nouvelles fonctionnalités de fond ont été ajoutées telles que les scripts génériques ou encore la gestion de l'encoding des templates et les modules de génération ont été mis à jour.
On peut citer l'apparition de Spring dans le module JEE accompagné d'une nouvelle documentation de mise en oeuvre. Le module PHP s'est enrichi d'une meilleure gestion des héritages et le module Python de diverses améliorations. La première livraison, expérimentale, de WISSS est également disponible: il s'agit d'un outillage dédié à la modélisation et la génération d'application web PHP utilisant le framework Zend : à partir d'une modélisation de type "entité/relations" le module génère les objets métiers ainsi que toute la couche d'accès aux données pour MySQL. Cette première version offre déjà le chargement des objets à la volée (lazy loading) ainsi que l'optimisation des requêtes SQL de mise à jour des objets. Un nouveau module dédié à Zope/Plone est apparu sur le site, il sera intéressant de comparer les résultats obtenus à l'aide de cet outil avec celui dédié à JEE.
Le site internet a lui aussi été mis à jour et les documentations ont été totalement re-travaillées (en particulier les versions anglaises). Bien évidement, de nombreuses corrections ont également été apportées et les nouvelles fonctionnalités sont présentées. Côté communautaire l'activité est intense sur les différents canaux de communication, en particulier sur la planète Acceleo et sur le forum. Acceleo était également présent aux dernières conférences Eclipse, "Eclipse Summit Europe" en Allemagne et "Eclipse Now You Can" à Paris par exemple.
Vous trouverez toutes ces fonctionnalités en images sur la page des nouveautés ainsi que des bundles Eclipse mis à jour spécialisés pour la mise en œuvre du MDA (Acceleo et ses modules, EMF, GMF, Topcased...).
La prochaine version d'Acceleo sera la version 3.0.0, elle apportera des changements majeurs pour permettre l'utilisation du moteur de génération en mode "standalone", c'est à dire sans Eclipse.
Un grand merci à toutes les personnes ayant fournit un retour sur le forum ou par le biais des tickets, c'est en grande partie grâce à ce dynamisme qu'Acceleo évolue aussi vite ! Rappel : Acceleo permet de mettre en oeuvre une démarche dirigée par les modèles. Cette démarche positionne le modèle (UML par exemple) au centre du développement. Un modèle + un module et Acceleo est alors capable de générer une grande partie du code du projet.
Exemple : un modèle UML détaillant les objets métiers et les écrans permet la génération des classes métiers, d'une classe pour chaque écran, des contrôleurs, des classes d'accès à la base de donnée. À la charge ensuite au développeur de compléter le code, lors de la prochaine génération ce dernier ne sera pas perdu.
La mise au point d'un module de génération pour une technologie donnée (Zope, KDE, Gnome...) passe par la création de templates. Acceleo fournit tous les outils nécessaires à la mise au point d'un tel template (éditeur avec complétion syntaxique, pré-visualisation du code généré).
Aller plus loin
- Nouveautés en images (95 clics)
- Bundles prêts à l'emploi (36 clics)
- Planet Acceleo (36 clics)
- Ferme de modules (21 clics)
# Lien vers WISSS
Posté par Cédric Brun (site web personnel) . Évalué à 4.
WISSS : http://www.acceleo.org/pages/module-wisss/
[^] # Re: Lien vers WISSS
Posté par Cédric Brun (site web personnel) . Évalué à 3.
http://www.acceleo.org/pages/rapporter-un-bug/
# Lien vers wisss
Posté par Alf (site web personnel) . Évalué à 2.
http://helpmequ.it: arrêter de fumer pour la bonne cause, http://mapetiteautoentreprise.fr : facturation libre pour les auto-entrepreneurs
# Nouveaux modules ?
Posté par Cédric Brun (site web personnel) . Évalué à 4.
De nombreuses autres technologies sont possibles !
[^] # Re: Nouveaux modules ?
Posté par Encolpe DEGOUTE (site web personnel) . Évalué à 3.
Ils ne semblent pas disponibles.
[^] # Re: Nouveaux modules ?
Posté par Cédric Brun (site web personnel) . É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: Nouveaux modules ?
Posté par Narmer . Évalué à 3.
Je suis en train de travailler sur un module de génération lié à db4o visant à remplacer toute la stack hibernate/ejb3+SGBDR qui alourdi le code, les performances et la productivité des developpeurs (troll inside ;)
Je reviendrai vers vous aussitot que j'ai une version "presentable" et stable (licence, nom des paquetage etc ), c'est une aplha pour le moment.
Je passerai surement vous voir au solutionslinux 2008.
J'attends beaucoup de la version 3.0 :> :> Elle permettra de decoupler votre moteur et pourquoi l'inclure dans des processus d'integration continue.
Avez vous prévu des plugin maven pour cette future solution ?
Merci et encore : excellent boulot ! Votre travail permet une ingénierie logicielle plus poussée et pour le coup un vrai début d'industrialisation.
bien à vous.
[^] # Re: Nouveaux modules ?
Posté par Cédric Brun (site web personnel) . É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: Nouveaux modules ?
Posté par Narmer . Évalué à 3.
J'essaierai de donner des news rapidement. Je n'aurai même pas du en parler mais encourager les equipes en montrant que leur produit a un intérêt est toujours une bonne chose.
il y'a dejà une tâche ANT pour lancer la génération via un Eclipse "headless".
Ah ! tien je ne savais pas un lien peut être ? ^_^
A priori une fois le mode standalone atteint ce sera "finger in the nose" pour le maven :)
Oui exactement, j'ai vraiment hate
A très bientot sur vos forums ou sur le salon.
Bon courage.
[^] # Re: Nouveaux modules ?
Posté par Cédric Brun (site web personnel) . Évalué à 3.
http://www.acceleo.org/doc/obeo/fr/acceleo-2.2-guide-utilisa(...)
# Licence de la deuxième création :)
Posté par Jul (site web personnel) . Évalué à 5.
Pour les modules
* Code généré :
Le code généré n'est pas soumis à la licence d'Acceleo. L'application cible peut utiliser la licence de votre choix.
* Modules de génération :
Vous pouvez créez vos propres modules librement et les redistribuer librement.
Donc si j'ai bien compris
- on peut faire du logiciel propriétaire avec ;
- et des modules propriétaires ;
(ce qui ne me dérange pas outre mesure)
PS des années que je vois des générateurs de code, et des années que je me fais les remarque suivante :
- le code généré est verbeux et souvent imbitable, donc sans le modèle chiant à déboguer ;
- le niveaux de complexité n'est pas toujours adapté ;
- le code pondu est chiant à optimisé (notamment quand on doit débrayer pour faire des grosses requêtes SQL)
Justement, dans la GPL il est dit ce que l'on doit fournir à une personne pour que ce soit libre est : "la forme préférée de modification". Si on génère du code avec un MDA, la forme préférée étant le modèle alors une application libre générée à partir d'un MDA devrait non fournir les sources, mais ce qui permet de les générer, non ?
[^] # Re: Licence de la deuxième création :)
Posté par Alf (site web personnel) . Évalué à 3.
je suis plus ou moins d'accord avec toi, mais ce n'est pas toujours un inconvénient.
Dans le cas de Wisss par exemple, le code est surement plus verbeux que s'il n'y avait pas de générateur. Mais en php, ca évite de faire des trucs dégeus comme $this->$method() où tu te retrouves à te battre pour trouver quelle est la vraie méthode appelée. En plus, ca déplace une partie de la complexité dans la génération, accélérant ainsi l'exécution. Evidemment, une des contreparties est d'avoir tendance à ne pas assez factoriser le code, ce qui est mauvais quand on met en place des systèmes de cache objets.
Pour la complexité, je dirais que la majeure partie de la complexité se trouve dans le générateur et pas dans le code généré. Sauf si tu ajoutes une surcouche au framework utilisé. Dans mon cas, j'utilise le Zend Framework pour réduire la complexité du code, mais j'ai généré une surcouche pour avoir une persistence automatique. Ca complique sûrement la lecture de la partie framework, mais ca simplifie le code métier.
Pour l'optimisation du code pondu, il y a le user code qui te permet justement de débrayer le générateur. Ma persistence automatique permet de se simplifier la vie mais bien sur, dans certains cas spécifiques, il faut faire des requêtes spécifiques, ce qui reste possible.
http://helpmequ.it: arrêter de fumer pour la bonne cause, http://mapetiteautoentreprise.fr : facturation libre pour les auto-entrepreneurs
[^] # Re: Licence de la deuxième création :)
Posté par Antoine . Évalué à 0.
"Se battre" ? C'est une blague ? Où est le problème exactement ?
PHP est une grosse daube, mais la possibilité de faire ce genre d'indirection est un des rares bons points du langage.
[^] # Re: Licence de la deuxième création :)
Posté par Alf (site web personnel) . Évalué à 1.
Et puis c'est le meilleur moyen d'obfusquer le nom d'une méthode à coup de str_replace et autres. Ce n'est pas un bon point, c'est un truc qui sauve la vie parfois, ca n'a rien à voir =)
http://helpmequ.it: arrêter de fumer pour la bonne cause, http://mapetiteautoentreprise.fr : facturation libre pour les auto-entrepreneurs
[^] # Re: Licence de la deuxième création :)
Posté par Antoine . Évalué à 1.
Ben, justement, les méthodes n'étant pas des objets, c'est un pis-aller qui vaut toujours mieux que rien.
Et puis c'est le meilleur moyen d'obfusquer le nom d'une méthode à coup de str_replace et autres
Tu peux obfusquer du code dans n'importe quel langage, même Python.
[^] # Re: Licence de la deuxième création :)
Posté par Cédric Brun (site web personnel) . É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.
[^] # Re: Licence de la deuxième création :)
Posté par Lutin . Évalué à 1.
# Du code vers le modèle?
Posté par Benjamin Poulain (site web personnel) . Évalué à 6.
J'ai pas mal utilisé Umbrello au début du développement de Linux Certif (en Python). J'ai fini par laisser tomber l'outil car le modèle divergeait de plus en plus du code.
Il faut dire que la correspondance est beaucoup plus difficile à faire pour un langage typé dynamiquement que pour pour les langages typés statiquement.
[^] # Re: Du code vers le modèle?
Posté par Cédric Brun (site web personnel) . É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: Du code vers le modèle?
Posté par Encolpe DEGOUTE (site web personnel) . Évalué à -1.
Un petit screencast ou une petite démo sur le site faciliterait sûrement la compréhension du processus qualité que vous tendez à mettre en place avec votre outil.
[^] # Re: Du code vers le modèle?
Posté par Cédric Brun (site web personnel) . É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 Jul (site web personnel) . Évalué à 2.
http://www.codinghorror.com/blog/archives/000566.html
1) je trouve ça dangereux, on peut écrire des choses simples en UML infaisable en informatique et masquer la complexité ;
2) je trouve que c'est déconnecté de l'informatique.
Quand je lis les bouquins sur l'UML et que je vois les rationnal rose (génération de code multi plateforme depuis au moins 10 ans), je trouve ça très déconnecté du vrai code et de la vrai informatique :
Mon ennemi est la complexité, plus il y a de couche à gérer plus c'est dur, donc en introduisant une surcouche je vais me poser la question où faut-il modifier, où est le bug (il y en a toujours), dans le code (90%, dans l'interpréteur 1%, dans le modèle (5%) ou la nouvelle surcouche (4%). Ok c'est peut être marginal, mais que de temps perdu quand ça arrive
Mon deuxième ennemi c'est la complexité. La plupart de nos web design sont intimement liés au système, et demande parfois des modifications drastiques de code de configurations... J'ai déjà du mal à retenir un langage, ces modules, les finesses des interpréteurs, les conf du brouteurs web, troubleshooter les virtualisations, les architectures n-tiers, les reverses proxy, les proxy authentifiants .... Avec une couche en plus, c'est un paramètre en plus à gérer. Combien mon cerveau peut il retenir d'informations ?
Mon troisième ennemi est la complexité : les informaticiens et les gens du métiers ont deux langages séparés, en france on rajoute la MOE et la MOA qui parlent ni métier ni informatique, si on se met à utiliser encore un intermédiaire par le truchement de la modélisation formelle (j'ai pas dit qu'il fallait pas modéliser, j'ai des modèles crayons papier et texte en toute lettre), ça devient carrément la tour de Babel.
Je dis pas que ça apporte rien (pas moins que la virtualisation), je dis juste que cela ne me semble pas apporter de simplification *notable* dans un métier dont le coeur consiste à lutter contre
1) la complexité (ça rajoute une couche)
2) la précision (Grande réserve sur l'UML qui veut tout et rien dire).
Bref je suis pas convaincu que le rapport gain/perte soit génial.
De toute façon aucune technologie informatique n'a jamais prouver apporter un gain de productivité > 10%, or nous ressources en temps et en connaissance étant limitée, je vais plutôt me concentrer sur l'informatique que sur la méta-informatique.
[^] # Re: Du code vers le modèle?
Posté par Gniarf . Évalué à 1.
[^] # Re: Du code vers le modèle?
Posté par Jul (site web personnel) . Évalué à 2.
C'est n'est pas un formalisme standardisé pour la modélisation ?
On m'aurait menti ?
Remarque pour moi c'est plutôt le feng shui de l'informatique, un espèce d'état d'esprit qui m'est effectivement ésotérique.
[^] # Re: Du code vers le modèle?
Posté par Gniarf . Évalué à 2.
rien ne t'empêchera de concevoir des conneries plus grosses que toi et de les exprimer avec UML pour en faire profiter tout le monde : blamer le langage c'est se tromper de coupable
[^] # Re: Du code vers le modèle?
Posté par Jul (site web personnel) . Évalué à -1.
Quand je vois des informaticiens se gausser d'XML, je pense tout de suite aux ridicules médecins de Molière dans le médecin malgré lui.
Je ne blame pas le langage, je blâme l'excès d'importance qu'on lui accorde. Il fait parti de chose soit disant importantes à maîtriser qui ne le sont pas. Je blâme la posture de savant que se donne ses utilisateurs, comme si il servait à quelque chose, et qui donnent **tant** d'importance à l'apparence.
De la même manière que j'aime pas l'UML, je n'aime pas les bonnes manières même si me tiens bien à table, je ne veux pas apprendre les différences entre genre musicaux même si j'adore écouter la musique, je n'aime pas le parler français académique même si j'adore cette langue, je n'aime pas le xhtml même si j'aime développer et utiliser des applis web, je n'aime pas la présentation cuisine nouvelle même si j'adore bien manger, je n'aime pas l'oenologie même si j'aime les bons vins.
UML est tout ça pour moi, un truc sûrement intéressant, dont on peut largement se passer pour faire de l'informatique, c'est une chose en plus à apprendre dont le bénéfice est marginal, sauf pour faire savant.
[^] # Re: Du code vers le modèle?
Posté par Gniarf . Évalué à 3.
bah sinon pouvoir se faire comprendre à coups de diagrammes divers et de petits dessins en général concis, que ca soit pour la documentation finale ou pendant la conception d'un programme pour voir si tes collègues, partenaires ou clients comprennent ce que tu veux dire, oui on peut s'en passer, oui le bénéfice est marginal si ce sont des tanches qui s'en foutent en face, oui forcément expliciter ce que tu as en tête c'est faire savant quelque part.
mais quand tu n'es plus seul face à ton clavier, ça aide quand même
[^] # Re: Du code vers le modèle?
Posté par Bozo_le_clown . Évalué à 1.
[^] # Re: Du code vers le modèle?
Posté par Jul (site web personnel) . Évalué à 1.
[^] # Re: Du code vers le modèle?
Posté par Antoine . Évalué à 0.
Je ne dois donc pas être informaticien, vu que je n'ai jamais fait d'UML, que je ne le comprends même pas et que j'en m'en tamponne joyeusement :-)
Me demande si Linus Torvalds et Dennis Ritchie comprennent et utilisent l'UML, tiens... Le standard pour se faire comprendre entre informaticiens, mis à part le code lui-même, ça reste tout de même le langage naturel.
[^] # Re: Du code vers le modèle?
Posté par Gniarf . Évalué à 2.
tu crois que je fais de l'UML pour des gruikeries, de l'assembleur, des bouts de 10 lignes en php ou perl ou sed ou autre prototype en C que je jetterais ensuite si je me dis finalement non ?
dans UML il y a des diagrammes de classes. tes Linus Torvalds et Dennis Ritchie ne risquent pas de les utiliser - d'en avoir besoin - tant qu'ils feront du C ou autre langage sans classes (ou objets). pareil pour le reste.
quand à ton langage naturel, si je dois lire du japonais pour ça, merci du cadeau. (cas rencontrés pour les langages Ruby et D, par exemple). là, les petits dessins ça va aider.
et justement pour décrire des classes et autres modèles que tu fais, ben tu vas préférer ajouter des dessins dès que tu en auras 3 ou que tu devras montrer des relations entre eux, plutot que juste un "langage naturel" chiant à lire comme à taper. alors comme là on en a un pas trop moche, relativement standardisé et des outils qui vont faire les zolis dessins - en couleur ! - à notre place...
après tu peux continuer à faire des dessins approximatifs et tremblotants sur des coins de nappes tachées de vin. c'est un choix :)
[^] # Re: Du code vers le modèle?
Posté par Antoine . Évalué à -1.
Ce genre de remarque implique qu'a contrario UML est nécessaire pour "modéliser" de gros programmes, ce qui est faux.
dans UML il y a des diagrammes de classes. tes Linus Torvalds et Dennis Ritchie ne risquent pas de les utiliser - d'en avoir besoin - tant qu'ils feront du C ou autre langage sans classes (ou objets).
N'importe quoi, il peut très bien y avoir des notions sémantiques de type objet dans des programmes codés en C. Regarde gobject ou CPython (l'interpréteur Python) pour des exemples évidents.
De manière générale, quand on code en C proprement, on définit des structures de données (référençant elles-mêmes d'autres structures) et des fonctions qui agissent sur ces structures, il n'est pas difficile d'y voir un modèle objet sous-jacent, même rudimentaire.
quand à ton langage naturel, si je dois lire du japonais pour ça, merci du cadeau. (cas rencontrés pour les langages Ruby et D, par exemple). là, les petits dessins ça va aider.
Si tes petits dessins sont annotés en japonais, ça ne va franchement pas t'aider, non.
[^] # Re: Du code vers le modèle?
Posté par Gniarf . Évalué à 1.
> Ce genre de remarque implique qu'a contrario UML est nécessaire pour "modéliser" de gros programmes, ce qui est faux.
je crois que tes notions de logique de base sont à revoir. "nécessaire", vraiment... "utile", oui. ca veut pas dire "indispensable".
tu sais au moins de quand date UML et qu'il y a eu de gros programmes écrits avant ? :)
de même pour ton rattrapage lamentable "ouin ouin mais on peut faire de l'objet en C" : dans ce cas justement , on peut utiliser UML. même les gens que tu cites. je les crois assez intelligents pour décider de s'en servir s'ils en éprouvent le besoin, toi pas, c'est triste.
> > quand à ton langage naturel, si je dois lire du japonais pour ça, merci du cadeau. (cas rencontrés pour les langages Ruby et D, par exemple). là, les petits dessins ça va aider.
> Si tes petits dessins sont annotés en japonais, ça ne va franchement pas t'aider, non.
ca tombe bien, tu as tout faux, le cadre formel apporté par cette notation fait qu'on a des informations sans avoir besoin de mots. je saurais pas que Ketitomi veut dire tir en rafale mais si je le vois hériter de Tomi il y aura une relation que j'aurais perdu si je n'avais que du baratin en japonais.
[^] # Re: Du code vers le modèle?
Posté par Antoine . Évalué à 0.
Et ça te fait une belle jambe de connaître la relation entre deux concepts que tu ne comprends pas, hein ?
même les gens que tu cites. je les crois assez intelligents pour décider de s'en servir s'ils en éprouvent le besoin, toi pas, c'est triste.
Magnifique, le passage à l'insulte par manque d'arguments. La prochaine fois, va te détendre un peu avant de répondre, merci.
[^] # Re: Du code vers le modèle?
Posté par Gniarf . Évalué à 1.
> Et ça te fait une belle jambe de connaître la relation entre deux concepts que tu ne comprends pas, hein ?
comme moi j'ai un cerveau, ca me suffira peut-être. un diagramme UML n'est qu'un élément d'information parmi d'autres disponibles
> > même les gens que tu cites. je les crois assez intelligents pour décider de s'en servir s'ils en éprouvent le besoin, toi pas, c'est triste.
> Magnifique, le passage à l'insulte par manque d'arguments. La prochaine fois, va te détendre un peu avant de répondre, merci.
tu as des excréments de poulpe dans la tête. va apprendre à lire, merci : ma phrase se lit comme : tu ne les crois pas assez malins pour décider d'utiliser tel ou tel outil si besoin.
et d'ailleurs de la part d'un cuistre qui cite comme argument d'autorité "X et Y, sommités reconnues, ne s'en servent sûrement pas" sans rien en savoir en fait, je me gausse, tu vois.
[^] # Re: Du code vers le modèle?
Posté par Antoine . Évalué à 1.
[...]
tu as des excréments de poulpe dans la tête
[...]
et d'ailleurs de la part d'un cuistre
Je vois, c'est un point de vue intéressant. Et sur UML, ton cerveau a quelque chose à nous dire ou il est trop occupé à traquer les excréments de pouple sur Internet ? :-)
[^] # Re: Du code vers le modèle?
Posté par Jul (site web personnel) . Évalué à 0.
[^] # Re: Du code vers le modèle?
Posté par Cédric Brun (site web personnel) . É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: Du code vers le modèle?
Posté par Bozo_le_clown . Évalué à 2.
Je crois que la réalité n'est pas aussi simple.
L'approche que tu préconises implique un maximum de génération automatique et de conventions implicites. La génération ne correspond pas tjs à des cas triviaux et souvent tu as besoin de t'inscrire dans un framework qui découpe ton architecture en couche. Tu dois aussi décider quelle classes vont persister dans ton SI et quelles autre sont en dehors de ton SI. Tu dois orienter la façon dont vont persister les informations (relations 1-n, ...) . Une génération en un coup n'est pas assez paramétrable et lorsque trop de code est géneré en un coup ceci devient opaque (effet boîte noire). Les sections de codes protégées ne suffisent plus pour assurer le dev incrémental. La solution est donc contrairement à ce que tu décris d'appliquer un modèle de marquage à ton modèle (profil UML) ou de passer par un modèle intermédiaire qui permet d'enrichir ton modèle avant transfomation (UML profilé ou DSL).
On parle alors de transfo M2M (Model to Model) qui génère le modèle pivot intermédiaire et on lui applique une transformation M2T (Model to Text)pour cibler le code.
Plusieurs transformations M2M peut être enchainées en amont si le besoin s'en fait ressentir.
Je regrette qu'Acceleo malgré toutes ses qualités ne couvre pas le premier aspect . Tu as bien sûr la possibilité de le coupler avec ATL mais quelle est la viabilité de cette solution face à des solutions complète telle qu' OpenArchitectureware ou d'autres propriétaires telle que celle de MIA ou encore RSA.
Rose travaille encore avec UML 1.3 et ctte norme ne propose pas de profil (seulement des stéréotypes isolés) . Rational ne le maintient plus et propose aujourd'hui RSA.
Il permet de mettre en oeuvre des transformations M2M qui ciblent soit de l'UML profilé soit de l'ecore. Les transformations M2T sont aussi couvertes avec du JET et un tooling proprio.
Aujourd'hui on est assez loin de ce que tu décris parce que ce produit est en voie d'obsolescence
[^] # Re: Du code vers le modèle?
Posté par Bozo_le_clown . Évalué à 2.
http://blog.benois.fr/post/2008/01/10/Acceleo-Module-JEE-Spr(...)
Ici on voit que le modèle en entrée est bien un modèle de conception et non un modèle d'analyse et il est bien nécessaire de le stéréotyper.
Or il est bien nécessaire de faire évoluer un modèle métier pour faire apparaitre ces classes.
Ainsi une classe métier "CompteCourant" devra être transformée en une collaboration entre un CompteCourantEntity, un CompteCourantDAO, ....etc
Avec Acceleo si on veut partir du modèle métier,
- soit on masque ce modèle intermédiaire en programmant l'étape de transformation M2M et en prenant des décisions arbitraires sans possibilité d'orienter la transfo.
'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)
-Soit on applique manuellement la transformation pour tous les objets métiers ce qui devient fastidieux.
Avec une transformation M2M on obtient l'équivalent de la première étape et on laisse apparaitre ce modèle intermédiaire que l'on peut enrichir et ce sans recourir à de la programmation EMF basique.
La transformation peut s'appuyer sur un langage de transformation (QVT/ATL ou OAW) ou bien sur un tooling (RSA)
Selon moi Acceleo seul ne suffit pas.
[^] # Re: Du code vers le modèle?
Posté par Cédric Brun (site web personnel) . É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) . É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: Du code vers le modèle?
Posté par Alf (site web personnel) . Évalué à 2.
L'idée est que j'ai des puces avec des pates et on relie les pates d'une puce à l'autre. Par exemple, je vais avoir une pate "Add Activity" qui prend deux objets en entrée et les ressort. La puce s'occupe d'associer les deux objets entre eux. Ca c'est ce que te présente le modèle, mais c'est bêtement traduit par un $objet1->add($objet2) ou $objet1->set($objet2) pour faire simple.
Pour l'instant, je n'ai pas encore de modeleur comme topcased pour UML, mais c'est prévu, et la on pourra construire des algorithmes métiers comme des petits circuits.
Pour les traitement plus complexes qu'un Add, Create, ..., rien n'empeche de définir une boite Activity toute simple pour laquelle on remplira le user code. Du coup, mes process métiers sont générés en grande partie pour les cas simples et les compliqués ne nécessitent que de toucher au code du process. Tous les liens entres les couches sont générés.
http://helpmequ.it: arrêter de fumer pour la bonne cause, http://mapetiteautoentreprise.fr : facturation libre pour les auto-entrepreneurs
[^] # Re: Du code vers le modèle?
Posté par Jul (site web personnel) . Évalué à 2.
C'est comme ça qu'on m'a présenté le VHDL, on fait des boîtes on les relie et tout .... Et c'est comme ça qu'on écrit le code VHDL. (approche top-> bottown
De même qu'on apprenait à faire des demi additionneurs avec AND et des OR, on faisait aussi du bottom-> up
Mais c'était un truc à intégrer, implicite de la microélectronique et on codait directement avec des boîtes, que l'on regroupait en boîte, que l'on cablait, que l'on regroupait ....
Et ça c'était précis, utile, et utilisé, tant en tant que tel (on retrouvait les blocs sur les dessins de circuits), que comme façon de coder. Je vois pas le besoin d'un formalisme UML quand on a une idée claire de ce que l'on veut faire, et de comment le faire. C'est le B A-BA non de visualiser son code en le séparant en bloc fonctionnel ?
[^] # Re: Du code vers le modèle?
Posté par Alf (site web personnel) . Évalué à 1.
Et bien, j'essaie de prendre le meilleur des deux, dans mes modèles, j'ai la partie données, entre les diagrammes et l'entité/relation, j'ai partie présentation avec la définition de formulaires ou de vues non éditables et finalement les process qui relient le tout en process métiers.
http://helpmequ.it: arrêter de fumer pour la bonne cause, http://mapetiteautoentreprise.fr : facturation libre pour les auto-entrepreneurs
[^] # Re: Du code vers le modèle?
Posté par Benjamin Poulain (site web personnel) . Évalué à 2.
Je ne doit pas gérer le matériel quand je fais du développement, grâce à la couche noyau.
je peut utiliser un langage de haut niveau grâce à la couche compilation.
etc...
Ajouter des couches diminue la complexité, car chaque couche est une abstraction, et tu ne dois pas connaître l'ensemble des couches pour travailler.
De mon experience, UML n'augmente pas la productivité. Mais pour diminuer la complexité, UML peut être un outil. Parfois ça fait la différence entre un projet qui finit dans les temps et un projet qui ne finit jamais.
[^] # Re: Du code vers le modèle?
Posté par Alf (site web personnel) . Évalué à 1.
Par exemple, j'étais bien content d'avoir mon générateur à partir d'UML pour notre dernier projet chez un client. Quand on a décidé après un mois de dev que les objets prospect avaient non plus une adresse mais une pro et une perso, on s'est pas emmerdé à modifier les dto, les dao, les scripts de bases. Le seul regret c'était de pas avoir généré les contrôleurs et les vues. Ca c'est pour la gestion du changement.
Pour la gestion de la complexité, dans Wisss, j'ai ajouté une surcouche de persistence. Elle s'appuie sur le Zend Framework et n'apparaît pas dans le modèle. Et concernant les choix d'implémentation, si on ne veut pas du Zend Framework + la surcouche Wisss, on utilise le générateur UML->PHP. Il n'est pas exclut que je fasse un générateur pour drupal également. Le problème étant qu'il nous faut une transfo d'UML vers Wisss et inversement. C'est un autre problème :-p
http://helpmequ.it: arrêter de fumer pour la bonne cause, http://mapetiteautoentreprise.fr : facturation libre pour les auto-entrepreneurs
[^] # Re: Du code vers le modèle?
Posté par Antoine . Évalué à 1.
C'est parce que tu es solution-driven et process-oriented !
[^] # Re: Du code vers le modèle?
Posté par Jul (site web personnel) . Évalué à 1.
Je fais un nouveau cadriciel pour permettre de gérer en 5 couches multi process model oriented un nouveau programme de gestion de temps.
J'imagine Newton qui au lieu de dire tous les corps sont attirés d'une manière inversement proportionnellement au carré de leur masse (méthode naïve sans système de modélisation), dire
en utilisant la théorie des supercordes appliquées dans le contexte de la thermochromodynamique quantique, si l'on pose que la conservation des quadrivecteurs dans la contrainte imposée selon la contrainte de l'incompressibilité des corps, alors pour le commun des mortels pour comprendre qu'une pomme tombe, il suffit juste d'écrire :
PI=1
ça me rappelle une tirade de Feynman sur les nouveaux scientifiques...
# Attention risque de troll inside
Posté par Alex G. . Évalué à 4.
Ma peur avec ce genre d'outil c'est que ça fasse les 80% de taff facile à faire (ceux qui prennent 20% du temps) et qu'il reste les 20% de taff difficile (ceux qui prennent 80% du temps).
Bref le seul intérêt que je vois est la documentation, et un travail plus clair pour le client (il a des modèles UML qu'il ne comprends pas mais qui le rassurent).
Pour info dans le monde Plone il y a ArchGenXML, http://plone.org/documentation/tutorial/archgenxml-getting-s(...) , qui génère les types de contenu, les workflow etc, à partir de diagrammes UML. Mais c'est plus simple, parce que en Zope il y a une base de donnée objet et un bon moteur de workflow. (Et si c'était ça la vrai solution ?).
[^] # Re: Attention risque de troll inside
Posté par Cédric Brun (site web personnel) . É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.
# De bon aloi
Posté par Obsidian . Évalué à 2.
Moment Capello, mais fournir au participe passé s'écrit "fourni", sans t final. Comme tous les verbes du deuxième groupe, notamment "subir".
Je le précise parce que non seulement on voit l'erreur très fréquemment, mais je me suis même fait annuler certains amendements que j'avais fait sur des articles Wikipédia. Certains croient y dur comme fer.
C'est une faute courante car les trois verbes en "ir" les plus fréquents dans le langage courant sont en fait des verbes du troisième groupe : "écrire","lire","dire". Ils finissent tous par "ire" et par "ir".
Dans le cas de "subir", c'est encore pire parce que les gens confondent avec l'adjectif "subit, subite" qui n'a rien à voir.
http://www.leconjugueur.com/php/newconjugue.php?lang=fr&(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.