Diagramme comportemental — Besoins
Diagramme de
Cas d'utilisation
Capture les besoins fonctionnels d'un système du point de vue des utilisateurs. Répond à : "Que doit faire le système ?"
Rôle du Diagramme
Le diagramme de cas d'utilisation est le premier diagramme à produire dans un projet : il décrit quoi fait le système, pas comment.
Chaque cas d'utilisation correspond à un objectif utilisateur : "Se connecter", "Passer une commande", "Générer un rapport". Évitez les cas trop techniques.
Éléments du Diagramme
| Élément | Notation | Rôle |
|---|---|---|
| Acteur | Entité externe qui interagit avec le système : personne, organisation ou autre système | |
| Cas d'utilisation | Fonctionnalité offerte par le système — une ellipse avec un nom sous forme verbale | |
| Frontière système | Rectangle (ou rectangle en pointillés) délimitant le périmètre du système | |
| Association | Ligne simple entre acteur et cas d'utilisation — indique la participation |
Acteurs
Un acteur est toujours externe au système. Il représente un rôle, pas une personne spécifique.
«système»"Client" et "Administrateur" sont des acteurs. "Jean Dupont" non — c'est une instance. Un acteur correspond à un rôle.
Si Gestionnaire hérite de Utilisateur, le Gestionnaire peut aussi effectuer tous les cas d'utilisation du parent.
Cas d'utilisation
Un cas d'utilisation décrit une interaction complète entre un acteur et le système pour atteindre un objectif.
Fiche d'un cas d'utilisation
Relations entre Cas
Trois types de relations permettent de structurer les cas d'utilisation.
«include» et «extend» en détail
«include» — Inclusion obligatoire
Le cas de base délègue toujours une partie de son comportement au cas inclus. La flèche pointe vers le cas inclus.
«extend» — Extension optionnelle
Le cas d'extension ajoute un comportement optionnel au cas de base, selon une condition. La flèche pointe vers le cas de base.
{ }Astuce mémo-technique : «include» = le cas inclus est toujours exécuté (obligatoire). «extend» = le cas extension s'ajoute parfois (optionnel). La flèche «extend» pointe vers le cas de base (celui qui est étendu).
Types d'Acteurs
Les acteurs se distinguent selon leur rôle dans l'interaction et leur nature (humain ou système).
| Type | Description | Placement | Exemple |
|---|---|---|---|
| Acteur principal | Initie l'interaction pour atteindre un objectif | À gauche de la frontière | Client qui passe commande |
| Acteur secondaire | Répond à une demande ou fournit un service au système | À droite de la frontière | Système bancaire validant la transaction |
| Acteur humain | Personne interagissant directement avec le système | Gauche ou droite selon son rôle | Membre d'une bibliothèque |
| Acteur système | Autre système ou application interagissant avec le système modélisé — stéréotype «système» |
Souvent à droite | Système de paiement externe |
Niveaux de Granularité
Les cas d'utilisation peuvent être modélisés à différents niveaux de détail selon l'audience et le stade du projet.
Résumé
Vue très abstraite couvrant un processus métier complet. Destiné à la direction ou aux parties prenantes non techniques.
Utilisateur
Niveau standard : décrit une tâche complète du point de vue de l'utilisateur. Base pour les tests et les spécifications.
Sous-fonction
Détaille une étape spécifique. Souvent inclus via «include» dans un cas de niveau utilisateur. Évite la répétition.
En pratique : utilisez le niveau Résumé pour cadrer le projet avec les clients, le niveau Utilisateur pour rédiger les spécifications, et le niveau Sous-fonction pour factoriser les comportements partagés via «include».
Description Textuelle
Le diagramme seul ne suffit pas : chaque cas important doit être accompagné d'une fiche textuelle détaillant le scénario complet.
La description textuelle est le véritable contrat fonctionnel entre les parties prenantes. Elle répond aux questions : qui, quand, comment, et que se passe-t-il en cas d'erreur.
Un diagramme de séquence (Chapitre 4) est souvent la meilleure façon d'illustrer le scénario nominal d'une description textuelle.
Erreurs Courantes
Connaître les pièges fréquents permet de produire des diagrammes plus lisibles et plus utiles.
Un acteur représente un rôle, pas une personne. "Marie" n'est pas un acteur — "Client" l'est. Une même personne peut jouer plusieurs rôles.
Modéliser chaque sous-étape comme un cas indépendant rend le diagramme illisible. Utilisez «include» pour factoriser les étapes communes.
Sans frontière, on ne sait pas ce qui est dans le périmètre. Toujours délimiter le système, même pour un diagramme simple.
La flèche «extend» pointe vers le cas de base (celui qui est étendu), pas vers l'extension. C'est souvent inversé par erreur.
Un diagramme sans fiche textuelle est incomplet. Les scénarios alternatifs et les préconditions sont essentiels pour éviter les malentendus.
Éviter "Appeler l'API REST" ou "Écrire en base de données". Un cas d'utilisation doit correspondre à un objectif utilisateur, pas à une implémentation.
Frontière Système
La frontière système est un rectangle qui délimite ce qui est dans le système et ce qui est en dehors.
La frontière aide à identifier ce qui est en scope (dans le projet) et ce qui est hors scope. C'est un outil de cadrage essentiel.
Exemple Complet — Bibliothèque en ligne
Diagramme complet avec acteurs hiérarchisés, include, extend et frontière système.
Résumé
🎭 Acteurs
| Principal | initie, à gauche |
| Secondaire | sollicité, à droite |
| «système» | système externe |
| Héritage | spécialisation |
📦 Cas d'utilisation
| Ellipse | un cas |
| Verbe inf. | nommage |
| Rectangle | frontière |
| Ligne | association |
🔗 Relations
| «include» | obligatoire, vers inclus |
| «extend» | optionnel, vers base |
| Généralisa. | triangle creux |
✅ Bonnes pratiques
| Verbe | nommer les cas |
| Rôle | nommer les acteurs |
| Objectif | 1 cas = 1 but |
| Granularité | ni trop fin ni trop large |