Cas d'utilisation & DSS
Le modèle du domaine disait de quoi le métier parle. Celui-ci dit ce que le système doit savoir faire — d'abord raconté comme une histoire, puis réduit à la liste exacte des événements que le système reçoit. C'est cette traduction qui est le vrai sujet du module.
Un cas d'utilisation est une histoire : un acteur veut quelque chose, il s'adresse au système, et à la fin il l'obtient. Un DSS est la même histoire dont on a effacé tout ce qui n'est pas un franchissement de frontière — il ne reste que les messages qui entrent dans le système et ceux qui en sortent.
Les deux se lisent ensemble et dans cet ordre, parce que le second se déduit du premier presque mécaniquement. Et le résultat de cette déduction — la liste des opérations système — est exactement ce que la conception recevra en entrée. C'est le point de bascule entre « comprendre » et « construire ».
De quoi le système doit-il être capable
Un client dit : « je veux un système de réservation de salles ». C'est une phrase, et il faut en tirer une liste de fonctionnalités. Que doit faire le système, exactement ? Réserver, oui — mais est-ce que ça inclut chercher les créneaux libres ? Recevoir une confirmation ? Modifier sa réservation ? Annuler ? Prêter sa réservation à un collègue ?
Le cas d'utilisation répond à ça, et il le fait d'une façon particulière qui est tout son intérêt : du point de vue de celui qui s'en sert, et non de celui qui le construit. Il ne décrit ni écrans, ni boutons, ni tables — il décrit un objectif atteint.
Le client commande une entrée, un plat et un dessert. Sa commande dit ce qu'il veut obtenir ; elle ne dit rien de la cuisine — ni dans quel ordre le chef s'y prend, ni quelle poêle il emploie, ni s'il délègue le dessert.
Un cas d'utilisation est cette commande. La cuisine, ce sera la conception. Et comme au restaurant, la seule chose qui compte pour juger la commande, c'est qu'elle décrive un résultat que le client peut constater.
C'est aussi ce qui explique la place de ce diagramme dans le processus. Le module précédent l'annonçait : le processus unifié est piloté par les cas d'utilisation. On ne planifie pas un projet par couches techniques mais par objectifs d'utilisateur, précisément parce qu'un objectif atteint se démontre et se juge, alors qu'une couche ne se montre à personne.
Les acteurs sont des rôles, pas des personnes
Un acteur est une entité extérieure au système qui interagit avec lui pour atteindre un objectif. Trois sortes, et la troisième surprend : un humain (caissier, usager), un autre système (une passerelle de paiement, un service d'authentification), ou un périphérique — y compris l'horloge, quand le système doit faire quelque chose à heure fixe.
On distingue l'acteur principal, qui déclenche le cas d'utilisation pour atteindre son objectif, et l'acteur secondaire, dont le système se sert pour aller au bout. Le caissier est principal ; le service de paiement, qu'on interroge en cours de route, est secondaire.
Retiens surtout ceci, parce que c'est ce qui se rate : un acteur est un rôle, pas une personne. Marie est caissière le matin et gérante l'après-midi — deux rôles, donc deux acteurs, et le système ne connaît qu'eux. Inversement, trois personnes différentes qui font la même chose ne font qu'un acteur. La question à se poser n'est jamais « qui ? » mais « en tant que quoi ? ».
Comment les trouver ? Trois questions passées sur l'énoncé, dans cet ordre. Qui déclenche ? — cherche les sujets des verbes d'action (« l'usager emprunte », « le bibliothécaire inscrit »). À qui le système parle-t-il ? — cherche « le système vérifie auprès de », « envoie à », « interroge ». Qu'est-ce qui se produit tout seul ? — cherche « automatiquement », « chaque nuit », « la veille de ». La troisième est celle qu'on oublie, et elle donne presque toujours l'horloge.
Derrière la notion d'acteur se cache la décision la plus structurante de tout le module : où passe la frontière du système ? Est « acteur » tout ce qui est dehors — et c'est toi qui décides de ce qui est dedans. Dans un système de bibliothèque, le service d'identification du gouvernement est clairement dehors. Mais le portique antivol à l'entrée ? Le lecteur de codes-barres ? Selon que tu les places dedans ou dehors, ils deviennent des acteurs ou disparaissent du diagramme.
Il n'y a pas de bonne réponse universelle ; il y a une bonne pratique : trace la frontière au périmètre de ce que ton équipe va construire. Ce que vous écrivez est dedans, ce que vous appelez est dehors. C'est aussi ce qui rend la frontière discutable avec le client — et cette discussion vaut mieux que la découvrir au troisième mois.
Oublier les acteurs non humains. On dessine les gens, on oublie les machines — et pourtant une passerelle de paiement, un service d'identification externe ou une base de données d'un autre ministère sont des acteurs à part entière : ils sont hors du système et le système leur parle.
Le réflexe de diagnostic : relis ton énoncé en cherchant les verbes « le système vérifie auprès de… », « le système envoie à… », « automatiquement, chaque nuit… ». Chacun désigne un acteur secondaire que tu n'as probablement pas dessiné — le dernier étant l'horloge.
Le cas d'utilisation, et le problème de sa taille
Un cas d'utilisation décrit une séquence d'interactions entre un ou plusieurs acteurs et le système, permettant à l'acteur principal d'atteindre un objectif observable.
Les deux derniers mots portent tout le poids, et ils servent de test. Un bon cas d'utilisation se termine par quelque chose que l'acteur constate : « commande passée », « livre emprunté », « rapport généré ». Si à la fin de ton scénario personne dans le monde réel ne peut dire « voilà, c'est fait », ce n'est pas un cas d'utilisation.
Le vrai problème n'est pourtant pas là : c'est la taille. Presque toutes les fautes d'examen sur ce point sont des cas d'utilisation trop fins ou trop gros, et les deux erreurs ont des symptômes distincts.
Le cas d'utilisation qui décrit l'interface. « Saisir le formulaire », « Afficher la liste », « Ouvrir la fenêtre » — ce sont des interactions, pas des objectifs, et elles enferment la conception avant même qu'elle commence : un cas d'utilisation qui parle de fenêtres interdit une version mobile sans qu'on l'ait décidé.
Le réflexe : chaque titre commence par un verbe à l'infinitif, et se termine par un résultat. Puis pose la question de l'ascenseur — si l'acteur devait raconter sa journée, dirait-il cette phrase ? On dit « j'ai emprunté un livre », jamais « j'ai saisi le formulaire d'emprunt ».
Parmi ces cinq propositions, lesquelles sont de vrais cas d'utilisation ?
(A) Se connecter
(B) Cliquer sur le bouton « Rechercher »
(C) Emprunter un livre
(D) Gérer la bibliothèque
(E) Sauvegarder la base de données chaque nuit(C) sûrement, (A) et (E) discutablement, (B) et (D) non.
(C) est le modèle du genre : verbe à l'infinitif, objectif observable, scénario racontable.
(B) est un geste d'interface ; (D) est une famille d'objectifs dont on ne peut pas écrire le scénario.
(A) « Se connecter » est le cas qui se discute, et l'examen aime
ça. C'est bien un objectif observable, mais il est rarement une fin en
soi : personne ne se connecte pour se connecter. Il devient donc presque
toujours un cas d'utilisation inclus par les autres — on y revient dans la
section sur include.
(E) est un vrai cas d'utilisation, et il surprend parce qu'aucun humain ne le déclenche. Son acteur principal est l'horloge. C'est exactement le cas que la section sur les acteurs annonçait.
Le descriptif : le format qui fait foi
Le diagramme de cas d'utilisation — des ovales, des bonshommes, un cadre — ne contient presque aucune information. Il donne la liste des fonctionnalités et rien de plus. Tout ce qui compte est dans le descriptif textuel, et c'est lui que l'examen demande d'écrire.
Le descriptif en six lignes
Nom : un VERBE à l'infinitif + son complément
Acteur principal : qui déclenche, et pour quel objectif
Préconditions : ce qui est VRAI avant qu'on commence
Garanties (succès) : ce qui sera VRAI à la fin, si tout va bien
Scénario principal : les étapes numérotées, quand TOUT va bien
Extensions : 3a, 5a… — les variantes, rattachées à leur étapeLe format de Larman, celui que le cours emploie. On l'écrit pour chaque cas d'utilisation retenu ; on le reconnaît au fait que les deux dernières lignes pèsent plus que les quatre premières réunies.
Chaque champ existe pour une raison, et les connaître évite de les remplir au hasard. Les préconditions disent ce qu'on ne vérifiera pas dans le scénario : écrire « caissier authentifié » dispense de raconter l'authentification. Les garanties en cas de succès sont le contrat — c'est la phrase qu'on relira pour savoir si le système fait ce qu'il a promis, et c'est souvent elle qui devient un test.
Le scénario principal, lui, obéit à une règle qu'on oublie systématiquement : tout s'y passe bien. Aucune erreur, aucun refus, aucune annulation. On l'appelle parfois le « chemin heureux », et il doit se lire d'une traite. Chaque étape alterne acteur et système — l'acteur fait quelque chose, le système répond — et l'ensemble tient en une dizaine de lignes.
Voici celui du cours, sur l'emprunt d'un livre. Lis-le en remarquant qu'aucune ligne ne parle d'écran ni de bouton.
Nom : Emprunter un livre
Acteur principal : Usager
Préconditions : l'usager est inscrit et n'a aucune amende impayée
Garanties : un emprunt est enregistré, liant l'usager au livre,
avec sa date de retour prévue
Scénario principal
1. L'usager présente sa carte et le livre.
2. Le système identifie l'usager.
3. Le système vérifie qu'il est en règle.
4. Le système identifie le livre.
5. Le système vérifie que le livre est disponible.
6. Le système enregistre l'emprunt et calcule la date de retour.
7. Le système confirme à l'usager.Le chemin heureux, et rien d'autre : ni amende impayée, ni livre déjà sorti. Ces deux-là sont des extensions.
Un dernier point que les cours passent souvent : on n'écrit pas tous les descriptifs au même niveau de détail, et Larman en distingue trois. Le bref tient en deux phrases — un résumé du scénario, rien de plus. L' informel raconte en un paragraphe, extensions comprises, sans numéroter. Le détaillé est celui de la formule ci-dessus, avec ses six lignes et ses étapes numérotées.
Le choix se fait au coût : un projet a souvent vingt cas d'utilisation, et en détailler vingt coûte des semaines pour un bénéfice décroissant. On détaille les plus risqués et les plus fréquents — ceux dont on n'est pas sûr, et ceux qui feront tourner le système tous les jours — et on laisse les autres en bref. C'est la même logique que le processus unifié applique aux phases : l'effort va là où l'incertitude est.
À l'examen, on demande évidemment le détaillé. Mais savoir que les trois existent est ce qui distingue une réponse apprise d'une réponse comprise.
Ce descriptif contient trois fautes de forme. Lesquelles ?
Nom : Gestion des emprunts
Acteur principal : Marie Tremblay
Scénario principal
1. L'usager clique sur le bouton « Emprunter ».
2. Le système affiche la fenêtre de saisie.
3. Si l'usager a une amende, le système refuse.
4. Sinon, le système enregistre l'emprunt.Le nom n'est pas un verbe à l'infinitif, et il désigne une famille d'objectifs plutôt qu'un objectif. « Gestion des emprunts » ne se raconte pas ; « Emprunter un livre » si.
L'acteur est une personne, pas un rôle. Marie Tremblay n'est pas un acteur ; « Usager » l'est.
Le scénario principal contient une condition — le « si… sinon » de l'étape 3. Le chemin heureux ne bifurque jamais : le cas de l'amende impayée est une extension, numérotée d'après l'étape qu'elle interrompt.
Une quatrième chose se discute : les étapes 1 et 2 parlent d'un bouton et d'une fenêtre. Ce n'est pas une faute de forme mais une faute de niveau — et elle est tout aussi grave, puisqu'elle décide de l'interface avant qu'on ait compris le besoin.
Les extensions, là où tout se joue
Une extension décrit ce qui se passe quand une étape du scénario
principal ne se déroule pas comme prévu. Elle porte le numéro de l'étape concernée suivi
d'une lettre — 3a, 3b, 5a — et cette numérotation
n'est pas cosmétique : elle rattache la variante à son point de départ.
C'est la partie que les étudiants bâclent, et c'est la plus utile des deux. Un scénario principal se devine ; les extensions, non. Elles contiennent les vraies questions à poser au client, et ce sont elles qui font découvrir les règles du métier qu'on n'avait pas vues.
Extensions
3a. L'usager n'est pas en règle.
1. Le système refuse l'emprunt.
2. Le système indique le montant à régler.
→ le cas d'utilisation se termine en échec.
5a. Le livre est déjà emprunté.
1. Le système propose de le réserver.
2. L'usager accepte : le système l'inscrit sur la liste d'attente.
→ reprise au point 1 pour un autre livre, ou fin.Chaque extension dit où elle s'accroche, ce qui se passe, et surtout où l'on repart — reprise à une étape, ou fin du cas d'utilisation.
Trois choses à ne pas rater. Une extension dit toujours comment ça se
termine — reprise à l'étape N, ou échec. Sans ça, le lecteur reste en l'air.
Elle décrit une situation, pas une erreur technique : « l'usager n'est
pas en règle » est une règle du métier, « la base de données ne répond
pas » est un problème d'implémentation qui n'a rien à faire ici. Et
plusieurs extensions peuvent viser la même étape, d'où les lettres —
5a, 5b, 5c.
Reste à savoir comment les trouver, parce qu'elles ne se devinent pas. La méthode est mécanique : reprends le scénario principal étape par étape, et pose sur chacune les trois mêmes questions.
Et si l'acteur ne pouvait pas ? — carte perdue, droit expiré, quota atteint. Et si le système ne pouvait pas ? — article indisponible, salle déjà réservée, paiement refusé. Et si l'acteur voulait autre chose ? — annuler, revenir en arrière, choisir un autre mode.
Sept étapes multipliées par trois questions font vingt-et-une occasions de découvrir une règle du métier. La plupart ne donneront rien ; deux ou trois donneront une question qu'il faut poser au client, et c'est le meilleur rendement de tout le travail d'analyse. Une copie d'examen qui présente trois extensions bien rattachées vaut mieux qu'une qui présente un scénario principal de vingt lignes.
Deux de ces quatre lignes n'ont rien à faire dans les extensions de « Emprunter un livre ». Lesquelles, et pourquoi ?
(A) 2a. La carte de l'usager est illisible.
(B) 4a. Le serveur de la base de données est hors service.
(C) 6a. L'usager a déjà atteint sa limite de cinq emprunts.
(D) 7a. L'écran de confirmation ne s'affiche pas correctement.(B) et (D), pour la même raison de fond : ce sont des défaillances techniques, pas des situations du métier. Un cas d'utilisation décrit ce que le système doit faire, pas ce qui arrive quand il tombe en panne — la robustesse est traitée ailleurs, par les exigences non fonctionnelles.
(D) ajoute une seconde faute : il parle d'un écran. Aucun descriptif ne devrait contenir ce mot.
(A) et (C) sont bonnes, et (C) est même la plus précieuse : la limite de cinq emprunts est une règle du métier que le scénario principal ne mentionnait pas. C'est exactement pour la faire apparaître que l'on écrit les extensions.
include et extend, et le sens des flèches
Deux relations lient des cas d'utilisation entre eux, et elles se confondent à chaque session. La différence de sens est simple ; la différence de direction de la flèche l'est beaucoup moins, et c'est là que les points se perdent.
« include » factorise ce qui est toujours exécuté : le cas de base ne peut pas se dérouler sans le cas inclus. On s'en sert quand plusieurs cas d'utilisation partagent la même sous-séquence — s'authentifier, calculer un total, vérifier une identité.
« extend » décrit ce qui n'arrive que parfois : le cas de base se déroule très bien tout seul, et l'extension vient s'y insérer dans certaines conditions. Appliquer un code de réduction, choisir une option, demander une facture.
include, elle y arrive
pour l'extend. La règle qui décide est unique — la flèche part
toujours de celui qui connaît l'autre. Le cas de base connaît ce
qu'il inclut ; il ignore en revanche ce qui l'étend, sans quoi l'extension ne
serait pas optionnelle.
Inverser la flèche d'« extend ». On raisonne « Payer est étendu par le code promo », on trace donc la flèche depuis Payer. C'est faux, et c'est l'erreur la plus courante des deux.
Le réflexe qui l'attrape : demande-toi lequel des deux pourrait être supprimé
sans toucher à l'autre. Le code promo peut disparaître, Payer continue de
fonctionner — donc Payer ne le connaît pas, donc la flèche part du code promo. Pour
include, c'est l'inverse : retire l'authentification, et Payer ne
veut plus rien dire.
Pour chaque paire, dis s'il s'agit d'un include ou d'un
extend, et d'où part la flèche.
(A) « Payer » et « S'authentifier »
il faut toujours s'authentifier avant de payer.
(B) « Acheter en ligne » et « Offrir un rabais »
le rabais est appliqué quand l'utilisateur y a droit.
(C) « Réserver une chambre » et « Choisir le petit-déjeuner »
l'option est proposée, elle n'est pas obligatoire.
(D) « Emprunter un livre » et « Retourner un livre »
on emprunte, puis on retourne.Voir le corrigé
(A) include, flèche depuis « Payer ». C'est obligatoire, et le cas de base en dépend.
(B) extend, flèche depuis « Offrir un rabais ». L'achat fonctionne très bien sans.
(C) extend, flèche depuis « Choisir le petit-déjeuner ». Même raisonnement.
(D) ni l'un ni l'autre, et c'est le piège de l'exercice. Ce sont deux cas d'utilisation indépendants, séparés dans le temps et souvent de plusieurs jours. Une succession chronologique n'est pas une relation UML : on ne relie deux cas d'utilisation que si l'un a besoin de l'autre pour se dérouler.
Du cas d'utilisation au DSS
Le diagramme de séquence système — le DSS — montre les événements échangés entre les acteurs et le système, celui-ci étant traité comme une boîte noire, pour un scénario précis d'un cas d'utilisation.
« Boîte noire » est le mot décisif, et il définit tout ce qui peut y figurer.
On ne voit qu'un seul rectangle nommé Système : pas de classes, pas de
contrôleurs, pas de base de données. Rien de ce qui se passe à l'intérieur n'apparaît,
parce qu'à ce stade on ne l'a pas encore décidé — et c'est justement ce qu'on ne veut pas
préjuger.
La construction est presque mécanique : on prend le scénario principal du descriptif, et on ne garde que les lignes où quelque chose franchit la frontière. Une action de l'acteur vers le système devient une flèche entrante ; une réponse du système devient une flèche sortante, en pointillé. Les lignes qui décrivent un traitement interne — « le système vérifie… » — disparaissent : elles se passent dans la boîte.
-
usager
présente sa carte et le livre
franchit la frontière →
identifierUsager(carte) - système identifie l'usager, vérifie qu'il est en règle traitement interne — ne franchit rien, n'apparaît PAS
-
système
répond que l'usager est en règle
franchit la frontière → retour
statut -
usager
présente le livre à emprunter
franchit la frontière →
identifierLivre(codeBarre) - système vérifie que le livre est disponible traitement interne — n'apparaît PAS
-
système
enregistre l'emprunt et confirme
franchit la frontière → retour
dateRetour
Faire de la conception dans le DSS. On dessine
ControleurEmprunt, GestionnaireUsager, une base de données —
et le diagramme cesse d'être un DSS. Il est devenu un diagramme de séquence ordinaire,
avec plusieurs mois d'avance.
Le symptôme est mécanique et se repère d'un coup d'œil : compte les
rectangles. Un DSS n'en a qu'un seul — Système. Dès qu'il y en a
deux, tu as ouvert la boîte, et tu as pris des décisions de conception au moment où tu
étais censé décrire un besoin.
Les opérations système
Une opération système est une méthode publique du système, vu comme boîte noire, déclenchée par un événement d'acteur. La règle qui la définit est d'une simplicité mécanique : chaque flèche entrante du DSS est une opération système. Il n'y a rien à interpréter, il suffit de les relever.
Sur l'exemple de l'emprunt, la liste tient en trois lignes :
identifierUsager(carte), identifierLivre(codeBarre),
enregistrerEmprunt(). Chacune est nommée par un verbe, et porte les
paramètres que l'acteur fournit vraiment — pas ceux dont le système aura besoin en
interne.
Et c'est ici que le module prend tout son sens. Cette liste n'est pas un sous-produit du diagramme : c'est le contrat que la conception devra réaliser. Chacune de ces opérations devra être attribuée à une classe, puis détaillée par un diagramme de séquence qui montre quels objets collaborent pour l'exécuter. Tout ce qu'on fera ensuite part de là.
Deux règles de nommage, qui se ratent souvent. La première : une opération porte
les paramètres que l'acteur fournit, pas ceux dont le système aura
besoin en interne. identifierLivre(codeBarre) est juste — l'usager présente
un code-barre. identifierLivre(idLivre, idBibliotheque, session) ne l'est
pas : l'usager ne fournit rien de tout ça, et ces paramètres viennent de décisions
de conception qu'on n'a pas encore prises.
La seconde : le nom décrit ce que l'acteur demande, pas ce que le
système fera pour l'exécuter. enregistrerEmprunt() plutôt que
insererLigneDansTableEmprunts(). Le test : si le nom de l'opération
survivrait à un changement complet de technologie, il est bon.
Mets bout à bout les trois premiers modules et tu obtiens une chaîne qui ne se rompt pas. Le modèle du domaine donne les concepts et leur vocabulaire. Le cas d'utilisation dit ce que l'acteur veut obtenir. Le DSS réduit cette histoire aux événements qui franchissent la frontière. Les opérations système en tombent, une par flèche entrante.
La suite du cours ne fait que continuer : les diagrammes d'interaction montreront quels objets réalisent chaque opération, les principes de conception diront à quelle classe confier chacune, et le diagramme de classes rassemblera le tout. Chaque module reprend la sortie du précédent — c'est aussi l'ordre des livrables du projet de session, et ce n'est pas une coïncidence.
La chaîne complète, sur un exemple
Reprenons le tout sur un énoncé neuf, en déroulant les quatre étapes dans l'ordre. C'est exactement la forme de la question d'examen la plus longue, et celle du livrable d'analyse.
Identifie les acteurs et les cas d'utilisation de cette description.
« Dans une bibliothèque, un usager peut consulter le catalogue, emprunter
et retourner des livres. Un bibliothécaire gère le catalogue, inscrit les
nouveaux usagers et applique des amendes. Le système se connecte à un
service externe pour vérifier l'identité d'un nouvel usager, et envoie
automatiquement un rappel la veille de chaque échéance. »Voir le corrigé
Acteurs principaux : Usager, Bibliothécaire — et Horloge, pour le rappel automatique que personne ne déclenche.
Acteur secondaire : le Service d'identification externe. Le système s'en sert ; il ne déclenche rien.
Cas d'utilisation : Consulter le catalogue, Emprunter un livre, Retourner un livre (Usager) ; Gérer le catalogue, Inscrire un usager, Appliquer une amende (Bibliothécaire) ; Envoyer un rappel (Horloge).
Et une relation : « Inscrire un usager »
include « Vérifier l'identité », puisque la vérification a
lieu à chaque inscription. La flèche part d'« Inscrire un usager ».
Le point qui distingue une bonne copie : avoir vu l'horloge. Le mot automatiquement de l'énoncé est le seul indice, et il suffit.
Voici un DSS proposé pour « Retourner un livre ». Relève ce qui ne va pas.
Usager ──▶ Système : scannerLivre(codeBarre)
Système ──▶ BaseDeDonnees : chercherEmprunt(codeBarre)
Système ──▶ Usager : afficherEcranConfirmation()
Système ──▶ ServiceAmende : calculerRetard(emprunt)Trois fautes, et la première les explique toutes.
Il y a quatre rectangles. BaseDeDonnees et
ServiceAmende sont des éléments internes du système : on a
ouvert la boîte noire. Un DSS n'a qu'un seul rectangle système. Ces deux lignes
n'existent pas à ce niveau — elles apparaîtront dans le diagramme de séquence
détaillé, plus tard.
afficherEcranConfirmation() parle d'interface. Un
message sortant décrit ce que le système rend —
montantAmende ou confirmation —, jamais comment il
l'affiche.
Il ne reste donc qu'une seule opération système,
scannerLivre(codeBarre), plus son retour. Et c'est probablement correct
pour ce cas d'utilisation : retourner un livre, c'est un geste.
Cette matière est celle des semaines 2 et 3, évaluée à l'examen intra du 24 octobre — la révision de la semaine 7 porte sur les modules 1 à 5 du cours, dont celui-ci. Elle complète le livrable d'analyse avec le modèle du domaine. C'est la partie du livrable qui demande le plus d'écriture : un descriptif par cas d'utilisation retenu, et un DSS par scénario principal.
IFT-2007 n'autorise aucun matériel. Le format du descriptif doit
s'écrire de mémoire, dans l'ordre, et la règle de direction des flèches
include / extend doit être acquise — c'est un point que le
correcteur vérifie en un coup d'œil.
« Rédigez le descriptif du cas d'utilisation X. »
Les six lignes, dans l'ordre, sans en sauter. Le scénario principal ne contient que le chemin heureux — y glisser un « si l'usager n'est pas en règle » est la faute classique, et elle coûte deux fois : une pour le scénario, une pour les extensions qu'on n'a alors plus rien à mettre. Chaque extension porte le numéro de son étape et dit où l'on repart.
« Quelle est la différence entre « include » et « extend » ? »
include est toujours exécuté et sert à factoriser ;
extend ne l'est que parfois et sert à décrire une variation. Ajoute la
direction, qui est ce qui distingue une réponse complète : la flèche part
toujours de celui qui connaît l'autre — du cas de base pour include, de
l'ajout pour extend.
« Combien d'objets un DSS contient-il ? »
Les acteurs, et un seul rectangle Système. C'est la
définition de la boîte noire, et c'est aussi la façon la plus rapide de repérer un
DSS fautif. Si tu vois un contrôleur ou une base de données, ce n'est plus un DSS.
Un cas d'utilisation raconte comment un acteur atteint un objectif observable, du point de vue de celui qui s'en sert — jamais en termes d'écrans ni de boutons. Sa difficulté n'est pas la notation mais la taille : trop fin, il décrit un geste ; trop gros, il n'a pas de fin. Tout ce qui compte vit dans le descriptif, pas dans le diagramme, et les extensions y valent plus que le scénario principal parce qu'elles font sortir les règles du métier qu'on n'avait pas vues.
Le DSS est ce même scénario dont on n'a gardé que ce qui franchit la frontière du système, traité en boîte noire — un seul rectangle, et c'est le test qui repère un DSS fautif en une seconde. Chaque flèche entrante devient une opération système, et cette liste est le contrat que la conception devra réaliser.
Et ailleurs : la distinction entre ce qui traverse une frontière et ce qui se passe derrière est l'une des idées les plus réutilisables de l'informatique. C'est exactement celle d'une API — on publie ce qui entre et ce qui sort, on garde le reste libre de changer. Savoir écrire un DSS, c'est savoir dessiner une interface avant d'avoir écrit ce qu'il y a derrière, et cette compétence sert partout : concevoir un service web, découper un module, ou simplement décider ce qu'une classe doit rendre public.
- Les six lignes d'un descriptif de cas d'utilisation
- nom (verbe à l'infinitif), acteur principal, préconditions, garanties en cas de succès, scénario principal, extensions
- Ce que contient le scénario principal, et rien d'autre
- le chemin heureux : aucune erreur, aucun refus, aucune annulation. Tout le reste va dans les extensions
- Comment se numérote une extension, et ce qu'elle doit dire en plus
- le numéro de l'étape visée + une lettre (
3a,5b), et elle finit toujours par où l'on repart : reprise à l'étape N, ou échec - La différence entre acteur principal et secondaire
- le principal déclenche pour son propre objectif ; le secondaire est utilisé par le système en cours de route
- Les trois sortes d'acteurs qu'on oublie
- un autre système (passerelle de paiement), un périphérique, et l'horloge — dès que l'énoncé dit « automatiquement »
- D'où part la flèche d'un « include »
- du cas de base vers le cas inclus. Il est toujours exécuté, et la base en dépend
- D'où part la flèche d'un « extend »
- de l'ajout vers le cas de base. Le cas de base ne le connaît pas : c'est ce qui le rend optionnel
- Combien de rectangles dans un DSS
- un seul, nommé
Système. Un deuxième signifie qu'on a ouvert la boîte noire et fait de la conception - Ce qui d'un scénario apparaît dans le DSS
- uniquement ce qui franchit la frontière : une action de l'acteur, une réponse du système. Les « le système vérifie… » disparaissent
- Comment se trouvent les opérations système
- une par flèche entrante du DSS, nommée par un verbe, avec les paramètres que l'acteur fournit réellement