Ainsi, par exemple le texte
@startuml
Alice -> Bob: synchronous call
Alice ->> Bob: asynchronous call
@enduml
génère le diagramme de séquence suivant :
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.
Aller plus loin
- Le site officiel (829 clics)
- Liste des greffons référencés (239 clics)
- Editeur PlantUML (629 clics)
- Génération à partir de code Java avec PlantUML dependency (241 clics)
# Je déteste UML
Posté par grondilu . Évalué à 3.
[^] # Re: Je déteste UML
Posté par mgoeminne (site web personnel) . Évalué à 6.
C'est un suppôt de .net? C'est utilisé par des satanistes?
[^] # Re: Je déteste UML
Posté par Etienne Juliot (site web personnel) . Évalué à 2.
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 Gniarf . Évalué à 6.
cool, tu perds une grosse partie de l'intéret d'UML : être compris par les autres.
[^] # Re: Je déteste UML
Posté par kadreg (site web personnel) . Évalué à 3.
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 Etienne Juliot (site web personnel) . Évalué à 3.
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 Nerdiland de Fesseps . Évalué à 9.
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 cosmocat . Évalué à 4.
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 PlantUML (site web personnel) . Évalué à 7.
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 reno . Évalué à 1.
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 monsieurmoche . Évalué à 2.
Merci pour l'info ;).
[^] # Re: Excellent !
Posté par monsieurmoche . Évalué à 3.
(Et je viens de découvrir un easter egg de LinuxFR ^^.)
[^] # Re: Excellent !
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 1.
Alexandre COLLIGNON
[^] # Re: Excellent !
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
# C'est génial comme système.
Posté par syj . Évalué à 3.
Il est simple de commenter une classe et d'ajouter un diagramme de séquence.
# Pas de logo ...
Posté par liperon . Évalué à 3.
# Rendu
Posté par Atson . Évalué à 2.
[^] # Re: Rendu
Posté par PlantUML (site web personnel) . Évalué à 3.
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 El Titi . Évalué à 3.
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 feth . Évalué à 3.
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 El Titi . Évalué à 3.
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 feth . Évalué à 2.
[^] # Re: Rendu
Posté par PlantUML (site web personnel) . É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 djano . Évalué à 2.
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 kbiger . Évalué à 2.
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 PlantUML (site web personnel) . Évalué à 2.
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 kbiger . Évalué à 1.
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 lolop (site web personnel) . Évalué à 10.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# uml c'est aussi utile que ... rien
Posté par Jul (site web personnel) . Évalué à 3.
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 PlantUML (site web personnel) . Évalué à 4.
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 Jux (site web personnel) . Évalué à 4.
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 kbiger . Évalué à 4.
[^] # Re: uml c'est aussi utile que ... rien
Posté par Jul (site web personnel) . Évalué à 2.
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 kbiger . Évalué à 2.
[^] # Re: uml c'est aussi utile que ... rien
Posté par Jul (site web personnel) . Évalué à -4.
[^] # Re: uml c'est aussi utile que ... rien
Posté par kbiger . Évalué à 2.
[^] # Re: uml c'est aussi utile que ... rien
Posté par djano . Évalué à 1.
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 Jul (site web personnel) . Évalué à -1.
- 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 jérôme Delatour . Évalué à 3.
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 PlantUML (site web personnel) . Évalué à 2.
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 funkygono . Évalué à 1.
# UMLGraph ?
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
Merci.
les pixels au peuple !
# Interopérabilité avec XMI
Posté par PlantUML (site web personnel) . Évalué à 2.
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 El Titi . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.