PlantUML, un nouvel outil de génération UML

Posté par . Modéré par Bruno Michel.
22
19
déc.
2010
Doc
PlantUML est un outil Java permettant d'écrire très rapidement des diagrammes UML en utilisant un langage texte simple et intuitif. Il supporte actuellement sept types de diagrammes : séquence, cas d'utilisation, classe, activité, composant, état et objet qui peuvent être générés au format PNG ou SVG.

Ainsi, par exemple le texte

@startuml
Alice -> Bob: synchronous call
Alice ->> Bob: asynchronous call
@enduml

génère le diagramme de séquence suivant :

Diagramme de séquence généré par PlantUML où Alice appelle Bob de manière synchrone, puis de manière asynchrone

Il est également possible de changer l'aspect visuel grâce à des paramètres de skin.

Grâce au soutien de la communauté open source, un écosystème de greffons a pu voir le jour : intégration Word / Open Office, intégration Eclipse, intégraton Emacs, intégration Javadoc / Doxygen, intégration MediaWiki / DokuWiki / Confluence, etc.

Des éditeurs graphiques ont également été développés comme PlantUML editor ou EasyUmlEditor et le projet PlantUML dependency permet la génération de la description PlantUML à partir d'un code source Java.
  • # Je déteste UML

    Posté par . Évalué à 3.

    Voilà, c'est dit.
    • [^] # Re: Je déteste UML

      Posté par (page perso) . Évalué à 6.

      Pour que ce soit un minimum intéressant, ce serait mieux de donner quelques arguments rationnels venant étayer cette détestitude, non?

      C'est un suppôt de .net? C'est utilisé par des satanistes?
      • [^] # Re: Je déteste UML

        Posté par (page perso) . Évalué à 2.

        Disons que maintenant, tu as une alternative réellement crédible à UML et beaucoup plus simple à mettre en oeuvre : les DSL.

        Ca te permet de te définir ton propre vocabulaire, ton propre modeleur avec tes choix de représentation graphique, le tout en gardant un format standard. En gros, si tu choisis de modéliser quelque chose de simple, et bien ca reste simple à utiliser ! Et si tu as un système complexe à mettre au point, et bien tu es libre d'aller très loin en précision de conception.

        Il y a une pres faite à un JUG qui explique un peu cela :
        http://www.parleys.com/#st=5&sl=1&id=2042
        • [^] # Re: Je déteste UML

          Posté par . Évalué à 6.

          > Ca te permet de te définir ton propre vocabulaire, ton propre modeleur avec tes choix de représentation graphique, le tout en gardant un format standard.

          cool, tu perds une grosse partie de l'intéret d'UML : être compris par les autres.
          • [^] # Re: Je déteste UML

            Posté par (page perso) . Évalué à 3.

            Ils faut voir aussi qui sont les autres. L'avantage du DSL, c'est justement qu'il est "Domain Specific", et va donc utiliser directement le vocabulaire et les concepts du metier pour en exprimer sa modélisation, et non un sabir d'informaticien.

            UML n'est pas compris par tout le monde, il est compris par les développeur logiciels dans un contexte objet. C'est pas mal, mais ça reste un DSL adapté a un public, et dans un but.

            Je travaille en ce moment avec des gens qui font de la modélisation de système critique, UML, ça leur parle pas. Il leur faut un DSL avec leur vocabulaire et qui reflete leur façon de faire.
          • [^] # Re: Je déteste UML

            Posté par (page perso) . Évalué à 3.

            Non, au contraire.

            Et si "les autres" comprennent déjà UML, ton DSL peut très bien s'appuyer sur une partie d'UML (genre, si tu veux modélisation un modèle Orienté Objet).
            Si tu veux réutiliser un diagramme (genre séquence ou activité) sur un DSL, il n'y a pas de problème : il faut bien différencier le diagramme, et le contenu de ce qui est manipulé. Comme ça, tu obtiens quelque chose de simple à comprendre, et réutilisant les formes que tu as déjà appris.
    • [^] # Re: Je déteste UML

      Posté par . Évalué à 9.

      UML c'est juste un ensemble de pictogrammes dont tu fais ce que tu veux. Après on a le choix de la méthodologie dans laquelle utiliser UML (contrairement à MERISE qui contient à la fois la méthodologie et la norme de représentation graphique).

      Ce serait plutôt envers la méthodologie utilisée qu'il faudrait râler (RUP étant la plus répandue). Ou même envers ceux qui appliquent absurdement une méthodologie à la lettre sans comprendre son but : permettre aux différents acteurs d'un projet (direction, métier, équipes techniques...) de communiquer entre eux via un langage commun. À partir du moment où on suit les étapes de la méthodologie juste pour suivre les étapes, qu'on produit les diagrammes et les documents parce que c'est marqué qu'il faut les faire, on perd de vue le but premier d'avoir une méthodologie et des diagrammes.
      • [^] # Re: Je déteste UML

        Posté par . Évalué à 4.

        +1.
        La plupart des bouquins sur UML insistent sur le point que c'est un langage de communication plus qu'une méthodologie où il faut produire tous les diagrammes sinon tu as perdu!
        • [^] # Re: Je déteste UML

          Posté par (page perso) . Évalué à 7.

          D'ailleurs, c'est ça qui a poussé au développement de PlantUML.

          J'en avais marre que pour faire un simple petit dessin explicatif, il fallait lancer des outils trop lourds (Rose...), et cela juste pour faire un petit diagramme.

          Ces outils peuvent être très puissants (génération de code, analyse automatique...). Mais pour faire simplement quelques diagrammes, ils ne sont forcément adaptés.

          Et la lourdeur inhérente à ces outils provoque la réaction classique : UML, c'est lourd, compliqué et je déteste :-)

          UML, cela sert à communiquer avec un symbolisme commun.
      • [^] # Re: Je déteste UML

        Posté par . Évalué à 1.

        >UML c'est juste un ensemble de pictogrammes dont tu fais ce que tu veux.

        Pictogrammes assez mal fichu: un rond plein ça dire X, un rond vide Y, bof..

        Pourquoi pas mettre tout simplement des nombre au dessus des fleches pour indiquer le nombre de relations possible.

  • # Excellent !

    Posté par . Évalué à 2.

    Je connais quelqu'un qui développe une bibliothèque d'analyse de code source C++ que je compte bien utiliser. Je pensais me servir de Graphviz pour générer des diagrammes UML à partir des résultats de l'analyse, mais ce petit outil est du coup beaucoup plus adapté.

    Merci pour l'info ;).
  • # C'est génial comme système.

    Posté par . Évalué à 3.

    J'aime beaucoup le côté embarqué dans Eclipse (comme le montre la vidéo du site officiel).

    Il est simple de commenter une classe et d'ajouter un diagramme de séquence.
  • # Pas de logo ...

    Posté par . Évalué à 3.

    Se protègent t-ils contre les méchants administrateurs de Wikipédia ?
  • # Rendu

    Posté par . Évalué à 2.

    Ca a l'air vraiment sympa comme outil, mais que cela donne t-il comme rendu avec plus de 15 (voire plus) de classes et plusieurs relations entre-elles ? Déjà avec un éditeur c'est pas forcément simple de trouver une configuration "lisible", mais est-ce que l'algo utilisé s'en sort bien pour éviter d'avoir un résultat illisible ?
    • [^] # Re: Rendu

      Posté par (page perso) . Évalué à 3.

      En fait, c'est GraphViz qui fait tout le boulot de placement des classes. Et en pratique, l'algo donne souvent de très bons résultats. (mais pas toujours :-)

      Exemples:
      [http://code.google.com/p/pyang/wiki/UMLOutput]
      [http://ews.mseedsoft.com/code-docs/page1.html]

      Quand il y a beaucoup de classes (disons plus de 60) la limite, c'est plutôt la taille de l'image générée, trop grande, qui fait que ce n'est plus lisible.
      • [^] # Re: Rendu

        Posté par . Évalué à 3.

        Et lorsqu'on atteint ces limites, comment s'en sort t'on pour reprendre les diagrammes ?

        Autant je vois l'intérêt pour la documentation (i.e dans un seul sens), autant je le saisis beaucoup moins comme support à la communication.

        L'avantage de la représentation graphique interactive est qu'on peut la faire évoluer "visuellement" et rapidement pour "échanger" des idées. Ceci est particulièrement important lorsque le diagramme commence à devenir complexe. Là, j'ai l'impression qu'il faut raisonner par tâtonnement en comparant le résultat généré en tentant de se repérer dans le pseudo-code saisi. Le coté "agile" doit en pâtir jusqu'à devenir contreproductif. Sans compter l'impossibilité de régler un petit détail si on ne peut pas retoucher le résultat obtenu.
        Bref, en dehors de cas triviaux, je ne saisis guère l'intérêt.

        Autre question:
        Tu sembles indiquer que l'intérêt de faire une sortie en xmi (ou uml2 eclipse) n'y est pas, mais y en existe t'il une ?
        C'est justement pour pallier ce manque pour quelqu'un qui souhaiterait reprendre cette ébauche travail dans un AGL classique que ca aurait un intérêt.

        En résumé, autant le fait de passer en mode textuel est intéressant, autant ménager la possibilité de s'intégrer avec un AGL classique serait un vrai plus.

        Que ce message ne t'apparaisse comme une critique simplement péjorative car je reste admiratif devant le travail accompli.
        Il y a un espace qui est brillamment occupé avec ce projet.
        • [^] # Re: Rendu

          Posté par (page perso) . Évalué à 3.

          Je suis d'accord avec l'auteur du logiciel quand il dit qu'UML est d'abord un outil de communication. En tant que tel UML n'est pas du tout réservé au génie logiciel, finalement, et il va bien plus loin que le seul et unique diagramme de classes ultra détaillé des élèves ingénieurs.

          En tant qu'outil de communication parmi d'autres, supportant d'ailleurs aussi bien une forme rédigée en tableaux qu'une forme diagramme, un diagramme UML n'a pas vocation à mes yeux à contenir 60 classes enchevêtrées, mais simplement les principales, pour faire passer des idées.
          • [^] # Re: Rendu

            Posté par . Évalué à 3.

            Je suis d'accord et c'est d'ailleurs ce que j'exprime.

            Sauf que là j'ai l'impression que la communication est à sens unique car uniquement contextuelle.

            Pas moyen de partager un même concept entre plusieurs diagrammes, Pas moyen de renommer une classe partout où elle apparaît, de remplacer simplement un héritage par une délégation, pour discuter de la pertinence de la décision...
            Au final, plus on utilise cet outil plus ces manques risquent de se faire sentir.

            Je saisis parfaitement l'intérêt d'un syntaxe écrite plutôt que de jouer à aligner les boiboîtes et faire des clics partout (nostalgie de StarUML et de ses quick dialogs sans doute) mais je voyais en plus un intérêt a réutiliser ça comme un greffon dans un autre modeleur en plus de celui de créer des diagrammes à la volée pour simplement documenter.
            • [^] # Re: Rendu

              Posté par (page perso) . Évalué à 2.

              Le point de vue pragmatique que tu exprimes me plaît aussi, je voulais juste rebondir. Chic chic on est d'accord :-)
        • [^] # Re: Rendu

          Posté par (page perso) . Évalué à 5.


          Tu sembles indiquer que l'intérêt de faire une sortie en xmi (ou uml2 eclipse) n'y est pas, mais y en existe t'il une ?
          C'est justement pour pallier ce manque pour quelqu'un qui souhaiterait reprendre cette ébauche travail dans un AGL classique que ca aurait un intérêt.

          En fait, l'export vers XMI est quelquepart dans la TODO liste.
          Je suis d'accord que cela serait un vrai plus, surtout que ca ne doit pas être très compliqué à faire.
          La seule chose qui m'empêche d'avancer sur ce point est le manque de documentation précise sur XMI.
          Si quelqu'un a un des liens sur des exemples simples & précis de fichiers XMI, je suis preneur!
          (Genre, le diagramme de séquence minimale : Bob -> Alice : Hello, et le digramme de classe minimale A <|-- B)


          Pas moyen de partager un même concept entre plusieurs diagrammes,

          C'est vrai, encore qu'avec l'utilisation d'!include, tu peux t'en sortir, même si c'est un peu une bidouille


          Pas moyen de renommer une classe partout où elle apparaît,

          Là, par contre, avec un petit sed ou alors avec ton éditeur de texte, c'est possible


          de remplacer simplement un héritage par une délégation, pour discuter de la pertinence de la décision...

          Remplacer :

          Role <|-- User

          par:

          User --> Role : utilise

          va très vite pour un expert du clavier. Je te met au défi d'aller aussi vite avec Rose / ArgoUml :-)
          Mais j'imagine que tu pensais à quelquechose de plus compliqué ?


          Que ce message ne t'apparaisse comme une critique simplement péjorative car je reste admiratif devant le travail accompli.
          Il y a un espace qui est brillamment occupé avec ce projet.

          Pas de problème. Le projet a beaucoup avancé grâce aux remarques (même négatives!) des utilisateurs, et on a le droit d'être dubitatif sur l'intérêt de PlantUML : il n'a pas vocation à sauver le monde :-)
      • [^] # Re: Rendu

        Posté par . Évalué à 2.

        Les diagrammes sur http://ews.mseedsoft.com/code-docs/page1.html sont très illustratifs !
        Néanmoins, les relations se marchent un peu dessus.

        Voici quelques exemples:
        - sur "High-level Classes", les relations sont toutes tordues et il devient difficile de les lire. Les relations entre les boites "drawables" et "model" ont l'air d'évoluer parallèlement, par exemple faucetGeom est associé a DripSource, WaterSurfaceGeom a WaveMedium et BarrierGeom a Barrier. Pourtant cela n'apparaît pas de manière évidente. Un humain l'aurait peut être représenté un peu comme le pattern Fabrique abstraite (patron de conception) ?
        - sur "GUI Widget Classes" la composition et la relation d'héritage entre osgNode et osgGroup n'est pas facile a lire car elles sont un peu l'une sur l'autre. De plus la composition entre EWSMainWindow et OSGWidget par un n'importe ou. Je ne sais si c'est la faut a GraphViz ou a PlantUML.

        Est ce que c'est le style Rational Rose utilisé sur ce diagramme ?

        Je chipote car les diagrammes créés sont vraiment bien! Ce logiciel me fait penser a GNU LilyPond et a son auteur qui est obsédé par le fait de faire un logiciel qui crée des notations aussi belles que si elles avaient été faites a la main par un "écrivain musical" (désolé je ne connais pas le mot a utiliser) expérimenté.
  • # XMI?

    Posté par . Évalué à 2.

    Quid de l'interopérabilité?
    Sans fichier xmi l'intérêt de l'UML est tout de même très restreint. Certes cela permet de visualiser rapidement certains use cases. Mais sans xmi il devient impossible de traiter l'information, d'en extraire des données ou d'en ajouter de manière dynamique.
    Donc oui l'intérêt est réel face à un end-user qu'il soit professionnel ou non. Mais dans ce cas le nombre de types de diagrammes supportés aurait pu être revu à la baisse.
    • [^] # Re: XMI?

      Posté par (page perso) . Évalué à 2.

      C'est une discussion que j'ai eu souvent :-) Tout dépend de l'usage que l'on fait de l'UML, et il y a beaucoup d'usages possibles.
      Je ne suis pas d'accord que sans xmi, UML est très restreint. D'ailleurs, il me semble qu'UML existait bien avant xmi. Pour la documentation, UML est super pratique.

      Certes, sans xmi, il est impossible de faire un traitement automatiquement de l'information. Mais on peut très bien utiliser UML sans avoir ce besoin précis.

      En plus, comme expliqué ici, chacun utilise son "standard" XMI [[http://modeling-languages.com/content/xmi2-tool-exchanging-u(...)]], qui du coup n'est pas si standard que ça (et du coup, on dit que UML est compliqué et lourd).

      PlantUML n'est pas un outil de modélisation, c'est plutôt un outil de dessin (on m'a même dit "dessin agile"). Le paradoxe, c'est que malgré cela, il aide quand même à faire de la modélisation.
      • [^] # Re: XMI?

        Posté par . Évalué à 1.

        C'est vrai que chaque outil a sa propre vision de la norme xmi (ou uml), il en va d'ailleurs également des gros outils tels rhapsody, rational software architect... Ca ne simplifie clairement pas le discours de l'OMG ou du moins la gestion de son discours.
        Pour le reste le coeur est tout de même assez homogène et les dissensions se font sur des détails.
        Je suis bien d'accord qu'ici le but du logiciel ne nécessite pas un export xmi.
        Comme vous le soulignez PlantUML est assez paradoxal, ce qui amenait ma remarque. Toutefois tant qu'il y aura des utilisateurs c'est qu'il y avait un besoin, donc je vous souhaite bonne route :) .
  • # Est-il d'accord ?

    Posté par (page perso) . Évalué à 10.

    Oui, avez-vous demandé à Plantu s'il désirait vraiment une mailing-liste à son nom ?
  • # uml c'est aussi utile que ... rien

    Posté par (page perso) . Évalué à 3.

    Prenons 2 exemples de descriptions de services : une en mode «diagramme de classe» à la gang des 4 et l'autre en «langage naturel» (presque) bien écrit, laquelle des deux prendrez vous ?

    papypal API SOAP en diagramme de classe :
    https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&c(...)
    papypal par web services :
    https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&c(...)



    UML (diagramme de classe et autres trucs d'ingénieurs pédants) ne marchent que pour donner une idée de comment ça marche (une vision top down), dès que l'on rentre dans une vision boite noire (IN/OUT/par IN/par OUT) alors, l'UML devient un fardeau. D'autant plus que pour les diagramme état/transition la réécriture équivalente en chronogramme UML est une putain de plaie.
    L'UML permet de remplir le vide avec une tétra chiée d'info qui parasitent le cerveau, et cache l'essentiel dans le foisonnement.

    Enfin, nous autres informaticiens travaillons pour des gens qui ont un métier avec leur langage. et pour travailler avec eux, on leur imposerait un nouvel alphabet, et avec des termes ésotériques ? Mais quelle pédance inutile. À part créer un effet tour de Babel (ou téléphone arable), ou créer un sabire de charlatan pour moi l'UML c'est H=k x ln (W) (de l'entropie dans un monde qui a besoin de simplicité).

    En physique, on impose que deux normes que je retrouve jamais dans UML :
    - que le schéma permettent de saisir l'essence du problème (et non la parasite) ;
    - que le schéma ait des légendes.

    Alors, en ce qui me concerne, à la norme UML, je préfère celle de mes études de physique dites des schémas explicatifs simples (une fois que l'on a beaucoup travaillé) non normalisés, mais légendés et expliqués...
    • [^] # Re: uml c'est aussi utile que ... rien

      Posté par (page perso) . Évalué à 4.

      Je suis à 100% d'accord.
      L'exemple de paypal est parfait : avoir des tas de diagrammes que l'on ne comprend pas ne sert à rien.

      Martin Fowler a expliqué il y a longtemps que l'UML était très utile pour présenter une version simplifiée, mais compréhensible d'un code.
      [[http://www.martinfowler.com/bliki/UmlAsSketch.html]]

      Cela permet d'avoir une vision globale du problème.
      Allez, puisque je fais ma pub, voici un diagramme des classes paypal faite avec PlantUML:

      [[http://www.plantuml.com/plantuml/uml/image/bPBFJiGW4CRlJVeEd(...)]]

      Cela me paraît plus compréhensible (même si je n'ai pas tout compris :-)

      Quant à la possibilité de rajouter une légende, c'est une bonne suggestion. Il faudra rajouter cette possibilité dans le logiciel...
      • [^] # Re: uml c'est aussi utile que ... rien

        Posté par (page perso) . Évalué à 4.

        Effectivement, le schéma original de Paypal est illisible, le tient est nettement mieux. Je soupçonne d'ailleurs celui de Paypal d'avoir été généré automatiquement d'après le code :)

        L'idéal, ça reste d'avoir l'UML pour les relations entre les classes et une description en langage naturel pour les paramètres/attributs et les trucs un peu complexes.

        Dans l'exemple de Paypal, ce que j'ai fais, c'est survoler la page décrivant l'API en langage naturel, puis j'ai jetté un oeil au diagramme version PlantUML pour voir un peu où sont les liaisons et je suis revenu à la description textuelle pour comprendre les détails.

        Bref, c'est un peu comme toujours, c'est un outil intéressant quand il est bien utilisé et ça ne sert à rien d'avoir uniquement des schémas UML comme documentation. Mais bon, ça permet d'avoir une vision global des liens entre les objets.
    • [^] # Re: uml c'est aussi utile que ... rien

      Posté par . Évalué à 4.

      Si vous résumez la norme UML à ce pauvre exemple effectivement je comprends que vous n'y trouviez aucun interêt. Maintenant je ne comprends pas que vous le résumiez à ce pauvre exemple.
      • [^] # Re: uml c'est aussi utile que ... rien

        Posté par (page perso) . Évalué à 2.

        Je pourrais aussi mettre cote à cote une RFC avec un diagramme état transition si cher aux electroniciens (avant d'avoir été labellisé UML compliant) et un diagramme de séquence. Et on aurait la même impression : l'UML reste la manière qu'utilise des singes pour paraître savant.

        L'UML raconte beaucoup de chose, parfois intéressantes, souvent inutiles. UML c'est comme une maison dans un film : il y a une belle façade, ça présente joliment, mais c'est très souvent vide derrière. Et je ne pense pas que la forme prime sur le fond.

        Donc, pour moi UML c'est le dictat de l'apparence sur le fond. L'avènement de noobs de la programmation qui sortent d'écoles qui y connaissent rien, et qui viennent expliquer aux codeurs comment faire, en prétendant qu'une fois le diagramme fait tout est fait.

        En ce qui me concerne, il y a les données structurées dans un coin, les traitements de l'autres, il y a des couches, des connexions, des états transition. Et si on fait bien son boulot, par la grâce de l'imaginativité, on tombe sur un truc simple. Et si c'est pas simple, alors on redécoupe en couche/boîte plus simple. Un peu comme unix, ou la conception d'un circuit électronique.

        On a des recettes de cuisines bas niveau (lock, décorateur, buffer ring, modules) qu'il faut savoir intégrer quand on reconnaît un problème (certes).

        Malheureusement aucun outil peut garantir qu'une personne a la capacité à bien voir un problème, à bien le disséquer. Pour moi l'UML est juste une n plus unième tentative de transformer les codeurs en ouvriers spécialisés au profit des ingénieurs, comme les jumbo-frameworks (rails, symfony, django).

        Je ne pense pas que cette vision de l'informatique a un avenir. Et je ne crois pas qu'il existe un espéranto de la symbolique informatique et une bonne manière de faire. Je crois qu'il y a des bons et des mauvais codeurs, et c'est tout.
        • [^] # Re: uml c'est aussi utile que ... rien

          Posté par . Évalué à 2.

          Lorsque je suis sur un projet avec plusieurs milliers de requirements sous DOORS j’apprécie de pouvoir les lier aux diagrammes UML présents dans ma spec. Pouvoir verifier quels sont les use cases non testés, inutiles… De même lorsque l’équipe de développeurs est importante c’est agréable de pouvoir se reposer sur un formalisme commun permettant d’éviter l’interprétation personnelle du langage naturel. Enfin non l’UML n’est pas réservé aux jeunes diplomés. Je ne dis pas et ne dirai jamais qu’UML est à appliquer dans tous les cas mais c’est une norme qui répond clairement à certains besoins. Si vous ne ressentez pas ces derniers, inutiles de vociférer à son encontre, passez votre chemin viola tout.
          • [^] # Re: uml c'est aussi utile que ... rien

            Posté par (page perso) . Évalué à -4.

            Si tous les devs ont besoin d'avoir les specs, c'est que le design est mal branlé. Voilà. UML c'est bien un truc de mauvais designer. CQFD.
            • [^] # Re: uml c'est aussi utile que ... rien

              Posté par . Évalué à 2.

              Je n'aurais jamais dû commencer à vous répondre :)
            • [^] # Re: uml c'est aussi utile que ... rien

              Posté par . Évalué à 1.

              Si tous les devs ont besoin d'avoir les specs, c'est que le design est mal branlé.
              Ou la la! Tu fais bien de t'arrêter la Hindifarai !
              Pourtant c'est pas vendredi !?!
              • [^] # Re: uml c'est aussi utile que ... rien

                Posté par (page perso) . Évalué à -1.

                Quand je suis syadmin, j'ai pas de specs uml imbittable, j'ai des man pages. Précis, concis et efficace. Et c'est pour ça que le CPAN/Perl reste un exemple de documentation de code, et d'architecture (à la unix):
                - modulaire ;
                - concis ;
                - documenté.

                L'ennemi du développeur c'est le couplage implicite et explicite. Juste parce que notre cerveau, aussi bien documenté soit un projet ne retient que peu d'information à court et moyen terme. La programmation c'est fait pour et par des humains. L'UML, ça diminue juste le rapporte signal bruit. Voilà.

                l'UML c'est un peu le XML de la programmation, juste hyperverbeux, et inefficace.
  • # Felicitation pour ce joli travail

    Posté par (page perso) . Évalué à 3.

    Merci pour ce très joli travail !
    Je ne savais pas que c'était un chtit francophone derrière plantUML.

    Je peux enfin faire de l'UML très correct avec Emacs. L'intégration avec org-mode et babel est vraiment top. Cela permet de vraiment faire de la programmation littéraire Programmation_lettrée. Et quel bonheur de ne pas avoir à lancer un mastodonte de clickodrome quand on veut juste faire un petit dessin explicatif...

    Bref, un grand merci et continuer sur cette voie !

    Je plussoie à l'idée d'avoir un export xmi car cela pourrait permettre de profiter des outils actuels de transformations (et pas simplement des générateurs de code).

    Sinon, par pure curiosité, avez vous regardé la norme "Human UML Textual Notation" (ou un truc dans le genre) de l'OMG, et si oui, qu'en avez vous pensé ?

    Jérôme
    • [^] # Re: Felicitation pour ce joli travail

      Posté par (page perso) . Évalué à 2.

      Je plussoie à l'idée d'avoir un export xmi car cela pourrait permettre de profiter des outils actuels de transformations (et pas simplement des générateurs de code).
      Ok, pour commencer, seuls les diagrammes de classes (j'ai l'impression que c'est ce que veulent les gens de toute façon) seront pris en compte, et on va tester avec ArgoUML et StarUML.
      Mais il faudra attendre l'année prochaine pour avoir ça :-)


      Sinon, par pure curiosité, avez vous regardé la norme "Human UML Textual Notation" (ou un truc dans le genre) de l'OMG, et si oui, qu'en avez vous pensé ?

      Quelqu'un m'a effectivement montré ça il y a quelque temps. [[http://www.omg.org/spec/HUTN/1.0/PDF]].
      D'ailleurs, cela a un peu influencé la syntaxe de PlantUML sur les diagrammes de classes et d'objet (utilisation d'accolades).
      En fait, cela m'a laissé un peu perplexe: dans le document, il est écrit que cela peut marcher pour tous les types de diagrammes.
      Mais les exemples ne contiennent que des diagrammes de classes ou d'objets, et je ne vois pas comment utiliser la notation pour les diagrammes de cas d'utilisation ou de séquence, par exemple.

      Est-ce qu'il y a des avantages par rapport à UMLgraph ?
      UMLgraph est très bien (d'ailleurs, je l'utilisais avant PlantUML, et c'est clair que cela a été une source d'inspiration), mais il ne se focalise uniquement sur les diagrammes de classes (et un peu les diagrammes de séquence). Il manque tous les autres.
      De plus, il est très orienté Java, puisqu'il est fait pour être mis dans la javadoc.
      Je le considère donc comme un illustre ancêtre! (au sens positif du terme)
    • [^] # Re: Felicitation pour ce joli travail

      Posté par . Évalué à 1.

      Tout à fait d'accord, c'est vraiment un beau boulot, je ne connaissais pas cet outil et j'ai l'impression qu'il est vraiment bien avancé. Merci pour l'intégration javadoc et l'intégration MediaWiki. Beau boulot.
  • # UMLGraph ?

    Posté par (page perso) . Évalué à 2.

    Est-ce qu'il y a des avantages par rapport à UMLgraph ?

    Merci.

    les pixels au peuple !

  • # Interopérabilité avec XMI

    Posté par (page perso) . Évalué à 2.

    Alors, en ce qui concerne l'interopérabilité avec XMI, supposons qu'on essaie de faire un fichier XMI qui marche à la fois avec StarUML et ArgoUML (au hasard), avec 3 classes, et 2 relations.

    Le problème, c'est que StarUML et ArgoUML n'interprètent pas tout à fait la balise <UML:AssociationEnd> de la même façon. :-)

    Si un fan de XMI réussi à faire un même fichier qui marche sur les deux produits, ça m'intéresse beaucoup. Mais je ne suis pas sur que cela soit possible...

    Fichier pour ArgoUML: [http://plantuml.sourceforge.net/testArgoUML.xml]
    Fichier pour StartUML: [http://plantuml.sourceforge.net/testStarUML.xml]
    • [^] # Re: Interopérabilité avec XMI

      Posté par . Évalué à 2.

      Tu ne devrais pas t'occuper d'ArgoUML qui en est resté à UML1.3 et te focaliser sur ceux qui implémentent le métamodèle UML2.

      Si tu ciblais la librairie uml2 d'eclipse
      http://wiki.eclipse.org/MDT-UML2

      Tu t'assures déjà une compatibilité avec une ribambelle de modeleurs
      libres (Topcased, Papyrus, UMLet, ...) ou non (RSA, eUML2, omondo, ...)
      Tiens d'ailleurs y'a un projet intéressant sur l'eclipse market:
      http://marketplace.eclipse.org/content/plantuml

      Dans les compatibles UML2 hors Eclipse, tu trouves StarUML (plus guère actif), Netbeans et Gaphor.

      Bref ArgoUML est presque une curiosité

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.