USE CASE Présentation

Technique importante ● Pilotage par cas d'utilisation (use case) ● Spécifications des besoins fonctionnels des acteurs ● Unité de travail, de lieu ● Technique de modélisation ● Décrit la structure fondamentale de l'application à un niveau élevé d'abstraction ● Informelle et non précise

Cas d'utilisation : pour qui ?(1) ● Les acteurs ● Rôles ● Primaire ● Secondaire ● Types ● Utilisateur ● Autre système

Cas d'utilisation : pour qui ?(2) ● Les acteurs

Cas d'utilisation : pourquoi ?(1) ● Le « quoi » ● Unité de travail ● Unité de livraison ● Pas le « comment » ● Pas une décomposition fonctionnelle ● Pas une vue statique ni dynamique ● Pas orienté objet

Cas d'utilisation : pourquoi ?(2) ● Réduire la complexité ● Partition du futur système ● Factorisation d'utilisations communes (« include ») ● Marginalisation des utilisations exceptionnelles (« extend ») ● Généralisation et spécialisation des niveaux d'abstraction

Relations ● Spécialisation, include, extend

Mode d'emploi (1) ● Etape 1 ● Identifier les acteurs (ceux qui interagissent avec le système) ● Etape 2 ● Choisir un acteur ● Etape 3 ● Définir ce que veut faire cette acteur avec le système ● Chacune de ses volontés devient un cas d'utilisation

Mode d'emploi (2) ● Etape 4 ● Pour chaque cas décider du scénario le plus usuel d'utilisation. Ce qui normalement arrive. C'est le scénario de base. ● Etape 5 ● Décrire le scénario de base de chaque cas d'utilisation : ● « L'acteur fait ceci, le système fait cela » ● A un haut niveau d'abstraction ● Par exemple : ne pas spécifier les IHM

Mode d'emploi (3) Description L'employé saisit le nom du client. Le système affiche tous les clients homonymes. L'employé en choisit un et le système affiche le détail de ce client. Pour chaque item que le client désire commander, l'employé saisit la ligne de détail. Quand toutes les lignes détail ont été entrées, le système confirme la commande. Description L'employé saisit le nom du client. Le système affiche tous les clients homonymes. L'employé en choisit un et le système affiche le détail de ce client. Le système affiche l'historique des paiements du client pour les six derniers mois.

Mode d'emploi (4) ● Etape 6 ● Une fois déterminer le scénario de base, étudier les cas alternatifs et les ajouter au modèle Description Dans le cas d'utilisation « Tester le crédit du client » si le système ne trouve pas de client répondant au nom saisi, il affiche un message d'erreur et permet à l'utilisateur de saisir un nouveau nom.

Mode d'emploi (5) ● Etape7 ● Revoir chaque description de cas d'utilisation et la comparer aux autres. Repérer chaque description commune et la factoriser par un cas d'utilisation en relation « include ». Description L'employé saisit le nom du client. Le système affiche tous les clients homonymes. L'employé en choisit un et le système affiche le détail de ce client.

Mode d'emploi (6) ● Etape 8 ● Répéter les étapes 2 – 7 pour chaque acteur. ● Remarques ● Ce qu'il ne faut pas prendre en compte : ● Les informations détaillées et formelles. Par exemple, le besoin de spécifier des relations entre objets ou que l'acteur dialogue avec le système via une IHM graphique : ➔ Modéliser ces informations avec les autres diagrammes UML. ● Ne pas décomposer (« include », « extend ») à un niveau trop bas.

Les erreurs courantes(1) ● Trop compliqué

Les erreurs courantes(2) ● Les « include » ● Est-ce que les cas : « Calculer marge brute », « Créer commande » et « Ajouter ligne détail » traduisent quelque chose de commun à plusieurs cas ? Non. ➔ Erreur !

Les erreurs courantes(3) ● Le cas « Chercher client » est à la fois référencé par un acteur et par d'autres cas d'utilisation. Mais surtout il y a contradiction car : ● Cas : « Passer une commande » ●L'acteur choisit un client dans la liste affichée par le système. Utilise le cas « Chercher un client ». Le système affiche l'écran de saisie de la commande et l'acteur saisit les items (code et quantité) requis pour chaque ligne. Le système affiche le total de la commande. Une fois la commande terminée l'acteur confirme la commande et le système est prêt pour enregistrer une nouvelle commande. ● Cas : « Chercher client » ●L'acteur choisit un client en entrant son numéro de référence. Le système affiche le détail complet de ce client, nom, adresse etc avec l'historique de ses achats.

Les erreurs courantes(4) ● Complétons le cas « Passer une commande » par l'utilisation (« include ») : ●L'acteur choisit un client dans la liste affichée par le système. L'acteur choisit un client en entrant son numéro de référence. Le système affiche le détail complet de ce client, nom, adresse etc avec l'historique de ses achats. Le système affiche l'écran de saisie de la commande et l'acteur saisit les items (code et quantité) requis pour chaque ligne. Le système affiche le total de la commande. Une fois la commande terminée l'acteur confirme la commande et le système est prêt pour enregistrer une nouvelle commande. ➔ La même tâche est répétée deux fois ! Erreur !

Les erreurs courantes(5) ● Les « extend » ● L'appellation du cas « Créer nouveau client » n'est pas adaptée. Un « extend » décrit une alternative, une exception.

Les erreurs courantes(6) ● Après correction :

Les erreurs courantes(7) ● Plus simplement :

Les erreurs courantes(8) ● Autre erreur :

