Voici donc le topic unique UML. C'est nouveau, ça vient de sortir. Dans le topic, je causerais d'UML, de ce qu'il est, de ce qu'il est pas, et de ce que ça contient.  
 
Ca parlera UML 1 (l'actuel) UML 2 (le futur), des diagrammes, voire même de profils ou de MDA, mais juste si vous avez pas peur.
 
Bien entendu, si vous avez quelques question, vous pouvez les poser, c'est un topic unique comme un autre
 
Pour commencer, on va le dire tout de suite : UML n'est pas une méthode. UML, qui signifie Unified Modeling Language est un langage graphique destiné à modéliser des systèmes objets (normalement). Il est apparu en 1997, suite au rapprochement de plusieurs méthodes objets tels que OMT, OOSE ou booch, ainsi que des travaux sur l'expression des cas d'utilisation d'ivar jacobson. En novembre 1997, la première version (UML 1.0) est standardisée par l'OMG (qui s'occupe aussi de CORBA). Depuis, plusieurs versions se sont succédées, retouchant certains concepts, et on en est à la version 1.5.
 
La version 2.0 est en cours de finalisation à l'OMG (depuis déjà un certain temps d'ailleurs...), mais on commence à voir apparaitre les premiers outils basés dessus.
 
Pourquoi je dis qu'UML n'est pas une méthode ? Parce qu'il s'agit d'un ensemble de diagramme destiné à exprimer certaines notions, mais que leur utilisation, est laissé à l'appréciation de l'utilisateur. Certains processus de développements, tel le RUP, utilisent d'ailleurs les différents diagrammes dans leur synopsis, ou sinon, il arrive que l'on utilise la notation UML (généralement un sous-ensemble) avec des méthodes plus classiques.
 

Yallaa ! Cool je vais pouvoir squatter trankilou chez moi au lieu d'aller en amphi
 
Non serieux, j'ai pas trop saisi les ficelles des diagrammes de sequences ... c'est au menu ?
 
PS : La seule chose qui me motivait pour ce cours c'était la prof ... OMG      

 
Pas tout de suite. Parceque c'est le diagramme qui me soule le plus et parcequ'il est entièrement refait dans UML2.

+2000  

Bon, les pollueurs, restez sage un peu, ce soir, je vais causer du premier diagramme :  
 
le diagramme de cas d'utilisations
C'est, selon pas mal de processus de développement, le premier diagramme que l'on utilise lors du  
 
développement d'un système. Son but est d'exprimer, d'une manière simple, le rôle d'un système, ce qu'il  
 
doit faire et les éléments qui interragissent avec lui. C'est généralement utilisé en phase de recueuil  
 
des exigences, par interview des utilisateurs. C'est également un diagramme qui est simple et permet  
 
d'avoir des retours de non-informatiens.
 
Voici un exemple de diagramme :  
 

 
La première chose que l'on voit est un ensemble de use case (les patates). Un use case est une  
 
fonctionnalité du système modélisé, sur laquelle on pourra plus tard accrocher un scénario plus  
 
complexe. Traditionnellement, on les nommera avec des termes "d'action", car le système FAIT quelque  
 
chose dans ce cas.
 
Ensuite, on a des acteurs. Un acteur est un élément externe au système, mais qui interragiut avec le  
 
système. On pense tout de suite aux utilisateurs en tant que personnes, mais ce n'est pas que ça. Par  
 
exemple un capteur mécanique ou un autre système peuvent parfaitement être un acteur. Enfin, signalons  
 
qu'il est généralement inutile de faire des liens entre les acteurs, on modélise le système, pas ce qui  
 
est autour. Dans l'exemple ci-dessus, inutile de faire hériter modérateur d'utilisateur, ça ne regarde  
 
pas mon système.
 
Enfin dernier cas, ce rectangle qui traine sur le diagramme. C'est ce que l'on appelle le "system  
 
boundary", la frontière du système, qui marque les limites du système à modéliser.
 
