Discussion :

[deunz]

Bonjour,

Je suis tout nouvel utilisateur de UML et je me pose quelques questions

Les principales sont celles-ci :



Ai-je le droit par un nommage implicite de faire une distinction entre acteur ?

Suis-je obligé de faire un include vers le UC "s'identifier" ?

Enfin si oui , n'est-ce pas étrange de considérer que à CHAQUE consultation l'acteur identifié doit s'identifier ?

Merci pour ces éclaircissements =).

[deunz]

Bien , ayant lu ce fil :

http://www.developpez.net/forums/d10...ludes-extends/

J'en conclu que le UC ((s'identifier)) n'en est pas un ...

Pour autant , à mon sens cela reste quelque chose à traiter comme tel :/

Bref jvai considérer que s'identifier n'est pas un UC , et le placer comme précondition sur les vrais UC nécessitant une authentification ^^

[bruno_pages]

Bonjour,

Ai-je le droit par un nommage implicite de faire une distinction entre acteur ?

je suppose que vous vouliez dire explicite et non implicite

ce n'est pas un droit, c'est une obligation, je veux dire par là que des acteurs (rôles) différents ne doivent pas porter le même nom

par contre mettre acteur dans le nom ce n'est pas utile, et je ne prendrai pas non plus non_identifié et identifié qui se réfèrent plus à une action faite/pas encore faite et non pas à un rôle, pensez plutôt autour de quelque chose comme invité / anonyme et abonné / membre

Suis-je obligé de faire un include vers le UC "s'identifier" ?

non, comme vous le dites dans le second message c'est une précondition

J'en conclu que le UC ((s'identifier)) n'en est pas un ...

si si, c'est bien un UC, mais les autres ne l'inclue pas

[deunz]

Bonjour ,

Tout d'abord merci pour votre réponse.

Et oui explicite me paraît maintenant beaucoup plus adapté.



Donc voici un exemple de ce que serait un cas similaire.

Est-ce correct ?

J'ai une autre question concernant les cas du type (( Gérer ses achats )).

Est ce ce cas doit apparaitre comme tel ? Ca me parait clair que derrière ce cas
Il y en a d'autre plus précis : (( voir la liste de ses achats )) , (( voir son total dépensé )) , (( classer les achat par type d'objet )) .. etc etc .

De fait les UC de ce type doivent-il apparaître sur un diagramme UC car concernant une description textuelle avec scénario nominal c'est pas vraiment faisable.

PS:je trouve beaucoup de UC avec consulter / afficher : est-ce normal / correct ?

Cordialement.

[bruno_pages]

Bonjour ,

Est-ce correct ?

oui

gérer ses achats cela fait plutôt penser aux achats déjà effectués, il manque donc un UC pour en faire de nouveaux

J'ai une autre question concernant les cas du type (( Gérer ses achats )).
...

il n'y a pas de réponse simple pour dire ce qu'est un niveau de granularité raisonnable, surtout que cela dépend de la complexité de l'ensemble, vous devez mettre ce qui vous semble utile c.a.d. ce qui est 'important' donc pas ce qui est du niveau du 'détail', sachant bien-sûr qu'un UC ce n'est pas qu'une ellipse quand un diagramme et que chaque UC (et acteur) a par ailleurs une description textuelle qui permet par exemple de préciser ce que veux dire gérer. Bien évidemment aussi vous n'êtes pas limité à un diagramme d'UCs, et il est d'ailleurs préférable que chaque diagramme porte sur un seul sujet

[deunz]

D'accord c'est compris

Concernant ce diagramme c'était pour l'exemple j'avoue je me suis pas trop creusé pour faire complet


En tout cas merci beaucoup pour vos réponses!

A bientôt.

Cordialement.