moi pas comprendre

• [^]Re: moi pas comprendre

  Posté par Jonathan ILIAS (Jabber id, page perso, ) le 11/09/2006 à 14:30. (lien). Évalué à 4.

  chut, c'est pour les décideurs pressés qui passent par ici... ;-)

  • [^]générateur de code source?

    Posté par salvaire () le 11/09/2006 à 14:39. (lien). Évalué à 2.

    On va enfin pouvoir reprogrammer tous les logiciels qui font défaut sous Linux en trois cliques de souris à partir des screenshots windows?
    
    J'ai bon?

• [^]Re: moi pas comprendre

  Posté par account () le 11/09/2006 à 14:36. (lien). Évalué à 1.

  faut plutôt demander des exemples concrets.

• [^]Re: moi pas comprendre

  Posté par Etienne Juliot (page perso, ) le 11/09/2006 à 14:39. (lien). Évalué à 4.

  Un vrai projet industriel, c'est un projet autre que le "helloworld" classique.
  En gros, c'est un projet qui dure plusieurs mois / années, avec plusieurs développeurs en parallèle.
  
  C'est souvent le problème de la génération de code qui marche bien au début, mais qui, une fois une grosse équipe mis au quotidien dessus, peut poser des problèmes.
  Avec Acceleo, on est parti de ces problèmes et on a tenté de les résoudre en y réfléchissant dès le début de son développement. Ca donne par exemple la génération incrémentale (génération, regénération, reregénération), l'intégration dans Eclipse, les chains, ...

  • [^]Re: moi pas comprendre

    Posté par salvaire () le 11/09/2006 à 14:53. (lien). Évalué à 4.

    Un vrai projet industriel

    Cela dit tous les livres que j'ai lu sur le sujet était très typiques (académique) et sur des thèmes bien maîtrisés: DAB, commerce, gestion de stock ... Qu'est ce qui prouve que ces méthodes sont applicables en générale, sur un projet jamais exploré ou mal maîtrisé? Je voudrai voir des comptes rendus d'utilisation sur de vrai projet industriel divers et variés.

    • [^]Re: moi pas comprendre

      Posté par Thomas Douillard () le 11/09/2006 à 19:24. (lien). Évalué à 3.

      A première vue : le thème est moins bien maîtrisé que dans les exemples académiques, donc il y a peut être besoin de souplesse pour faire des changements en cas de modélisation foireuse (les cours de GL que j'ai suivi insistaient tous sur une bonne modélisation à la base sous peine de devoir jeter du code, voire de tout redémarrer, en cas de mauvaise direction). Peut être que ce genre d'outil apporte un peu plus de souplesse en cas de foirage? Le risque que j'y vois : on met moins de soin à la modélisation et à la définition des besoins et on se plante quand même ...
      
      note sur les sujets de tes cours de GL : ca doit recouvrir une partie non négligeable des développements en entreprise, donc si les méthodes marchent pour ça, c'est déja pas mal ;)

      • [^]Re: moi pas comprendre

        Posté par Etienne Juliot (page perso, ) le 12/09/2006 à 07:23. (lien). Évalué à 4.

        En effet, les cours font souvent l'impasse sur la partie évolution.
        Entre le début d'un projet et sa fin, la facon de modéliser et surtout l'architecture technique changent.
        Les changements sont souvent dû à des imprécisions, des lourdeurs (le syndrômes des "fameux" modèles trop techniques qui ne servent quasiment à rien), des changements de versions de frameworks, ou à des retours des tests de performances / qualité.
        
        Acceleo permet justement plus de souplesse pour prendre en compte ces changements et pour ré-impacter ce qui a déjà été fait. Notamment, la possibilité de modifier facilement la manière de modifier ce qu'il génère rend la mise à jour des générateurs relativement simple.
        
        Pour revenir aux cours, c'est notamment pendant des conférences d'externes que tu peux avoir ce genre de retours. Normal, les profs maîtrise le côté théorique, mais ils n'ont pas forcément le retour d'expérience d'une utilisation sur le terrain.

Utilisation d'Acceleo pour les logiciels open-source

Un projet d'avenir...

• [^]Re: Un projet d'avenir...

  Posté par Alexandre Garel () le 12/09/2006 à 06:46. (lien). Évalué à 2.

  Une question qui va paraitre idiote. Je n'ai regardé que très rapidement la présentation (donc je ne veux pas être insultant). Mais peut on voir ça en gros comme l'association d'un moteur de template et d'un modélisateur UML ?

  • [^]Re: Un projet d'avenir...

    Posté par Bertrand Florat (page perso, ) le 12/09/2006 à 08:14. (lien). Évalué à 4.

    Acceleo n'integre pas de modeleur UML mais fournit uniquement un moteur de generation de code orienté template (et des fonctionnalités de transfo de modeles FYI) mais très bien intégré, simple et puissant (bien plus que EMF.Codegen JET, Acceleo peut se comparer en couverture fonctionelle à l'outil proprio MIA.Generation de sodifrance). Comme modeleur UML OSS, il est possible d'utiliser en complément Topcased (Airbus, voir topcased.org) qui peut serializer les modeles en XMI. Ensuite on donne à manger à acceleo ce XMI + le XMI du meta-modèle (celui d'UML2 si tu n'utilise pas de meta-modèle perso) + le template Acceleo pour recuperer le code (ou tout autre artéfact comme un fichier XML).

    • [^]Re: Un projet d'avenir...

      Posté par Wajsberg Julien () le 12/09/2006 à 12:28. (lien). Évalué à 2.

      Par rapport à du OpenMDX, ça se compare comment ?
      
      OpenMDX permet aussi de générer du code à partir de fichiers XMI issus de divers logiciels (rational, poseidon, etc), mais je crois qu'il va plus loin : binding SQL, interface web graphique générique, etc.

      • [^]Re: Un projet d'avenir...

        Posté par Cédric Brun (page perso, ) le 12/09/2006 à 13:57. (lien). Évalué à 4.

        De manière assez basique les approches sont similaires, Acceleo est cependant différents sur certains points :
        
        - OpenMDX génère effectivement vers différents frameworks (pour la persistance, la présentation) via ce qu'ils appellent des "plugins". À ce jours Acceleo ne dispose pas d'une base de module de génération open-source en dehors des modules d'exemples mais c'est clairement dans ce sens que l'on compte évoluer.
        
        - OpenMDX ne supporte pas la génération incrémentale. Autrement dit avec cet outil on génère le code, si on le modifie il devient impossible de fusionner les modifications après une éventuelle re-génération. Acceleo permet de re-générer sans perdre les modifications apportées au code.
        
        - Acceleo facilite la création de templates de générations (ce qu'OpenMDX appelle "plugins"). Ainsi on peut réaliser son propre template ou encore étendre un template existant en profitant d'un outillage complet (prévisualisation de la génération, complétion syntaxique, synchronisation entre le texte généré et l'élément du modèle correspondant)
        
        - OpenMDX ne gère qu'UML. Il n'est pas possible de définir ses propres concepts et de s'en servir pour générer du texte. Acceleo est compatible avec plus de modeleurs (en particulier des modeleurs libres tels que Umbrello) et permet l'utilisation de méta-modèles personnalisés
        
        - son intégration à un IDE (Eclipse) qui permet d'intégrer l'approche générale avec le développement du logiciel.

        • [^]Re: Un projet d'avenir...

          Posté par Bertrand Florat (page perso, ) le 12/09/2006 à 19:46. (lien). Évalué à 2.

          Juste un point: si acceleo (le projet open source) ne propose en effet pas de modules de generation, OBEO vend "Acceleo Pro Modules" qui integre la plupart des modules imaginables vers les architectures J2EE, PHP et .NET (sur J2EE: Struts, JSF, EJB, ...)