Il existe également des liens entre les uses cases, destiner à extraire certain sous-ensemble que l'on invoquera lors de plusieurs uses cases. Il y a deux type de liens, <<includes>> qui permet de faire sortir une sous-partie d'un cas d'utilisation (taper son mot de passe est l'exemple bateau), et <<extends>> qui permet de faire de "l'héritage" de use case.
 
Pour terminez, n'oubliez pas que les dessins sont bien gentils, mais largements insufisants. Tout cas d'utilisation se doit d'être bien documenté, avec des explication précises, des préconditions (pour poster, un contributeur ne doit pas être banni) et être validé par des cycles de revue.

Cool le topic
 
Dans le diagramme des use case, faut-il préciser qu'un modérateur est aussi un contributeur ? Y'a-t-il moyen de le faire ? Ou est-ce que c'est un aspect qui n'entre pas dans les use case ?

 
En fait, il ne faut pas voir un acteur comme une personne, mais comme un élément qui interragit avec le système. Ca peut être la même personne qui prend deux rôles différents suivant le cas. Suivant le contexte, antp sera contributeur ou modérateur, et suivant le contexte, interragira différemment avec le forum.
 

 
On peut mettre des héritages entre acteurs, mais cela signifie modéliser l'extérieur du système, ce qui me semble mal(tm)
 

 
C'est un problème philosophique J'ai ici mis mon avis, d'autres peuvent en avoir un différent.

Ok je vois, merci
 
J'ai fais de l'UML l'an dernier, mais on l'a survolé. On n'a fait que les graphes d'héritage, pas les use case

 
(il cause bien kadounet )

Autrement dit, un cas d'utilisation est un scénario, et l'ensemble des cas d'utilisation est l'ensemble des scénarios possibles dans l'intéraction avec le système. Ce qui signifie que le cas d'utilisation n'est qu'un diagramme, mais que le scénario doit en principe être écrit en français par ailleurs.
Peut-on, par extension, considérer qu'un cas d'utilisation est l'équivalent d'un test de validation, voire d'un contrat, une spécification ?
Ce qui reviendrait en quelque sorte à faire du design par contrat.

 
A peu près, sauf que je dirais plus prévu que possible. Certains scénarios tordu peuvent apparaitre lors de l'implémentation.
 

 
Un use case est plutot une partie de spécification. Il reste insuffisaemment fin pour être exauhstif, et ne permet de modéliser que des contraintes fonctionnelles. Les contraintes non fonctionnelles, qui font pourtant parti de la spécification. Mais il est clair que de la spécification, on va tirer tout un ensemble de tests de validation.
 

 
Non, parceque l'on est pas en phase de design. Et c'est un contrat assez informel. Je n'ai jamais vu personne mettre des contraintes formelles exprimées en OCL sur  des UC. (si vous ne comprenez pas cette phrase, c'est pour une prochaine explication).
 
Accessoirement, on notera la faiblesse d'UML dans ce type de phases amont, puisqu'on a rien pour le receuil des exigences, ni le moindre dictionnaire pour vérifier que tout le monde parle le même langage. Ces notions sont apportées dans les processus de développement par des moyens autres qu'UML.

Muchacho > il est clair que la recette définitive consistera entre autre à dérouler tous les scénarios des use-cases.

Aller hop, on améliore ça et on invente le HFRUML

Mouais, déjà sur ton premier diagramme je ne suis pas trop d'accord avec l'include. Un diagramme de use case doit contenir les actions élémentaires pour chacun des acteurs. En gros je n'aurai mis que Poster et Modérer (avec en plus un lien entre modérateur et poster, ou alors un "héritage" avec le contributeur).

 
C'était un exemple pour montrer à quoi ça ressemble et essayer de justifier un <<include>>, d'ailleurs "Modérer" n'est pas franchement une action (trop abstrait).

CMk > il classifie ses uses-case de façon hiérarchique pour pas que ça devienne le bordel trop vite.
 