Les erreurs courantes(9) ● Un cas d'utilisation ne peut traduire à la fois une condition, une exception (« extend ») dans le déroulement d'un cas d'utilisation de base et traduire une utilisation (« include » ) courante, normale d'un autre cas. ➔ Solution : créer un nouveau cas d'utilisation (« Création d'un nouveau client » ) utilisé par les cas « Créer client » et « Client non trouvé ».

Les erreurs courantes(10) ● Cas d'utilisation : « Créer une commande » ● L'acteur choisit un client dans la liste affichée par le système. Le système affiche l'écran de saisie de la commande et l'acteur saisit les items (code et quantité) requis pour chaque ligne. Le système affiche le total de la commande. Une fois la commande terminée l'acteur confirme la commande et le système est prêt pour enregistrer une nouvelle commande. ➔ Attention : éviter de décrire des détails qui imposent trop tôt une solution de conception

Les erreurs courantes(11) ● Solution : ● L'employé choisit un client. Le système demande à l'employé d'entrer le détail de la commande (code de l'item et quantité) et gère le total courant de la commande. Une fois terminé avec la commande, elle est confirmée et le système enregistre la commande confirmée.

Spécialisation ● Le cas d'utilisation « généralisation » ● Définit le squelette du service offert par le système à l'acteur. ● Les cas d'utilisation « spécialisation » ● Réécrivent ou étendent les aspects du squelette général.

Avantages de la spécialisation ● Permet la réutilisation ● Améliore l'extensibilité du système ● Permet de ne pas plonger trop tôt dans les détails

Cas d'utilisation : inscription aux cours 1.L'étudiant demande à s'inscrire aux cours 2.Le système valide l'identité de l'étudiant 3. Partie générale: (a)Le système contrôle le curriculum et liste les cours disponibles (b)L'étudiant choisit ses cours 4.Le système informe l'étudiant que l'inscription est réussie 5.Le système enregistre l'inscription

Cas d'utilisation : inscription aux cours obligatoires 1.L'étudiant demande à s'inscrire aux cours 2.Le système valide l'identité de l'étudiant 3. Partie spécialisée: (a)Le système contrôle le curriculum de l'étudiant et sa matière principale et liste les cours du bloc obligatoire (b)L'étudiant choisit ses cours obligatoires 4.Le système informe l'étudiant que l'inscription est réussie 5.Le système enregistre l'inscription

Cas d'utilisation : inscription aux cours optionnels 1.L'étudiant demande à s'inscrire aux cours 2.Le système valide l'identité de l'étudiant 3. Partie spécialisée: (a)Le système contrôle les cours optionnels disponibles et les liste (b)L'étudiant choisit ses cours optionnels 4.Le système informe l'étudiant que l'inscription est réussie 5.Le système enregistre l'inscription

Remarques ● Les étapes 1,2,4 et 5 sont partagées par tous les cas d'utilisation spécialisés. ● Règles ● Les comportements abstraits qui doivent être remplacés par des spécialisations dans les sous cas d'utilisation ne doivent pas apparaître dans la partie constante. ● Les comportements dans la partie constante du cas général doivent être réutilisés sans modifications dans les cas spécialisés.

Autres représentations ● Table de décisions ● Conditions ● Actions ● Formulaire de cas d'utilisation ● Ordonnancement des scénari ● De base, alternatifs et exceptionnels ● Diagramme d'activité

Table de décision (1) Lorsqu'une personne porteuse d'un chèque d'un des clients de la banque et désireuse de l'encaisser se présente au guichet, l'employé saisit le numéro du compte et le montant du chèque. Si le solde du client est suffisant, le système débite le montant du chèque sur le compte courant du client et la banque honore le chèque. Si le solde est insuffisant et que le client a donné son accord pour que dans ce cas le chèque soit débité sur son compte rémunéré, le système débite le compte rémunéré du client et honore le chèque à condition que le solde soit suffisant. Dans tous les autres cas le système refuse l'opération et la banque refuse d'honorer le chèque.

Table de décision (2)

Formulaire (1) ✔ Cas d'utilisation : « honorer un chèque » ✔ Acteur : employé du guichet ✔ Préconditions : chèque de la banque, dûment rempli et signé ✔ Post-conditions : caisse suffisante pour honorer le chèque ✔ Scénario de base 1. L'employé saisit le numéro du compte et le montant du chèque 2. Le système contrôle que le solde du compte du client est suffisant 3. Le système débite le montant du chèque du compte courant 4. Le système informe l'employé de la réussite de la transaction 5. Fin de la transaction

Formulaire (2) ✔ Scénario alternatif ✔ 2.1 Le système vérifie si le client a donné son accord pour un débit sur son compte rémunéré ✔ 2.2 Le système contrôle que le solde du compte rémunéré est suffisant ✔ 2.3 Le système débite le montant du chèque du compte rémunéré ✔ 2.4 Retour en 4 ✔ Scénarios exceptionnel ✔ Le système informe l'employé de l'échec de la transaction ✔ Retour en 5 ✔ Le système informe l'employé de l'échec de la transaction ✔ Retour en 5

Diagramme d'activité

Conclusion ● Les cas d'utilisation sont fait pour : ● Décrire le futur système d'un point de vue centré sur l'utilisateur (acteur). ● Recueillir les besoins de l'utilisateur à un haut niveau d'abstraction. ● Ils ne sont qu'une petite étape dans le cycle de vie d'un projet.

Bibliographie ●« Object Oriented Software Engineering: A Use Case Driven Approach »Ivar Jacobson. ●« Writing Effective Use Cases » Alistair Cockburn ●Sites web : ● ●