Reprise du message précédent :
le premier qui dit 'Dia' a un blame

il l'a deja dit

mince
 
 j'osais esperer qu'on en etait pas encore la

j'ai raté un episode?

nan nan, enfin, si, plein, dia c'est un running gag sur la cat

quelqu'un me racontes?

Dia est comment dire... special au niveau de son interface... genre ca resemble a du windows 3.1 moche et aussi intuitif qu'une application faites par un autiste aveugle
 
 ce qui a permis de nombreux debat quant a Dia

poseidon est pas mal...

 
Umbrello, sous nux
 
Et dia est pas moche quand tu es sous linux, mais sous windows il l'est puisque la version windows ne dispose pas de thèmes gtk avec la bibliothèque gtk+.
 
+ 1 pour Poseidon.

moi j'utilise ArgoUML Il commence enfin à être utilisable (niveau bugs)

Putain mais BOUML, quoi  

Mais BOUML c'est moche

 

 
il a beaucoup fait rire au bureau

Même Dia est beau (enfin sous nux, sous win ca fait lego)

Poséidon n'est pas mal en effet mais la version que j'utilise (community édition) est trop buggée à mon goût (erreurs fatales - merci d'être passé).  
 
Un inconvénient (mais probablement dû à mon poste de travail) : très long à charger.
 
Mes bugs peuvent provenir d'un problème avec la VM Java. C'est pas le premier qui me saute à la gueule.  
 
En produit commercial, il y a Rational Rose mais tu as intérêt à aligner la monnaie.    
 
Y a des professionnels qui se servent très bien d'UML. Je viens de me cogner une description UML d'une API Nokia alors je peux le dire : un diagramme UML bien fait (et dans le contexte) c'est mieux qu'un dessin (oups c'en est un en quelque sorte).    
 
Par contre, il faut savoir lire UML bien sûr...

 
Mais on s'en fout, ça marche, et plutôt mieux que Rational Rose.  
Et Bruno l'améliore tous les jours (la dernière version a moins d'une semaine), maintenant il ajoute les XMI.(bon y'a un truc qu'il n'a pas mis, c'est la fonction undo/redo... , et ce genre d'omissions ne joue pas trop dans la popularité du produit...)
 
 
[PUB]Bouml, les utilisateurs sont ceux qui en parlent le mieux

http://www.developpez.net/forums/v [...] viewresult

http://www.geekswithblogs.com/flan [...] /1594.aspx
[/PUB]

 
L'undo fonctionne et l'outil est devenu parfaitement utilisable au quotidien.
Le round-trip est en cours (bon, faudra pas être pressé avant que ça fonctionne).

Mais revenons au sujet principal du topic.
 
J'ai bcp de mal avec les diagrammes dynamiques comme le diagramme d'activités même pour des process simples, alors que je suis parfaitement capable de les décrire dans le détail à l'écrit.
 
Quels sont les diagrammes les plus utiles ? Quels sont les diagrammes redondants ?

Ca rejoint justement ce que j'étais en train d'écrire à Bruno Pagès:  
 

Enfin, au moins, on n'est pas obligé d'utiliser l'intégralité des 13 diagrammes. Après tout, ils sont censés servir à éclaircir le discours, pas à l'obscurcir. Je pense que dans la plupart des cas, il vaut mieux se limiter à 5 ou 6 diagrammes conceptuellement bien distintcs, comme le diag de classes, de composants, les use cases, d'états et de séquence.

l'héritage entre "states machine" et "activity diagram", c'est de la bidouille, un héritage technique, parce que tous les deux ont des trucs techniques en communs.  
 
C'est comme faire hériter vache d'armoire normande parce qu'elles ont tous les deux 4 pieds

Merci kad
Sur ce Bonne nuit !

bon alors ca continue la description des diagrammes ?
(c'est tout ca mais moi j'ai pas touche d UML depuis la fac , ca me rafraichit bien la memoire et j ai pas les nerfs de me ressortir des cours ou un tuto )
 
excellent topic

Salut, j'essaie de me mettre à UML, design pattern et compagnie parce que j'en ai marre de coder comme un porc et de perdre mon temps... par contre je suis assez feignant en lecture et la tentative avec "o'reilly - learning uml 2.0" vient d'échouer
 
Ma question c'est : qu'est ce qui est vraiment indispensable pour pouvoir définir proprement l'architecture des futurs fichiers sources ? Car le problème que je rencontre, c'est que je me lance dans le développement, je fais mes classes etc sauf qu'ensuite je passe mon temps à restrcturer mes classes et au final, enormement de temps perdu... J'ai pas envie pour l'instant de faire tous les diagrammes de séquences etc, juste m'aider à y voir clair dès le début sur l'architecture idéal de mes fichiers, et donc le découpage en packages / classes + les attributs / méthodes et les relations entre tout ça.
 
Donc, ce qu'il me faut impérativement, c'est les diagrammes de classes uniquement ? Je peux les faire direct sans faire de use case avant ?
 
Pour des projets de tailles restreintes j'imagine que y'a pas besoins de diagrammes pour les packages / composants... si ?
 
PS : j'ai trouvé un cours de sun qui s'appelle "analyse et conception orientées objet avec uml et réalisation en c++", qui traite donc d'uml, traduction typique des schémas en code C++ et a la fin y'a aussi du design pattern... je trouve ce truc très sympa car il cible justement ce que je voulais apprendre en un seul morceau : pas besoin d'aller lire 3 livres différents. Vous en avez des autres dans le même genre ?

UML tout seul ça va pas beaucoup t'aider, par contre les design patterns c'est tout de suite plus concret et là je te conseille le bouquin Head First Design Patterns

Merci ! Ton intervention va surement m'être bien utile car j'aurai au contraire penser que les design patterns pouvaient être utiles mais qu'on pouvait aussi très bien s'en passer !

Faut pas oublier qu'UML est là pour t'aider à modéliser le problème (donc le résoudre) pas pour t'entraver dans ta démarche. Alors si faire certains diagrammes ne sert à rien pour ton projet (le diagramme de composants en est un exemple significatif) ne le fait pas.
 
Encore faut il comprendre à quoi servent les différents diagrammes et les utiliser judicieusement...

Et un modérateur ne peut pas poster ?  

Tout dépend s'il a deux comptes distincts ou non mais à priori manque une relation d'héritage en effet

 
Un modérateur est un utilisateur. Cela peut donc se modéliser par une relation d'héritage.
 
MAIS
 
Mais on modélise un système, limité par le fameux rectangle noir du diagramme de use case , appelé System Boundary. Les acteurs sont des éléments extérieurs agissant avec le système, mais ne faisant pas parti du système. En cela, ne faisant pas parti du système, leur relation ne m'interresse pas, et n'est donc pas à représenter.  
 
Pour moi, il ne manque pas cet héritage. On ne modélise pas l'exterieur du système. Il s'avère que la même personne peut endosser les deux roles, suivant le cas d'utilisation, mais c'est un problème extérieur.  
 
Ce n'est pas une vérité absolue, certains préféreront avoir cela. Mais cet argumentaire est celui que l'on a choisi ici après réflexion sur le sujet.

L'usage ne veut-il pas que l'on trace un trait entre l'acteur "Modo"et le use-case "Poster" ? Pour justement conserver l'information qu'un modo peut poster. Autrement, où documentes-tu le fait que Harko peut nous imposer ses calembours foireux ?

Si j'ai bien compris, ils veulent dire que ça n'apporte rien dans ce diagramme de faire le lien entre le Modo et le Poster, et de plus on peut supposer qu'il existe un Modo qui n'aurai jamais besoin de poster, un espèce de nettoyeur qui n'a pas à se justifier ... même si j'ai jamais vu ça dans les forums, mais pourquoi pas après tout.  
 
Par contre si ce diagramme a été fait dans l'idée que le modo peut poster, alors ce diagramme est incomplet et donc inexploitable.  
 
Ne pas divulger une information qu'on sait pertinente est comme mentir.  

Ajouter la relation d'héritage n'à qu'un seul intérêt : exprimer un élément descriptif du domaine, c'est à dire "un modérateur peut poster". Si j'appliquais la ligne directrice de UML 2 par la pratique, je mettrai la relation d'héritage mais ce n'est qu'un élément descriptif qui n'a pas d'impact sur la réalisation (quoique se posera la question de l'administration des comptes utilisateurs où cette problématique va sauter au visage)

si je puis me permettre (je ne suis pas un expert UML   ) kadreg a raison en disant les acteurs sont des éléments extérieurs ... leur relation ne m'interresse pas, un modérateur ne poste jamais et le dessin indique que par définition celui qui poste est un contributeur.
 
Le fait que quelqu'un puisse être à la fois modérateur et contributeur n'a strictement aucune importance dans ce use case car ce n'est pas ce que celui-ci veut montrer, si vous vous posez la question c'est peut être que vous êtes déjà en train de penser implémentation, ce qui n'est pas du tout le rôle d'un use case, au contraire.
 
Un use case doit être simple, le but n'est pas de tout dire sur un diagramme, contrairement à une description d'implémentation qui au final doit tout prendre en compte.
 
Si on veut montrer qu'un administrateur puisse aussi poster des messages alors cela peut par exemple se faire via un use case parlant de l'inscription genre:
 
En tout cas cela indique un problème récurrent : les use cases devrait être les diagrammes les plus simples à exprimer car par définition ceux-ci doivent être simples ... et en fait ce sont souvent ceux qui posent le plus de problèmes car leur utilisation/lecture est détournée.
 
Bonnes modélisations !

Chuis pas d'accord du tout. Certes, comme ce sont des éléments externes du système, il n'est pas nécessaire de signaler quelle est la relation entre le modérateur et l'utilisateur.
 
Cependant, en terme de capture des besoins logiciels, il est indispensable pour un forum type HFR ou type PHPBB de signaler qu'un modérateur PEUT poster des messages comme tout utilisateur. Donc il faut enregistrer le lien entre le modérateur et le use-case "Poster".  
 
On pourrait à la limite considérer que le use-case "modérer" étend le use-case "poster", et donc mettre un "include" ou un "extends". Mais ce n'est pas la compréhension que j'ai de ce use-case là (sans doute faudrait-il le découper en autres uses-cases, du style: "supprimer des messages", "bloquer des topics", etc. Pour moi, il est disjoint de l'activité "poster".
 

D'accord avec Lam's qui illustre ce que j'ai dit plus haut : "quoique se posera la question de l'administration des comptes utilisateurs où cette problématique va sauter au visage"