Acteur : Entité externe au système qui interagit avec lui. Peut être un utilisateur, un autre système ou un événement externe.
- Analyser le contexte d'utilisation du système
- Identifier les utilisateurs directs du système
- Détecter les systèmes externes avec lesquels il communique
- Relever les événements externes qui déclenchent des actions
- Classer les acteurs par rôle ou type
- Valider la pertinence de chaque acteur
Système de Gestion de Bibliothèque - Acteurs
Lecteur
Bibliothécaire
Système de notification
• Bibliothécaire : Gère les opérations de la bibliothèque
• Administrateur : Configure le système
• Système de paiement : Gère les pénalités
• Système externe : Fournit les données des livres
Comprendre les interactions possibles entre le système et son environnement.
Lister toutes les personnes qui interagissent avec le système.
Identifier les autres systèmes qui communiquent avec le système.
Acteurs identifiés : Lecteur, Bibliothécaire, Administrateur, Système de notification, Système de paiement.
• Extériorité : L'acteur doit être en dehors du système
• Interaction : L'acteur doit interagir avec le système
• Pertinence : L'acteur doit avoir un rôle fonctionnel dans le système
Cas d'usage : Scénario d'interaction entre un acteur et le système pour atteindre un objectif spécifique.
- Identifier les objectifs fonctionnels du système
- Associer chaque objectif à un acteur
- Formuler le cas d'usage en termes d'action
- Préciser les conditions d'utilisation
- Décrire le scénario nominal
- Identifier les scénarios alternatifs
Système de Réservation de Cinéma - Cas d'usage
Client
Gestionnaire
• Réserver place : Sélectionner et réserver un siège
• Payer réservation : Effectuer le paiement
• Annuler réservation : Annuler une réservation existante
• Gérer films : Ajouter/modifier les films
• Gérer tarifs : Définir les prix des places
• Générer rapports : Statistiques des ventes
Déterminer les buts fonctionnels que le système doit atteindre.
Lier chaque objectif à l'acteur qui l'initie.
Exprimer chaque cas d'usage comme une action claire.
Cas d'usage définis : Rechercher séance, Réserver place, Payer réservation, Gérer séances, Annuler réservation.
• Objectif clair : Chaque cas d'usage doit avoir un objectif bien défini
• Complétude : Tous les objectifs fonctionnels doivent être couverts
• Indépendance : Les cas d'usage doivent être relativement indépendants
Relation : Lien entre un acteur et un cas d'usage indiquant que l'acteur participe à l'interaction.
- Identifier les acteurs concernés par chaque cas d'usage
- Établir les relations d'association
- Préciser le rôle de chaque acteur
- Identifier les relations d'inclusion et d'extension
- Documenter les contraintes de relation
- Valider la cohérence du modèle
Système de Commande en Ligne - Relations
Client
Gestionnaire
Transporteur
• Include (<
• Extend (<
• Généralisation : Héritage entre acteurs ou cas d'usage
• Commander produit → Payer commande : Include
• Commander produit → Consulter catalogue : Association
• Gestionnaire → Gérer stock : Association
• Transporteur → Livrer commande : Association
Lier chaque acteur aux cas d'usage qu'il initie.
Repérer les cas d'usage qui dépendent d'autres cas.
Représenter les relations Include et Extend.
Relations établies entre acteurs et cas d'usage : associations directes, relations d'inclusion et d'extension.
• Direction : Les relations partent de l'acteur vers le cas d'usage
• Clarté : Les relations Include et Extend doivent être bien identifiées
• Cohérence : Toutes les relations doivent être logiques et nécessaires
Relation Include : Lien entre deux cas d'usage indiquant qu'un cas d'usage inclut toujours un autre cas d'usage.
- Identifier les parties communes à plusieurs cas d'usage
- Extraire ces parties dans un cas d'usage séparé
- Créer la relation <
> vers ce cas d'usage - Spécifier la condition d'inclusion
- Documenter la relation
- Valider la modularité
Système de Gestion de Parking - Inclusion
| Cas d'usage | Type | Description | Inclusion |
|---|---|---|---|
| Enregistrer véhicule | Principal | Enregistre l'entrée d'un véhicule | Authentification utilisateur |
| Calculer tarif | Principal | Calcule le montant à payer | Valider badge |
| Libérer place | Principal | Libère une place de parking | Authentification utilisateur |
| Consulter historique | Principal | Affiche l'historique des passages | Authentification utilisateur |
• Réutilisable : Le cas d'usage inclus peut être utilisé par plusieurs autres
• Modulaire : Permet de réduire la duplication de code/logique
• Non inversible : Le cas d'usage inclus ne dépend pas du cas principal
Rechercher les fonctionnalités partagées entre plusieurs cas d'usage.
Créer un nouveau cas d'usage pour les parties communes.
Établir la relation <
Documenter clairement la relation et son objectif.
Relations d'inclusion créées : Authentification utilisateur incluse dans plusieurs cas d'usage principaux.
• Obligation : Le cas d'usage inclus est toujours exécuté
• Direction : La relation va du cas principal vers le cas inclus
• Modularité : Favorise la réutilisation et la lisibilité
Relation Extend : Lien entre deux cas d'usage indiquant qu'un cas d'usage peut étendre un autre cas d'usage dans certaines conditions.
- Identifier les cas d'usage optionnels ou conditionnels
- Déterminer les points d'extension dans le cas principal
- Créer le cas d'usage étendu
- Spécifier la condition d'extension
- Établir la relation <
> vers le cas principal - Documenter les conditions d'activation
Système de Gestion Bancaire - Extension
| Cas d'usage | Type | Condition | Point d'extension |
|---|---|---|---|
| Retirer argent | Principal | Solde insuffisant | Vérification solde |
| Notifier découvert | Étendu | Solde < 0 | Fin transaction |
| Calculer intérêts | Étendu | Fin de mois | Fin mois |
| Bloquer carte | Étendu | 3 tentatives échouées | Échec authentification |
• Optionnel : L'exécution n'est pas obligatoire
• Point d'extension : Moment spécifique dans le cas principal
• Inverse : Le cas étendu part du cas principal vers le cas étendu
Rechercher les fonctionnalités optionnelles ou conditionnelles.
Identifier les moments dans le cas principal où l'extension peut intervenir.
Créer les cas d'usage qui étendent le comportement principal.
Définir les conditions qui déclenchent l'exécution de l'extension.
Relations d'extension créées : Notifier découvert, Calculer intérêts, Bloquer carte avec conditions d'activation spécifiques.
• Optionnalité : Le cas d'usage étendu n'est pas toujours exécuté
• Condition : L'extension dépend d'une condition spécifique
• Direction : La relation va du cas étendu vers le cas principal
- Granularité : Garder les cas d'usage à un niveau d'abstraction cohérent
- Clarté : Nommer les cas d'usage avec des verbes d'action
- Complétude : Couvrir tous les besoins fonctionnels du système
- Simplicité : Éviter les relations trop complexes entre les cas d'usage
- Un acteur ne peut pas interagir directement avec un autre acteur
- Les relations Include sont obligatoires, les relations Extend sont conditionnelles
- Un cas d'usage ne peut pas inclure un cas d'usage qui l'inclut (boucle interdite)
- Les cas d'usage doivent être indépendants et complets
- Acteur principal : Celui qui initie le cas d'usage
- Acteur secondaire : Celui qui fournit des informations au système
- Scénario nominal : Chemin principal d'exécution d'un cas d'usage
- Scénarios alternatifs : Chemins de déviation dus à des exceptions ou erreurs
