Diagramme de cas d'utilisation UML - système de tirage au sort

Question

Dans ce diagramme de cas d'utilisation, j'essaie de montrer comment l'administrateur du tirage au sort peut voir la liste de tirage mise à jour après qu'un client a participé au tirage au sort. Une fois que le client a participé à la tombola, le système vérifiera et vérifiera les doublons et s'il n'y a pas de doublons, la liste de tombola sera mise à jour.

L'image suivante est ma tentative sur le scénario cependant, je ne suis pas sûr si c'est correct. Pouvez-vous s'il vous plaît me conseiller?

edit: J'ai plusieurs questions:

1) En cas où j'utilise le système de tombola lui-même pour vérifier l'entrée de tombola, je ne serais pas besoin de mettre un cas d'utilisation pour la vérification parce que le système de tombola n'est pas un acteur correct?

2) Toutefois, si l'acteur est un autre membre du personnel du système de tombola (où il trie le tirage au sort manuellement), le cas d'utilisation pour la vérification serait-il applicable?

3) Si oui, est-ce le bon diagramme pour illustrer (2)?

Update entry -- <<includes>> --> Verification 

Answer 1

Votre diagramme a quelques erreurs:

• System est jamais un acteur externe. Il agit à l'intérieur du système considéré représenté par la frontière. Par conséquent, Verification n'est pas un cas d'utilisation valide. C'est une fonctionnalité interne.
• <<extend>> fonctionne dans l'autre sens (déplacez la flèche pointant de l'autre côté). Le même pour <<include>>.
• Verification n'est pas un nom pour un cas d'utilisation. Il a besoin de prédicat/sujet et éventuellement d'un objet.
• Généralisation (à Update entry) est une mauvaise idée pour les UC et probablement pas ce que vous vouliez montrer ici (alors quelle est l'intention ici?).
• Fondamentalement UCs sont sur la valeur ajoutée apportée à leurs acteurs primaires. Ils ne concernent pas les fonctions impliquées. Essayez d'obtenir ce focus et évitez tout ce qui a tendance à être une décomposition fonctionnelle!

Modifier

1. Exactement.
2. Si quelqu'un est là pour le faire, vous avez un acteur et un tel UC (mais il doit être nommé correctement).
3. Cela peut être correct. Que ce soit est correct dépend des exigences du système considéré (ce que vous voulez finalement atteindre)