La version 2.7 d'Acceleo est maintenant disponible. Le profiler Acceleo a été amélioré notamment lors de la génération de gros modèles. Un template extender a été ajouté, cela permet d'explicitement étendre un template à partir d'un module Acceleo. Des services utilisateurs peuvent maintenant être ajoutés comme service système. L'import des modèles provenant d'Enterprise Architect a été aussi corrigé. Les modules Acceleo C et Java ont été améliorés. Un nouveau build intégrant toutes ces modifications est disponible sur le site permettant la mise à jour du plugin. Des anomalies ont été corrigées. Jetez un œil sur la page décrivant les nouveautés en images pour plus d'informations.
Les packs Eclipse dédiés à la modélisation incluant Acceleo, ses dépendances ont également été mis à jour et fournissent comme à leur habitude l'environnement ATL pour la transformation modèle vers modèle, EMF Compare pour la comparaison de modèles, ainsi que les autres projets composant le package officiel « Eclipse Modeling » . Ces packs sont la voie royale pour qui veut tester la puissance de l'ingénierie des modèles au sein d'Eclipse.
Plusieurs versions correctives pour la branche 2.X sont prévues : la version 2.7.1 sera livrée cette année, la 2.8 en 2011. Mais comme vous le savez certainement, la nouvelle versions majeure d'Acceleo est en ce moment implémentée et cette version est un projet officiel de la fondation Eclipse. Le plus grand changement concerne la révision de la syntaxe car elle suit maintenant le standard de l'OMG "MOF Model To Text Language" (MTL) basé sur OCL. En incubation depuis environ deux ans au sein d'Eclipse, Acceleo 3.0 sera très bientôt disponible avec la release simultanée Helios d'Eclipse (Juin 2010). Acceleo 3.0 supporte déjà un niveau de fonctionnalité proche de la version 2. Des milestones "Pre-release candidate" peuvent déjà être testées.
N'hésitez pas à donner des retours par le biais des mailing-lists, du traceur d'anomalies, du forum web ou du Wiki. Merci à tous les développeurs et contributeurs impliqués dans cette version !
NdM: Acceleo est publié sous licence EPL, licence libre et Open Source, non-copyleft et incompatible GPL.
Aller plus loin
- Site web Acceleo (31 clics)
- Les nouveautés de 2.7 (12 clics)
- Page téléchargement (24 clics)
- Participer au projet (3 clics)
# FOUTAISE !
Posté par tuiu pol . Évalué à 10.
[^] # Re: FOUTAISE !
Posté par El Titi . Évalué à 2.
[^] # Re: FOUTAISE !
Posté par lolop (site web personnel) . Évalué à 2.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: FOUTAISE !
Posté par El Titi . Évalué à 2.
Dépêche éditée par
poltuiu
;)
[^] # Re: FOUTAISE !
Posté par tuiu pol . Évalué à 1.
[^] # Re: FOUTAISE !
Posté par foutaises . Évalué à 2.
# On est pas vendredi mais je m'en fous
Posté par DLFP est mort . Évalué à 5.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Antoine . Évalué à 1.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Dring . Évalué à 1.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Thomas Douillard . Évalué à 7.
Ça demande plus d'argumentation qu'un laconique "c'est stupide voir criminel", en tout cas.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Ontologia (site web personnel) . Évalué à 7.
J'ai regardé les screecast, et particulièrement celui-là : http://www.acceleo.org/screencast.php?width=858&height=6(...)
Bilan, encore un métatruc !
Effectivement c'est intéressant de pouvoir générer toutes les parties chiantes d'une bouse J2EE : Base de données, DTO, coques des DTA, coques Services, etc...
On voit bien dans le screencast à 2/3 (le temps n'est pas affiché), que le code Java, à l'intérieur du code, enfin, des coques générées, il faut se le farcir à la main.
En gros, c'est un outil moyennement intéressant, qui s'épargne d'écrire à la main le code bête et stupide que l'on trouve dans tous framework java : gestion de la BDD, prototypes des fonctions, gestions des multiples fichiers de la susdite bouse.
Mais ce qui me fait marrer, c'est qu'on continue à dessiner des boiboites, qui sémantiquement ne valent rien : un User est une simple boiboite avec le titre User, et des champs à l'intérieur.
Pire on voit à quel point c galère d'expliquer que la fonction findCategoryByName a un param String, ça prend 3 fois plus de temps que l'écrire, faut cliquer partout !
Là c'est débile.
Est-ce qu'on pourrait avoir un truc qui soit plus haut niveau où on définit les specs et qui nous génère le code à l'intérieur ?
Ou pourrait t'on définir des HFSM, des règles pour un moteur de règle, une interface à FSM tant qu'on y est.
Bref autre chose que du code qu'on est obligé de générer pour coller au framework de 20T qui accompagnent ces technos.
Je dis pas que c'est criminel, je dis que c'est stupide par certains côté, et que ce n'est pas la bonne approche d'attaquer le problème de l'industrialisation du logiciel.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Cédric Brun (site web personnel) . Évalué à 5.
- qu' Acceleo n'est qu'un outil générique qui permet de définir ses templates. On peut écrire des templates qui génèrent 100% du code ou bien des templates qui n'en génèrent qu'une partie comme dans le screencast (ça va dépendre du contexte d'utilisation)
- que si on est allergique aux boiboites ou si le formalisme choisi s'y prête moyen on peut définir sa syntaxe textuelle avec Xtext, (http://www.eclipse.org/xtext ) Acceleo s'en moque, pour lui c'est un modèle.
- que l'on choisi le niveau d'abstraction que l'on veut, on peut être très haut niveau ou très technique, voir les deux (exemple WISSS qui définit un formalisme pour les webapps, haut niveau pour le côté métier mais très précis et détaillé pour la gestion des droits).
- que c'est un outil parmi d'autres aidant à l'industrialisation, avoir un bel outil n'implique ni que l'on sache bien s'en servir ni que le problème s'est résolu par magie.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Thomas Douillard . Évalué à 2.
Pour l'aspect cliquodrome, c'est pas rédhibitoire : le genre d'approche "orienté modèle" permet en théorie, et en pratique aussi d'ailleurs, de définir facilement des langages spécifiques pour certaines tâches (les DSL) donc on pourrait très bien imaginer faire exactement la même chose et décrire le modèle dans un langage dédié.
Pour l'aspect "spec -> code", tu veux mettre quoi exactement dans tes specs ? si c'est décrire des algos à plus ou moins haut niveau, c'est possible avec le MDA je pense.
Si c'est pour qu'il trouve tout seul un algorithme pour résoudre des problèmes compliqués, ça l'est pas en l'état actuel des choses.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . Évalué à 3.
On a renoncé depuis longtemps à spécifier les aspects dynamiques d'un système au niveau le plus bas.
Mais ce qui me fait marrer, c'est qu'on continue à dessiner des boiboites, qui sémantiquement ne valent rien : un User est une simple boiboite avec le titre User, et des champs à l'intérieur.
Sauf que tu ne critiques pas le bon outil. Ici c'est le modeleur mais on peut parfaitement définir son propre langage de modélisation dédié (Domain Spécific Language) y compris purement textuels (voir le projet xText).
Ensuite ici, il existe des modeleurs UML en mode texte qui peuvent faire l'affaire et tu n'es pas non plus obligé de faire un diagramme de classe, ca n'est qu'une démo.
Sinon cet usage des DSL en lieu et place de l'UML se démocratise maintenant que les outils commencent à arriver à maturité(voir Eclipse Modeling Framework)
Et là Acceleo et d'autre générateurs Eclipse répondent aussi à ton besoin.
Après, il y a une chose que tu oublies avec cette approche, c'est qu'elle centralise tes informations. A partir du même modèle tu peux aussi générer toute la tuyauterie pour les web services, cibler une autre architecture dans un environnement hétérogène, migrer vers un autre framework, ...
L'avantage c'est que toutes les parties prenantes partagent le même modèle et parlent le même langage. Ca facilite les échanges et c'est plus simple d'envoyer un bout de modèle à des développeurs de la couche noyau et à ceux qui sont chargés du middleware et de regénérer les docs de specs pour les AMOs, que de mettre à jour qui les WSDL, qui les contrats d'interface et qui les documents à la main.
Pire on voit à quel point c galère d'expliquer que la fonction findCategoryByName a un param String, ça prend 3 fois plus de temps que l'écrire, faut cliquer partout !
Ici, c'est comme le paradigme "convention over configuration". Ca te génère avec des présupposés. Ensuite, tu peux éditer ton code ou surcharger le modèle pour prendre en charge les spécificités. Libre à toi de choisir. Après, cette information saisie dans le modèle peut-être utile pour d'autres régénérations ultérieures (modèles qui évoluent en fonction des specs) ou pour d'autres cibles.
Mais si tu veux du "one shot", évidemment, c'est une perte de temps.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Antoine . Évalué à 1.
Par ailleurs cette fonction aurait dû s'appeler findCategoryByNameAsString.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par yellowiscool . Évalué à 6.
findCategoryByNameAsStringThatInheritsFromObjectAndImplementsAlsoCharSequenceAndComparableAndSerializableTogetherEnvoyé depuis mon lapin.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par lolop (site web personnel) . Évalué à 2.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: On est pas vendredi mais je m'en fous
Posté par kadreg (site web personnel) . Évalué à 4.
d'ailleurs, métatruc, tu vas prendre froid.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Dring . Évalué à 3.
C'est très joli, mais les IDE modernes font déjà 99% de ce travail. Quand je veux faire un nouvel objet, je tape juste son nom, la liste de ses propriétés et la complétion fait le reste. Il y a aussi la notion de template et d'assistant pour les morceaux plus complexes.
La plus value à ce niveau là me semble vraiment ridicule.
Si je dois chercher un intérêt, c'est plutôt dans le fait de me focaliser sur un modèle graphique plutôt que sur du code. Mais personnellement, après toutes ces années de code, je me sens plus à l'aise avec du code dont je peux prévoir le comportement qu'avec un générateur automatique que je ne maîtrise pas.
D'autre part, j'ai déjà vu pas mal de projets se fourvoyer à passer des heures, que dis-je des jours et des semaines à créer un zoli modèle UML, à générer un squelette avec, puis à progressivement tout réécrire à la main parce que le "code obtenu n'était pas maintenable" ou "la bidirectionnalité merdait" ou "le générateur n'exploitait pas telle nouvelle fonctionnalité/tel nouveau framework", et j'en passe et des meilleures.
D'où ma question sans réponse pour l'instant (enfin, j'ai pas fini de lire le thread) : est-ce que quelqu'un a déjà vu un gros projet utiliser ce type d'outil ? Est-ce que ça a survécu avec le temps ?
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Ontologia (site web personnel) . Évalué à 2.
Car dans ce cas ça peut avoir un quelconque intérêt, pour générer le "code à faible valeur ajoutée" (la bouse à framework est son autre petit nom)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Cédric Brun (site web personnel) . Évalué à 1.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . Évalué à 2.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Ontologia (site web personnel) . Évalué à 2.
Dommage !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Cédric Brun (site web personnel) . Évalué à 1.
Après tout c'est un logiciel libre, il ne faut surtout pas hésiter à le rendre plus utilisable pour vos cas d'utilisation.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . Évalué à 2.
Tout dépend de l'usage que tu en fais.
Cf. ma réponse à ton post plus bas.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Cédric Brun (site web personnel) . Évalué à 1.
La génération est intéressante si à partir d'un élément modélisé tout un ensemble de choses sont générées : fichiers de paramétrages, doc, code avec API/implémentation. A partir de là on gagne vraiment en efficacité. Il est assez facile de voir que si on l'utilise ainsi (1 élément dans le modèle donne n éléments dans le code source) on ne souhaite pas et surtout on ne *peux* pas faire le chemin inverse dans beaucoup de cas.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Ontologia (site web personnel) . Évalué à -2.
T'es quoi, encore un ingénieur qui rêve avec ses beaux modèles, et qui fait trimer les pauvres développeurs se démerder avec toutes les conséquences de ses modèles tout beaux tout propres qui te font mousser ?
Excuse moi, mais ça me gonfle profondément.
Si tu pars avec ce genre de ton suffisant, t'es pas prêt d'imposer ton approche MDA, parce que nous les développeur on continuera à gueuler et démontrer par A + B que ça nous emmerde et nous fait perdre du temps.
De l'expérience que j'en ai eu (certes pas Acceleo, mais un concurrent) c'est une perte de temps totale. Comprendre j'aurai fait 100 fois mieux avec un script perl de 200 lignes, ce que j'ai d'ailleurs fait discrètement à la fin, parce que ça devenait ingérable.
Fait toi passer pour un dev Bac + 2, va faire le grouillot dans une SSII pour apprendre ce qu'est la réalité, et tu calmera ton ton peremtoire.
J'ai entendu des milliers de fois ton refrain "un projet bien fait est modélisé dès le début"
Ca marche pas p**** ! Parce que le modélisateur aussi doué qu'il est loupe des concepts, que le client a changé d'avis, que le framework Y marche pas sur tel fonctionnalité et qu'il faut changer pas mal de truc dans le code généré parce que tel truc s'implémente plus de la même façon, etc...
J'en ai eu plein des cas comme ça, et à cause de ça on a été obligé de jeter les boiboites et de bosser à la main sur du code généré, génial !
Votre truc de métatruc ça sera très bien quand ça sera bijectif, pas avant, fou toi le dans le crane.
Merci.
Et c'est pas parce que t'as quelques exemple qui ont eu la chance de marcher, que ça se généralisera.
Descend sur terre ! (et arrête de nous prendre pour des glandus)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Cédric Brun (site web personnel) . Évalué à 3.
J'ai entendu des milliers de fois ton refrain un projet bien fait est modélisé dès le début
Je dis tout à fait le contraire mais apparemment tu entends ce que tu veux, cet outil te permet justement d'itérer et de remettre en cause le modèle en permanence, c'est tout l'intérêt. Personne ici ne dit que c'est *la* solution mais c'est utile. D'ailleurs on est toute une boite (Obeo) à mettre en oeuvre ces solutions chez des clients et le moins qu'on puisse dire c'est que le retour est très positif, surtout de la part des développeurs justement...
Pour info Acceleo a été créé justement sur la base des retours concernant d'autres outils, il est probable qu'il s'agisse d'un de ceux là...
Votre truc de métatruc ça sera très bien quand ça sera bijectif, pas avant, fou toi le dans le crane.
Et bien non toujours pas, la bijectivité implique que l'on a autant d'informations dans le modèle que dans le code, de mon côté j'aime autant développer directement dans ce cas.
Pour info j'ai les deux technologies à ma dispositions (Obeo édite une solution bijective) et pour autant au sein de mon équipe on utilise Acceleo car ça correspond bien mieux à nos contraintes.
Dans tous les cas je t'invite à essayer, peut être que tu trouvera alors des arguments plus constructifs que mais tu n'y connais rien ou ça marche pas et puis c'est tout
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Ontologia (site web personnel) . Évalué à 2.
Je dis tout à fait le contraire mais apparemment tu entends ce que tu veux, cet outil te permet justement d'itérer et de remettre en cause le modèle en permanence, c'est tout l'intérêt. Personne ici ne dit que c'est *la* solution mais c'est utile. D'ailleurs on est toute une boite (Obeo) à mettre en oeuvre ces solutions chez des clients et le moins qu'on puisse dire c'est que le retour est très positif, surtout de la part des développeurs justement...
Pour info Acceleo a été créé justement sur la base des retours concernant d'autres outils, il est probable qu'il s'agisse d'un de ceux là...
Votre truc de métatruc ça sera très bien quand ça sera bijectif, pas avant, fou toi le dans le crane.
Et bien non toujours pas, la bijectivité implique que l'on a autant d'informations dans le modèle que dans le code, de mon côté j'aime autant développer directement dans ce cas.
Quand je dis bijectif, je demande juste si ton outil respecte le code qui est inséré dans les fonctions, et ne modifie que le prototype de la fonction.
Cela veut dire aussi qu'une modif du prototype de la fonction (typiquement je rajoute un paramètre) est bijectif ?
J'ai bien compris que ton modèle ne représente pas les traitement et que ça n'a pas lieu d'être. je parle de bijectivité pour la sémantique que le modèle est capable de représenter, pas tout le code, c'est évident.
L'itératif c'est très bien si ça te permet de coder dans le corps de la fonction en pouvant changer le modèle, et donc changer le prototype de la fonction (typiquement rajouter mon paramètre) de manière itérative, sans m'effacer le code que j'ai écris.
Si c'est pas ça c'est la plaie.
Si c'est ça, c'est génial, et là je te présente mes excuses, j'ai mal compris et réagi de manière épidermique suite à plusieurs mois de souffrances.
Si en plus le modèle se change si je change mon paramètre dans le code, là c'est encore plus génial !
Dans tous les cas je t'invite à essayer, peut être que tu trouvera alors des arguments plus constructifs que mais tu n'y connais rien ou ça marche pas et puis c'est tout
Si tu répond positivement plus haut, faudrait que je vienne faire un stage chez vous pour me faire pardonner ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On est pas vendredi mais je m'en fous
Posté par ylussaud . Évalué à 2.
Apres si tu fais une modification hors de ces balise c'est mal. Pourquoi ? Il y a deux cas de figure :
- tu changes du code generee a partir du modele => au lieu de changer le code il faut changer le modele (un nom de methode par exemple get<nom attribut> il faut changer le nom de l'attribut dans le modele)
- tu change du code produit par un template => au lieu de changer le code il faut changer le template (par exemple changer le prototype d'un traitement pour passer un progress monitor)
Yvan
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Cédric Brun (site web personnel) . Évalué à 1.
http://www.obeo.fr/pages/obeo-traceability
Il y'a un certain nombre de démos pour se faire une idée. Ce n'est cependant pas encore la panacée et il reste du travail pour gérer tous les cas possibles. Côté stage on est plein mais l'année prochaine, qui sait ;)
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Ontologia (site web personnel) . Évalué à 2.
Ca se configure simplement d'utiliser un DSL text sur votre techno ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Cédric Brun (site web personnel) . Évalué à 1.
http://www.eclipse.org/xtext
Dernier exemple en date : protocol buffers
http://blog.efftinge.de/2010/04/googles-protocol-buffers-imp(...)
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . Évalué à 2.
Vous filmez ca avec quoi ?
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Cédric Brun (site web personnel) . Évalué à 1.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . Évalué à 2.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . Évalué à 2.
C'est très joli, mais les IDE modernes font déjà 99% de ce travail. Quand je veux faire un nouvel objet, je tape juste son nom, la liste de ses propriétés et la complétion fait le reste. Il y a aussi la notion de template et d'assistant pour les morceaux plus complexes.
Sauf que tu raisonnes toujours par rapport à tes propres besoins de développeurs dans ton coin alors qu'on t'a expliqué en long et en large que l'application ne se limitait pas à ca. Le moindre changement dans ta conception peut impacter plusieurs projets avec moultes refactoring sur des technos et des équipes différentes. L'approche top down te permet justement de rester cohérent.
D'où ma question sans réponse pour l'instant (enfin, j'ai pas fini de lire le thread) : est-ce que quelqu'un a déjà vu un gros projet utiliser ce type d'outil ? Est-ce que ça a survécu avec le temps ?
Oui j'en ai vu un mais ca t'apportera quoi puisque tu trouveras à redire que ca rame parce c'est du JEE et que de toute façon t'aurais mieux à toi tout seul.
Fais toi plaisir.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Dring . Évalué à 2.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Cédric Brun (site web personnel) . Évalué à 2.
D'ailleurs quand on passe un peu dans les entreprise c'est plutôt rare quand une SSII ou un grand compte n'utilise pas déjà ces approches (a plus ou moins grande échelle), en tout cas je n'en ai pas croisé.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Ontologia (site web personnel) . Évalué à 3.
En plus t'es obligé de tout jeter quand tu as commencé à coder dans tes classes, ce qui peut souvent arriver dans une approche incrémentale (qui se développe).
Je ne parle même des heures passées à rajouter le fait que dans la fonction toto dans la classe machin, il y a deux paramètre string.
Mais bon ça c'est Rational. Acceleo pas testé, peut être que c'est bien fait.
Même dans un approche cycle en V c'est la merde à cause de la non bidirectionalité : c'est rare qu'on ait pas besoin de corrigé un truc après coup. Et là horreur : on doit gérer du code généré à la main, ya plein d'incohérence qui pètent de partout. Merde le framework a un bug, mais on le savait pas, fo prendre la version suivante (ou précédente), et là faut tout refaire.
Ah mais attend si tu veux regénérer, t'écrases le code déjà ecris.
Bref, c'est beau sur le papier...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . Évalué à 2.
Si tu te lances dans du refactoring à tout va et que tu retouches le code généré en dehors des sentiers battus (balise preserved), ton modèle et ton code divergent et la moindre régénération de code suite à une évolution de ton architecture ou des specs va te lancer dans un interminable merge de ton code. Au fil du temps modèle et code sont de plus en plus éloignés et les réconciliations deviennent contre-productives.
Partant de ce constat:
Soit tu n'envisages le modèle uniquement que pour faire du one shot et tu peux effectivement douter de l'utilité des modèles (ecole du sketch modeling, on modélise sur un tableau pour des besoins ponctuels)
Soit tu essaies de ne pas trop faire diverger ton modèle et ton code
Soit tu te donnes les moyens de réconcilier les divergences.
Si tu adoptes une approche descendante. Tu te dois de respecter les zones de code non éditables et tout ce qui peut être ecrasé par le générateur.
L'aspect incrémental peut-être est assuré par l'outil de transfo (identifiants dans le code généré+balise preserve) ou par l'outil de gestion de version qui sait gérer le merge mieux que personne puisque c'est son rôle. Il est vrai que ca peut être un peu contraignant comme tu l'évoques mais une chaîne de travail bien pensée peut apporter un gain. Il faut aussi savoir se limiter sur ce qu'on veut générer.
Si on choisit de générer certaines parties du code c'est qu'on pense qu'il y un gain en terme de cohérence au niveau de ton archi. Le but n'est pas seulement de cracher un maximum de code automatiquement.
C'est toute la difficulté de l'exercice. Ne pas en faire trop.
Si malgré tout, tu veux te laisser la liberté de diverger au niveau du code en cassant les associations, en refactorant les classes ou les packages, en modifiant tes contrats de WSDL à la mano, ... tu as besoin de mettre en place une transformation inverse c'est à dire du code vers le modèle. Le problème est: que se passe t'il si ton modèle a aussi évolué entretemps. Tu te retrouves avec 2 versions de modèles à réconcilier, l'une modifiée à la main, l'autre obtenue par rétro-ingénierie.
Sans un bon outil qui te permet (cf. EMF Compare pour te faire une idée) de faire des merges de modèles et qui t'évite de te répeter tu es dans l'impasse (merge tracking)
Là où c'est assez drôle c'est que la suite que tu critiques (RSM + Clearcase je suppose) est à ma connaissance la seule qui prenne en charge ca à peu près correctement mais je l'opensource avance de son coté (cf Expand, Acceleo, EMF Compare, ...).
Tout ceci nous ramène une problématique classique de versionning.
Il faut y aller petit pas par petit pas pour ne pas faire de merge big-bang.
El là où ca devient intéressant c'est qu'on peut créer des modèles adaptés et compréhensibles par ceux à qui on s'adresse (modèle de processus métiers pour les Business Analyst, modèles d'analyse, modèles de conception, maquettes d'IHM, ...) tout ça grâce aux DSLs (Domain Specific Language) y compris textuels (cf. Xtext) ou à l'UML profilé. Si on dispose de transformations Modèle vers Modèle et d'un bon outillage ceci n'est pas hors d'atteinte et l'aspect incrémental consolide la chaîne.
Après je suis d'accord que ca peut devenir complexe, mais la réalité de ces projets est complexe et les gains se font sur l'échelle.
Je sais que je ne te convaincrai pas mais j'ai la faiblesse de croire que ca marche pas trop mal pour certains projets que j'ai pu croiser.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Ontologia (site web personnel) . Évalué à 2.
La coque de la fonction, bref ce qu'il a généré, ne doit pas être touchée, on est d'accord, même si ça pourrait être plus pratique dans certains cas, surtout avec Eclipse qui te gère le refactoring automatique, alors que ton outil (je connais RSM + ClearCase) ne le fait pas, ce qui fait que tu dois le faire à de multiple endroits, moins nombreux certes, mais néanmoins multiples.
Donc partant de cela, et si c'est géré automatiquement, ça devient intéressant... dans certains projets, bien bateaux, et bien cadrés.
En gros les projets neufs, ce qui est assez rare dans une SSII.
Pour RSM et ClearCase, je t'assure que j'ai jamais vu cette fonction de gestion de modification de source, mais on avait peut être une version trop vieille, je ne sais pas.
M'est avis, que vous allez avoir du mal à imposer ça dans l'industrie, ie. à l'average programmer, parce qu'il va falloir imposer ça au développeur, et quand on voit comment certains sont pédants (voire plus haut), c'est mal parti.
Java, n'est ni plus ni moins qu'une application de concept de Simula (1967), soit un décalage de 35 ans entre le labo et sa généralisation dans l'industrie.
Mais un conseil, veillez vraiment à la bijectivité, je pense que c'est un gros frain à l'adoption. Et travailler vos interfaces de dev, parce que 20 clics (et j'exagère au pire d'un facteur 1,2) pour dire que ma fonction toto a un param machin de type string -----> Poubelle.
J'ai pas envie d'avoir une tendinite au poignet..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . Évalué à 2.
Alors si ça me gère les points d'insertion du code, en sachant qu'entre tel endroit tel endroit il doit pas y toucher, très bien. Le problème peut venir de l'incapacité de l'outil de comprendre que telle zone de code ne fait pas partie de ce qu'il a généré, typiquement le coeur d'une fonction.
Acceleo fonctionne, comme ca. Nous on utilise OAW Xtend avec le même principe de balises protected
La coque de la fonction, bref ce qu'il a généré, ne doit pas être touchée, on est d'accord, même si ça pourrait être plus pratique dans certains cas, surtout avec Eclipse qui te gère le refactoring automatique, alors que ton outil (je connais RSM + ClearCase) ne le fait pas, ce qui fait que tu dois le faire à de multiple endroits, moins nombreux certes, mais néanmoins multiples.
On est d'accord: un appel à 'une méthode qui a été renommée dans le modèle puis régénérée, ne ne sera pas mis à jour dans le corps de la méthode appelante alors que le refactoring s'en sortira mieux. Mais bon y'a pas mort d'homme. Pense que ton modèle une fois mis à jour te permettra aussi de mettre à jour d'autres briques qui ne seront pas couvertes par ton IDE. Par contre je ne vois pas le rapport avec RSM ou Clearcase là. tu compares un IDE avec un modeleur et un VCS
Pour RSM et ClearCase, je t'assure que j'ai jamais vu cette fonction de gestion de modification de source, mais on avait peut être une version trop vieille, je ne sais pas
Même question. Je comprend pas ce que tu veux dire. J'ai pas du être clair.
Mais un conseil, veillez vraiment à la bijectivité, je pense que c'est un gros frain à l'adoption.
Le problème est que la bijectivité parfaite n'existe pas.
Imagine un modèle avec une classe qui comporte des attibuts private et public.
Pour diverses raisons, tu as décidé que ton générateur de code transforme tous les attributs en public dans le code généré de la classe.
Si tu fais un reverse, tu n'as pas moyen de revenir au modèle initial en remettant les bon attributs.
Tu régenères donc une version de modèle qui a tous ses attributs à public et tu t'en remets au modeleur et à ses capacités à merger les modèles pour reconstituer le modèle que tu attends. La transfo inverse ne peut pas être automatique.
Pour une classe ca va, mais pour un projet complet.
C'est pourquoi, on privilégie une approche top down car le roundtrip est beaucoup trop complexe voire inapplicable.
L'autre solution consiste à conserver la tracabilité de la génération (modèle de marquages). La transfo modèle vers code (vu comme un modèle) mémorise chaque relation entre elt du modèle souce et du modèle cible.
Ca marche pas mal avec les modèles parce que tous les elts ont des identifiants immuables.
Avec du code source cet identifiant est dans les commentaires.
Ca reste ardu car il y a plein de cas tordu (cas des surjections: 1elt donne n elt dont 1 seul a changé dans le code , ...)
Et travailler vos interfaces de dev, parce que 20 clics (et j'exagère au pire d'un facteur 1,2) pour dire que ma fonction toto a un param machin de type string -----> Poubelle.
Là tu t'en prends plus au modeleur mais d'une manière générale, il faut éviter de bosser sur les diagrammes et attaquer directement la structure du modèle, voire utiliser un DSL texte (qui n'est rien d'autre qu'un langage)
Avec RSM le truc chiant c'est que pour créer le moindre lien entre 2 concepts il faut un diagramme. C'est perfectible.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par Ontologia (site web personnel) . Évalué à 2.
Imagine un modèle avec une classe qui comporte des attibuts private et public.
Pour diverses raisons, tu as décidé que ton générateur de code transforme tous les attributs en public dans le code généré de la classe.
Si tu fais un reverse, tu n'as pas moyen de revenir au modèle initial en remettant les bon attributs.
Tu régenères donc une version de modèle qui a tous ses attributs à public et tu t'en remets au modeleur et à ses capacités à merger les modèles pour reconstituer le modèle que tu attends. La transfo inverse ne peut pas être automatique.
Pour une classe ca va, mais pour un projet complet.
C'est pourquoi, on privilégie une approche top down car le roundtrip est beaucoup trop complexe voire inapplicable.
L'autre solution consiste à conserver la tracabilité de la génération (modèle de marquages). La transfo modèle vers code (vu comme un modèle) mémorise chaque relation entre elt du modèle souce et du modèle cible.
Ca marche pas mal avec les modèles parce que tous les elts ont des identifiants immuables.
Avec du code source cet identifiant est dans les commentaires.
Ca reste ardu car il y a plein de cas tordu (cas des surjections: 1elt donne n elt dont 1 seul a changé dans le code , ...)
Je veux bien croire qu'on veuille contraindre son modèle, mais j'ai du mal à comprendre la pertinence de ta limite : si une classe comporte des attributs publics, qu'ils soient rendus comme tel dans le modèle, de même pour les privés, protected.
Bref la bijectivité suppose que le modèle rende compte du code pour ce qu'il sais représenter : essentiellement les prototypes de fonction et la config.
Si ça contrevient à une règle posé, genre celle que tu cite en exemple, eh bien pond un warning, mais va pas dire que c'est pas bijectif :-)
Pour RSM et ClearCase, je t'assure que j'ai jamais vu cette fonction de gestion de modification de source, mais on avait peut être une version trop vieille, je ne sais pas
Même question. Je comprend pas ce que tu veux dire. J'ai pas du être clair.
Tu me disais ds le précédent post que ces outils géraient une sorte de bijectivité, je te répondais que ds la pratique que j'en ai eu, non.
Clearcase n'a effectivement rien à voir, c'est un VCS comme tu le disais, mais tu les citaient plus haut.
C'est avec RSM que je devait faire mes boiboites (j'en ai envie de vomir rien que d'y penser, brrrrrr), et c'est une des interfaces les plus mal pensée et imbitable que j'ai jamais vu.
Tout ça décidé d'en haut par des abrutis qui n'ont jamais eu à y toucher. Voilà les dégats d'ingénieurs au poste de managment qui lisent des plaquettes de pub, et qui croient connaitre parce qu'ils ont codé 10 lignes de java ya 10 ans.
Bref, au minimum, il faut garantir la bijectivité, l'outil dusse t-il sortir une palanqué de warning pour dire qu'il ne sait pas reverser tel chose, ou que ça viole telle ou telle contrainte.
Mais croire qu'on va attirer le développeurs en lui imposant un outil où il doit se débrouiller avec du code généré à partir d'un moment x du projet, j'ai peur que ça marche mal, la pénétration dans le secteur..
PS : Votre techno a 15 ans, il va falloir 15 autres années pour que ça parvienne au cerveau des industriels, on pari ? ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . Évalué à 5.
Je veux bien croire qu'on veuille contraindre son modèle, mais j'ai du mal à comprendre la pertinence de ta limite : si une classe comporte des attributs publics, qu'ils soient rendus comme tel dans le modèle, de même pour les privés, protected.
Bref la bijectivité suppose que le modèle rende compte du code pour ce qu'il sais représenter : essentiellement les prototypes de fonction et la config.
Si ça contrevient à une règle posé, genre celle que tu cite en exemple, eh bien pond un warning, mais va pas dire que c'est pas bijectif :-)
C'est pourtant, ce que j'essaie d'expliquer. Tu raisonnes en te disant que ton modèle est ton code. Or ca n'a aucun intérêt à part faire chier les développeurs. L'intérêt est de "transformer" d'effectuer automatiquement des modifications simples pour éviter que le dev ne se les coltine. L'entrée et le résultat ne sont pas sémantiquement équivalents ni même bijectifs. Les warnings c'est super mais ca ne suffit pas. Il faut résoudre les conflits... à la mano.
C'est le couple RSM+Clearcase qui s'en charge.
Donc la bidirectionnalité est possible mais pas "automatique". C'est ce j'entends par bijectif. Elle est juste chiante.
C'est avec RSM que je devait faire mes boiboites (j'en ai envie de vomir rien que d'y penser, brrrrrr), et c'est une des interfaces les plus mal pensée et imbitable que j'ai jamais vu.
Avec les premières versions qui sont sorties juste après la spec UML 2.0, je ne te donne pas tort. Ca s'est pas mal amélioré depuis avec la 7.5 mais il traîne encore les hérésies ergonomiques du socle Eclipse.
Malheureusement, Topcased et Papyrus sont encore plus à la ramasse et je ne te parle même pas d'ArgoUML.
Tout ça décidé d'en haut par des abrutis qui n'ont jamais eu à y toucher. Voilà les dégats d'ingénieurs au poste de managment qui lisent des plaquettes de pub, et qui croient connaitre parce qu'ils ont codé 10 lignes de java ya 10 ans.
Fais toi plaisir. Chez nous, on fait du support sur les solutions qu'on propose donc les merdes c'est nous qui devons les gérer.
PS : Votre techno a 15 ans, il va falloir 15 autres années pour que ça parvienne au cerveau des industriels, on pari ? ;-)
A l'heure où on redéveloppe une appli par site web pour le consulter sur son mobile, où on encapsule tous les protocoles IP dans un protocole en mode non connecté, ou on revient aux clients lourds qu'on renomme riches pour faire passer la pilule, où réinvente le bon vieux RPC en le rebaptisant SOA, ... j'ai perdu mes illusions sur une informatique qui ferait gagner du temps à ses clients ;)
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . Évalué à 1.
# Voilà une bonne nouvelle: plus besoin de programmeurs
Posté par Kerro . Évalué à 4.
Et la marmotte, elle emballe le chocolat avec du papier alu.
[^] # Re: Voilà une bonne nouvelle: plus besoin de programmeurs
Posté par Sébastien Mosser . Évalué à 8.
Mais quand on travaille dans la vraie vie, on se rend compte rapidement:
a) que les gens qui prennent des décisions ne comprenne foutrement rien à du code. Ils VEULENT des "boiboites" pour monter en abstraction et comprendre ce qui se passe dans la technique. Donc vu qu'on est obligé de les avoir les boiboites, autant les opérationaliser
b) qu'il y à une énorme différence entre maitrise d'œuvre et maitrise d'ouvrage. Écrire du code, c'est un métier. Écrire du joli code, c'est presque un autre métier. Mais cela "reste" de la maitrise d'œuvre. Et il devient très difficile ne ne pas tenir compte du phénomène d'outsourcing. Graham disait (je paraphrase affreusement, mais je ne retrouve plus mon bookmark avec la source) "apprenez Java, et vous serez comme les 20.000 indiens qui candidate chez moi. Apprenez Lisp en plus de Java, pensez différemment, et je vous engagerais". C'est un peu le même principe. Il y à une forte tendance dans le marché actuel pour de la maitrise d'ouvrage (gestion de projet, gestion d'équipes, conduite de projet, gouvernance technique ...). Pour la maitrise d'œuvre, très peu de grands comptes embauchent encore en interne. La plupart externalise (que ce soit via des consultants ou de l'out-sourcing).
c) Avez vous simplement entendu parler de ligne de produit ou d'usines logicielle? Tant qu'on se contente de se construire des outils "dans son coin", où qu'on utilise comme gouvernant des personnes aux compétences techniques, la maitrise du code est suffisante. Mais pour les autres cas (qui sont beaucoup plus nombreux que vous semblez le croire), vous ne pouvez pas vous permettre de "bricoler", car vous devez :
- démontrer a la direction que ce machin va se vendre
- démontrer au marketing qu'on pourra l'adapter facilement au client
- démontrer à vos différents sous-projet l'avancée globale du produit.
Bref ... on parle ici d'"ingénierie du logiciel", pas de développement. Pensez à une compagnie qui vend un back-end de réservation de voyage. au niveau modèle, quel que soit l'agence de voyage qui vous achète le système, c'est "presque" pareil. Toute la valeur ajoutée est dans l'adaptation de votre système a votre client, tant au niveau front-end (site web, ...) que dans le back-end (compagnies partenaires, accord hôtels / loueurs de voiture pour construire des 'packs', ...).
Alors autant on apprécie l'expérience d'experts en développement (qui sont d'ailleurs utilisé pour écrire les transformations), autant votre réaction tombe juste "a coté": Ce n'est pas le même métier. alors si on vous laisse faire le votre, laissez nous faire le notre.
[^] # Re: Voilà une bonne nouvelle: plus besoin de programmeurs
Posté par Dring . Évalué à 7.
Sauf que j'ai jamais vu un non-informaticien capable d'appréhender un schéma UML, même un pov' diagramme "Use Case".
Au final, toutes ces mécaniques ne font que rajouter une couche de travail supposée permettre de mieux se faire comprendre, mais sans y parvenir réellement. En tout cas, c'est ce que j'ai constaté jusqu'ici, et je ne demande que des exemples pour me convaincre du contraire.
Mais quand on travaille dans la vraie vie, on se rend compte rapidement: [...]
Dingue ça. Dire que j'étais persuadé d'être dans la vraie vie, et m'être rendu compte du contraire. Je dois être tombé dans une faille interdimensionnelle sans faire gaffe.
[^] # Re: Voilà une bonne nouvelle: plus besoin de programmeurs
Posté par Cédric Brun (site web personnel) . Évalué à 1.
Une petite présentation assez intéressante sur les légendes autour de modeling :
The Unbearable Stupidity of Modeling : http://www.slideshare.net/merks/the-unbearable-stupidity-of-(...)
[^] # Re: Voilà une bonne nouvelle: plus besoin de programmeurs
Posté par Antoine . Évalué à 5.
J'imagine qu'à force de prendre le client pour un neuneu attardé, on finit par se faire une spécialité des clients infantiles qui veulent de jolis schémas comme un enfant aime les jouets multicolores.
Et il devient très difficile ne ne pas tenir compte du phénomène d'outsourcing
Ok, là ça devient intéressant. Tu veux dire qu'après avoir fait ton petit pâté de boîboîtes face au client tout frétillant, tu refiles le sale boulot (le vrai boulot, en fait) à une autre entreprise ?
C'est mignon tout plein de nous faire croire que c'est ton boulot qui crée la valeur ajoutée.
Bref ... on parle ici d'"ingénierie du logiciel", pas de développement
Ah ouais, je vois, on est pas au même niveau. Les torchons et les serviettes. Et dire que ça n'a même pas l'air d'être ironique.
(en français on dit génie logiciel, ça t'évitera les guillemets autour d'une expression effectivement affreuse)
C'est hallucinant de citer Paul Graham, parce que lui, son logiciel de commerce en ligne (ViaWeb), en plus d'en être le concepteur, il l'a écrit en Lisp de A à Z, il n'a pas dessiné des « boîboîtes » pour ensuite refiler le bébé à une bande de pisseurs de code considérés comme du bétail. Et le genre de gadget graphique dont tu nous fais la retape est aux antipodes de son discours. Lui croit à la technicité du métier de programmeur, et à l'importance du talent.
[^] # Re: Voilà une bonne nouvelle: plus besoin de programmeurs
Posté par El Titi . Évalué à 2.
Et il devient très difficile ne ne pas tenir compte du phénomène d'outsourcing
Ok, là ça devient intéressant. Tu veux dire qu'après avoir fait ton petit pâté de boîboîtes face au client tout frétillant, tu refiles le sale boulot (le vrai boulot, en fait) à une autre entreprise ?
C'est mignon tout plein de nous faire croire que c'est ton boulot qui crée la valeur ajoutée.
Sauf que l'idée est aux antipodes de ce que tu décris. Il s'agit de te rendre plus productif toi qui connait bien le métier, en t'évitant les tâches répétitives et donc de rendre moins intéressant la sous-traitance vers les pisseurs de code. Un peu comme dans l'industrie avec les robots vs les délocalisations.
Dans les faits c'est pas gagné mais au moins on essaye.
[^] # Re: Voilà une bonne nouvelle: plus besoin de programmeurs
Posté par Sébastien Mosser . Évalué à 4.
Pour vous donner un exemple, j'ai récemment monté un cours en M2 Bio-Informatique. Avoir des étudiants biologiste impose un gros décalage de vocabulaire ("système" en bio, c'est "cellule de foie porcine cancéreuse" par exemple). Le fait d'utiliser des modèles pour communiquer et UML comme langage intermédiaire nous a permis de mener à bien un projet de semestre assez costaud.
Être capable de communiquer avec d'autres personne que des informaticiens, c'est vital!! Après, UML à pleins de défaut, et lorsque le besoin s'en fait ressentir, on peut créer un langage spécifique a un domaine donné, pour régler le problème et être encore plus efficace.
Pour ta remarque sur "les torchons et les serviettes", ce n'est pas mon point de vue. On parle de deux métiers différents, au même niveau d'expertise. Mais pas du même métier. Prends la construction d'un pont, le viaduc de Millau par exemple. Il y à une différence très net entre les spécialistes "structures" qui s'occupent de garantir que le pont ne va pas s'écrouler des spécialistes "flux" qui regardent les flux de circulations alentours et planifient l'utilisation et le nombre de contraintes que va devoir supporter le pont. 2 expertises très différentes, exprimées dans des langages très différents (calculs de structures pour les uns, flots dans l'autre cas). Mais au final, on parle bien du même viaduc, qu'il faut vendre au conseil régional pour obtenir de nouvelles subventions. Comment faire sas une vision synthétique, de plus haut niveau, coordonant tous ces dev.? Est-ce plus clair avec cette métaphore? L'idée est que la réalité est constitué par de nombreux corps de métiers ou d'expertise, et qui'l faut bien arriver a faire en sorte que tout le monde se parle. et surtout se comprenne.
Et, pour finir, je citais Graham dans le sens où la plus-value d'un expert n'est pas dans l'ecriture d'un code "basique", mais dans les trucs tricky qui nécessitent justement son expertise. Encore une fois, pas le même métier. On a besoin de gens experimentés dans leur domaine pour écrire les générateurs de code par exemple. si jamais je devais définir une transformation vers une VM Lisp, je ferais surement appel à un expert pour obtenir une projection ayant du sens, et optimisée selon son experience.
C'est toujours le même décalage: on ne fait pas le même métier. Mais normalement, rien de grave là dedans. enfin à mon sens.
[^] # Re: Voilà une bonne nouvelle: plus besoin de programmeurs
Posté par Antoine . Évalué à 3.
Pour cela, il y a un truc génial : le langage naturel. Le français, en clair (ou bien l'anglais si tu adores le mot « engineering »). Bien plus riche et nuancé que n'importe quel agencement de boîboîtes sur feuille A4.
L'humanité n'a pas attendu l'invention de formalismes infantiles par des spécialistes du « consulting » pour se lancer dans des entreprises collectives ambitieuses. Les cathédrales en sont un exemple.
Et si le viaduc de Millau existe, c'est parce qu'un certain état de l'art technique et scientifique l'a permis. Pas parce qu'un consultant a réussi à « vendre le projet » avec son Powerpoint plein de zigouigouis.
(d'ailleurs, le viaduc de Millau décrit en UML, ça doit être cocasse)
[^] # Re: Voilà une bonne nouvelle: plus besoin de programmeurs
Posté par ylussaud . Évalué à 2.
Le probleme du langage naturel c'est qu'il est ambigu. L'avantage de definir un DSL c'est justement d'avoir une base technique concrete deriere. Si tu utilises tel ou tel concepts c'est qu'il est definit et donc que tout le monde sait de quoi tu parles sans ambiguite. Apres libre a chacun d'en faire une utilisation special. Par exemple si tu decrit qu'un service sera accessible en TCP sur tel port et tel ip les actions aprendre sont de plusieurs ordre suivant ton interlocuteur :
- le fournisseur du service va ecouter sur ce port
- le client va se connecter sur ce port
- l'admin system va ouvrir le port dans un firewall par exemple
N'empeche que tout le monde va partager le meme modele pour avoir l'info. Et surtout le meme langage pour lever au maximum l'ambiguite. J'aime bien l'exemple de la micro bio dans un autre commentaire aussi. D'autre part c'est pas par ce qu'ont utilise un formalisme technique qu'il ne faut pas se parler. L'un ne remplace pas l'autre. C'est un outil parmi d'autres.
Les hommes n'ont pas attendu l'invention du briquet pour allumer un feu. Pourtant c'est plus pratique d'utiliser un briquet.
Pour ce qui est de la vente d'un projet ca fait partie de la vie du projet. Je pense pas qu'on lance la construction d'un viaduc si personne n'est pret a financer sa construction. Pour ce qui est du formalisme a apporter pour le construire je suis contant de voir que tu ne choisirais pas UML. Fait gaffe t'es en train de devenir un pro du MDA :)
cordialement,
Yvan.
[^] # Re: Voilà une bonne nouvelle: plus besoin de programmeurs
Posté par El Titi . Évalué à 5.
Très bon exemple.
[^] # Re: Voilà une bonne nouvelle: plus besoin de programmeurs
Posté par ckyl . Évalué à 1.
Mais quand on travaille dans la vraie vie, on se rend compte rapidement:
Penses à faire ce genre de commentaires sous un autre nom la prochaine fois.
Non par ce que pour un thésard de l'I3S chez rainbow qui n'a jamais mis les pieds en dehors d'une université et d'un polytech au niveau totalement extraordinaire ça fait doucement rigoler.
[^] # Re: Voilà une bonne nouvelle: plus besoin de programmeurs
Posté par Sébastien Mosser . Évalué à 2.
Regarde mon travail et les activités de mon équipe, les projets auquel nous participons sont toujours relié a des problématiques industrielles, relayé par nos partenaires de projet. C'est d'ailleurs pour cela qu'on utilise des modèles, pour arriver a se comprendre entre participants.
Quand a Polytech, tu trouve peut-être notre niveau "tout a fait extraordinaire", mais personellement, j'ai encadré des stages et des projets de fin d'étude de niveau tout a fait valable, et dont les participants sont aujourd'hui embauché en CDI, et content de leur boulot.
La vie est une question de priorité.
# Excel
Posté par tyoup . Évalué à 1.
# Quelques informations
Posté par ylussaud . Évalué à 3.
Je vais essayer d'apporter mon point de vue sur le MDA et la generation de code. Ce n'est surement pas une verite absolue ni meme complete mais j'espere que ca aidera a y voir plus clair.
Deja la modelisation c'est pas forcement UML. Avec UML l'OMG a voulu apporte une solution generaliste pour modeliser le maximum de choses. L'autre approche est ce qu'on appelle les DSL (domain specific languages). L'idee dans le cas des DSL est de faire son propre langage qui manipule les concepts de son metier. On peut prendre l'exemple de l'application du langage Logos pour piloter la tortue (http://en.wikipedia.org/wiki/Logo_%28programming_language%29(...) C'est plus facile de manipuler directement un langage avec des actions comprises par l'utilisateur (un enfant dans cet exemple).
La premiere etape est donc de savoir si l'on veut aller vers tel ou tel type de modelisation.
La deuxieme etape est de savoir quoi modeliser. Pour certaines utilisation il faut avoir un grain tres fin pour d'autres ce n'est pas necessaire. Il faut donc savoir ce que l'on veut faire avec ses modeles. Un modele de retro ingenierie est beaucoup plus complexe qu'un modele de generation de squelettes d'application par exemple.
Dans le cas de la generation il faut aussi placer un curseur pour dire cette partie la on la modelise pour la generer et cella pas. Par exemple pour le cas d'un moteur de rendu 3D c'est illusoire de modeliser chaque instruction d'un algo de rendu. Par contre il est possible de definir l'architecture du moteur de rendu et de generer 10% ou 20% de l'application (par exemple). Pour une application plus traditionnelle de gestion il est possible de modeliser et donc de generer beacoup plus de chose.
Dans ces choses on va retrouver des regles metier et c'est la que le DSL est a mon sens plus interessant. Avec le bon DSL il est possible de laisser l'expert du metier manipuler son metier tout en assurant une base technique qui permet d'utiliser directement dans le systeme d'information (par exemple l'enfant et le robot tortue).
Une autre etape est de savoir comment presenter ces concepte a l'expert du metier. C'est ce qu'on appelle la syntaxe concrete par oposition a la description des concepts qui represente la syntaxe abstraite. Dans les syntaxes concretes on retrouve deux grandes familles les syntaxes textuelles et les syntaxes graphiques. Il faut donc choisir celle qui est la mieux addapter. Par exemple utiliser une syntaxe textuelle pour decrire des IHM c'est peut etre pas tres intuitif.
Pour en revenir a la generation il y a un point important a considerer c'est de savoir si l'on veut travailler en iteration ou en one shot. C'est a dire faire des aller retour entre la phase de modelisation et de generation/modification du code ou pas. Pour ce qui est de l'exemple du moteur 3D l'approche la plus plausible est le one shot. On lance une generation une fois que l'architecture est figee et on oublie les generateurs par la suite quand on implemente les algo de rendu. Mais le travail se fait le plus souvent par iteration modelisation / generation / ajout de code manuel / modification de la modelisation / regeneration / ...
On voit que le soit apporte aux generateurs ne sera probablement pas le meme dans les deux cas. Mais l'avantage de la generaration sur ce point c'est que les modifications du code sont centralisees. Une correction de bug dans un template de generation va s'appliquer plusieurs fois dans le code generer. De meme l'argument facile du genre "le code est moche" ne tient pas. Si le code est moche il faut changer le generateur pour le rendre beau. Une fois fait tout les utilisateurs du generateur profitent de l'amelioration.
Bref y a surement plein d'autres choses a dire mais si ce qu'il y a au dessus vous parle un minimum il faut continuer sur google. Et je dirais aussi que si une solution est trop belle pour etre vrai c'est qu'elle doit etre fausse... Si on modelise n'importe comment ou n'importe quoi on arrive sur le meme probleme que le code ecrit n'importe comment qui fait n'importe quoi. Faut juste etre un peu realiste :)
Et pour finir quelques projets qui utilisent la generation de code:
EMF (Eclipse Modeling Framwork) : il utilise JET (Java Emitter Templates) pour generer sont code a partir de sa propre specification (a quelques details technique pret).
EEF (Extended Editing Framework) qui permet de faire des vue propriete plus sexy pour les editeurs Eclipse. Il repose sur le projet Eclipse Acceleo. Ceci dit il est en incubation mais vu l'age du projet et ce qu'il permet deja de faire je pense que c'est juste impossible de faire la meme chose a la main...
Acceleo utilise JET aussi pour des questions de bootstrap.
La plus part des projets qui dependent d'EMF utilisent les generateurs JET d'EMF
Microsoft a aussi une plateforme de modelisation DSLTools... Je connais moins les projets qui gravitent autour.
J'ai aussi une liste de projet prives pour des SSII et autres integrateurs. Je pense qu'une recherche google devrait vous donner des resultats (Acceleo + <nom d'une SSII>). Elles utilisent surement d'autres generateurs d'ailleurs.
Pour les exemple d'utilisation du MDA il est possible de citer la migration et la modernisation d'application. Et tout ce qu'il est possible de faire avec un DSL. L'executer par exemple...
cordialement,
Yvan.
# Rien du tout ....
Posté par kadreg (site web personnel) . Évalué à 1.
[^] # Re: Rien du tout ....
Posté par Cédric Brun (site web personnel) . Évalué à 1.
# Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.