Le diagramme de cas d’utilisation sert à montrer qui utilise le système (les acteurs) et pour faire quoi (les cas d’utilisation). Il donne une vue d’ensemble des fonctionnalités offertes par ton application.

Dans ce cours, on attend de toi un diagramme de cas d’utilisation suffisamment détaillé, qui exploite les relations <<include>> et <<extend>> quand c’est pertinent, et qui montre clairement la frontière de ton système.

Éléments obligatoires sur ton diagramme

• Acteurs : au moins un acteur principal (utilisateur, administrateur, système externe, etc.).
• Cas d’utilisation : plusieurs cas d’utilisation décrivant les grandes fonctionnalités (pas un seul énorme cas « Gérer le système »).
• Frontière du système : un rectangle qui encadre les cas d’utilisation, avec le nom du système.
• Relations acteur–cas : lignes d’association entre acteurs et cas d’utilisation.
• Relations <<include>> pour factoriser un comportement commun à plusieurs cas d’utilisation.
• Relations <<extend>> pour représenter un comportement optionnel ou exceptionnel qui prolonge un cas d’utilisation de base.

Exemple d’exigences pour ton projet

Pour ton projet, ton diagramme de cas d’utilisation devrait au minimum montrer :

• les acteurs principaux (par exemple : Client, Administrateur, Système externe de paiement) ;
• les cas d’utilisation principaux (ex. : S’inscrire, Se connecter, Passer une commande, Consulter son profil) ;
• au moins un <<include>> (par exemple « Authentifier l’utilisateur » inclus dans plusieurs cas) ;
• au moins un <<extend>> (par exemple une gestion d’options avancées ou de cas d’erreur).

Exemple visuel (à adapter à ton projet)

Inspire-toi de la structure, mais adapte les noms d’acteurs et de cas d’utilisation à ton propre projet.

Pièges à éviter

• Un seul cas d’utilisation qui englobe tout (trop vague, pas exploitable).
• Trop de détails techniques dans les noms (reste au niveau métier : « Passer une commande », pas « Appeler API X »).
• Oublier la frontière du système et mélanger ce qui est dans le système avec ce qui est externe.
• Ne jamais utiliser <<include>> ni <<extend>> alors que des comportements communs ou optionnels existent clairement.