D'autre part, il a déjà dit 15 fois que les relations entre les acteurs on en a rien à branler, ils sont pas dans le système. Comme on s'en fout, la politique c'est d'user le moins d'encre possible dans l'imprimante.

 
Certes, mais il me semble que quand on fait un tutos, il faut quand même présenter et expliquer les méthodes utilisées actuellement. Actuellement, la mode c'est la simplification des diagrammes de use case, qui ont tendance à devenir un peu un fourre-tout incompréhensible. La ok c'est pour l'exemple, mais bon autant partir sur de bonnes bases
 
 

Oui, il l'a dit, mais comme il l'a dit 15 fois, chacun voit un peu comme il veut le schmilblik. Pour certain cas non évident, il vaut mieux les mettre.

 
 je vais sans doute me faire incendier, mais et Merise par rapport a l'UML?

déjà merise c'est une méthode qui comprend une notation et pas une notation seule.
 
Ensuite, merise c'est pas orienté objet, UML l'est.
 
Enfin et de manière non négligeable, Merise c'est uniquement français.

ceci dit, un truc "objet" comme les EJB ne sont en fait qu'une vielle revanche des papys du merise sur les jeunes javateux. Les Entity beans modélisent les données et les Session beans modélisent les traitements. ça rend caduque tout le système d'encapsulation.

J'aurais plutôt utilisé << extends >> au lieu d'<< include >> : Bannir est une "spécialisation" de Modérer.
http://uml.free.fr/cours/p10.html#uc
 

Pas tout à fait :

 
C'est vrai que Moderer c'est pas "systematiquement" bannir ... quoique c'est discutable (genre un modero un peu expeditif)

un pti up ! on voit même plus ton beau diagramme avec tes bêtises  

 
Je reprendrais lorsque :
- je serais plus ban d'images
- j'aurais le courage de fairte un paté sur le static class diagram
 

Bonjour,  
 
etant donné que je n'ai pas trouvé d'autres sujet sur UML je pose ma question ici, excusez moi si j'ai eu tord!!
Je souhaiterai savoir qu'est ce que vous me conseillerez comme logiciel simple et gratuit pour faire des digrammes UML,  
Ya Visio mais c'est payant
Dia, mais je trouve pas la version windows
d'autres???

 
En cherchant, on trouve.
http://www.google.com/search?hs=9c [...] ercher&lr=

Oki si je pose la question c'est pour avoir d'autres logiciels que ceux que je connais deja, meme si je me suis mal exprimée...

Poseidon for UML (http://www.gentleware.com , version Community).
 
Et Dia que tu connais deja, qui avec un plugin peut sortir du php5.
 
Waterproof::UML, pour le php4/5.  
 
PS : Je suis développeur web et ca se voit je crois, désolé donc, mais il y en a surement d'autre pour java, c++, et j'en passe

oki oki merci beaucoup, j'en également besoin pour du developpement web alors merci bcp

parceque j'ai 2 jours pour assimiler l'UML

C'est une reprise de la pub ovomaltine ?

ben je dois faire l'intermediaire entre le client et le codeur, et je commence chez le client lundi. On y gagnera tous si j'arrives a mettre l'analyse au propre en UML directement. Donc j'essaye d'engranger un max d'infos, j'ai achetté u bouquin plutot bien foutu, et il me reste 36h

En une semaine de formation j'ai eu l'impression de quasiment rien faire...alors en 2 jours...

 
ROFL
 
Bon on verra ce que ça donne, de toute façon je vais apprendre "sur le tas", comme d'habitude.
 
J'en profite pour demander vos suggestions quant au soft à utiliser pour modeliser. J'ai un ex collèque qui prechait rational rose, mais d'autres comme dia+dia2code ou uml designer (coir poseidon qu'on vient de me suggerer) pourraient faire l'affaire. Vos preferences? (je suis sous windows, linux et OSX/x86 indifferament) Idéalement un qui soit simple a prendre en main...

le premier qui dit 'Dia' a un blame