Discussion :

[pigeon11]

Quelqu'in peut m'éclaircir la relation d'héritage entre acteurs dans un

diagramme de cas d'utilisation ?

Si un acteur B hérite de A, est ce que cela signifie que B a accés aux

uecases de A ?

Est ce qu'on doit mettre la relation d'héritage entre acteurs juste si B a

accés à tous les usecases de A ?

j'ai un acteur administarteur et un acteur fonctionnaire et chacun a ses

propres usecases. L'admin ne fé pa ce que fé le fonctionnaire. Je ne sais pas

si je ne dois pas mettre la relation d'héritage entre ces 2 acteurs ?

[bruno_pages]

Si un acteur B hérite de A, est ce que cela signifie que B a accés aux uecases de A ?

oui, B peut heriter de A si tous les cas d'utilisation accessibles à A le sont aussi à B

Est ce qu'on doit mettre la relation d'héritage entre acteurs juste si B a accés à tous les usecases de A ?

s'il existe un use case accessible à A mais pas a B il ne peut y avoir d'héritage

L'admin ne fé pa ce que fé le fonctionnaire

alors admin ne peut pas hériter de fonctionnaire

c'est simple : si B ---|> A, alors quelque soit les use cases ou A apparait il est possible de mettre B à la place (mais pas l'inverse)

il y a des tutoriels UML sur DVP, par exemple UML 2.0 : Cours complet et les cas d'utilisation

[pigeon11]

j'ai un projet concernant la gestion de courriers.

J'ai réalisé les diagramme se usecase et de contexte

Diagrammme de usecase

- usecase "gérer corriers émis": ca permet de voir la liste des courriers émis, leurs points d’arrivées et le temps qu’ils sont restés chez le destinataire.

-usecase "suivre courrier" : permet de voir le point d’arrivée d’un courrier, s’il a été traité et le traitement qu’il a subi.

1- il ya une relation d'extension entre eux. est ce qu'elle est juste ?

-usecse "gérer courrier sortants": permet de voir une liste de courriers qui sont venus de l’intérieur de la direction

- usecase "cofirmer la reception des courriers sortants " : permet de valider la réception d’un certain nombre de courriers qui viennent d’être reçus.

2- 1- il ya une 2ème relation d'extension entre eux. est ce qu'elle est juste ?

3- ya t-il dse choses qu manquent ?


Diagramme de contexte

est ce que c juste de mettre comme messages entrants les messages suivants ? :

-confirmer le recption des courriers
-envoie des courriers
-envois des messages
il apparaissent au niveau du responsable du bureau d'ordre et du fonctionnaire

[pigeon11]

Merci de bien vouloir me corriger mes diagrammes

[bruno_pages]

Merci de bien vouloir me corriger mes diagrammes

on se doutait bien qu'ils étaient publiés pour cela

concernant les use cases (je ne sais pas ce qu'est un diagramme de contexte) :

• l'authentification étant incluse par tout le monde, il serait sans doute plus simple de finalement de pas mettre les inclusions dans le diagramme
• c'est peut être trop précis et certaines distinctions ou UC peu utiles ? (gerer les utilisateurs, gerer les fonctions utilisateur) (gerer courier creer)
• les extends sont ok
• ce n'est pas parce que l'on a Acteur------UC1 <|-----UC2 que l'on a Acteur----UC2. Il manque donc plusieurs relations acteur---UC
• faire trois diagrammes au lieu d'un seul (même s'il y en a peut être qu'un pour n'insérer qu'une image sur DVP) car ils ne sont pas reliés. Il faut impérativement qu'un diagramme d'UC soit simple, un diagramme complexe n'indique pas que celui qui l'a fait domine un sujet complexe, au contraire

[ego]

- S'authentifier : inutile
- Les extend ne sont à utiliser que si tu as un acteur relié directement au UC qui "extend". C'est à dire si ce UC peut être directement exécuté par l'acteur.
- La relation d'héritage avec Gérer les couriers n'apporte par grand chose. Il est préférable de ne mettre que tes 3 "Gérer...".
- Y a t-il une différence fondamentale entre les 3 "Gérer courier..." ? Si la réponse est non, peut être qu'un seul UC est suffisant
- Même remarque sur les UC du Responsable.

[pigeon11]

Merci pour vos réponse , bruno et ego

- concenant la remarque de bruno

ce n'est pas parce que l'on a Acteur------UC1 <|-----UC2 que l'on a Acteur----UC2. Il manque donc plusieurs relations acteur---UC

vous parlez des relations d'héritage. il vaut mieux de les remplaces par 3 usecases sans mettre d'héritage pour corriger le pb ??

-concernant la remarque d'ego :

Les extend ne sont à utiliser que si tu as un acteur relié directement au UC qui "extend". C'est à dire si ce UC peut être directement exécuté par l'acteur.

- dois je mettre une relation directe entre fonctionnaire et gérer courriers émis ?

-est ce que vs avez des remarques sur mon diagrmme de contexte?


Merci