Diagramme de cas d’utilisation

1. Du besoin à un objectif observable

Un cas d’utilisation décrit un service que le système rend à un acteur pour atteindre un objectif. « Accepter un devis » produit un résultat métier ; « cliquer sur le bouton vert » décrit une interaction d’interface. Le même service pourrait être proposé demain dans une application mobile sans changer d’objectif.

On nomme généralement un cas avec un verbe à l’infinitif et un complément : soumettre une demande, consulter un dossier, préparer un devis, accepter un devis. La liste doit rester centrée sur les résultats attendus. Les opérations internes, comme écrire une ligne dans une base, seront étudiées dans les interactions.

Une exigence fonctionnelle indique un service attendu. Une exigence de qualité précise par exemple une disponibilité, un délai ou une restriction d’accès. Dire « le client consulte uniquement ses demandes » apporte une contrainte indispensable ; dessiner une ellipse « sécurité » ne suffit pas à la spécifier.

2. Acteurs et frontière du portail

Un acteur est un rôle extérieur au système qui échange avec lui. Il peut s’agir d’une personne, d’un autre logiciel ou d’un équipement. Le client est un acteur ; le service externe de notification peut également en être un. La base de données interne n’est pas un acteur dans notre périmètre.

Le rectangle délimite le portail NKILItech Services. Les ellipses sont à l’intérieur, les acteurs à l’extérieur. Une association en trait plein signale une participation ; elle n’exprime ni ordre chronologique ni transfert de données. Le PDG est extérieur au logiciel même s’il appartient à l’entreprise.

Une même personne peut jouer plusieurs rôles : un collaborateur peut être chargé d’affaires sur un dossier et responsable technique sur un autre. Inversement, plusieurs personnes peuvent jouer le rôle de client. Modéliser le rôle évite de dessiner une nouvelle silhouette pour chaque nom propre.

3. Inclusion, extension et généralisation

« include » représente l’insertion du comportement d’un autre cas. La flèche en pointillés part du cas qui inclut et pointe vers le cas inclus. Préparer un devis inclut calculer le total : le chiffrage nécessite ce calcul. Une inclusion n’est pas un simple lien « se déroule après ».

« extend » décrit un ajout conditionnel à un cas de base qui reste défini indépendamment de cet ajout. La flèche part du cas d’extension et pointe vers le cas étendu. Dans notre exemple, joindre une pièce peut étendre soumettre une demande au point d’extension « pièces complémentaires », si le client choisit d’ajouter un document.

La généralisation spécialise un acteur ou un cas. Le triangle creux pointe vers l’élément général. Un acteur spécialisé reprend les participations du rôle général. On peut définir Collaborateur puis Chargé d’affaires et Responsable technique, à condition que chacun puisse réellement assumer les interactions du rôle parent.

4. Fiche complète : accepter un devis

1. Le système présente le devis et sa version courante.
2. Le client confirme son accord.
3. Le système vérifie l’identité du client, la validité du devis et l’absence d’une autre version acceptée.
4. Il enregistre l’acceptation avec sa date dans une transaction.
5. Il confirme le résultat et programme la notification du chargé d’affaires.

A1 - Devis expiré : à l’étape 3, le système refuse l’acceptation et invite à demander une nouvelle proposition. A2 - Confirmation déjà traitée : le résultat accepté est renvoyé sans créer une seconde acceptation. A3 - Notification indisponible : l’accord demeure enregistré ; une nouvelle tentative d’envoi est prévue.

La fiche précise un contrat fonctionnel. Elle ne choisit ni un framework ni un schéma de base. Les détails d’implémentation apparaîtront lorsque nous répartirons les responsabilités entre objets.

5. Élaborer et vérifier le diagramme

1. Écrire en une phrase la responsabilité du portail.
2. Repérer les rôles qui échangent directement avec lui.
3. Interroger chaque rôle sur les résultats qu’il attend.
4. Regrouper les variantes d’un même objectif, puis rédiger les scénarios.
5. Introduire une relation UML seulement lorsqu’elle clarifie un comportement partagé ou conditionnel.
6. Vérifier les règles métier avec des exemples de succès et d’échec.

Pour R4, un devis de 1 200 000 FCFA doit recevoir un accord du PDG avant envoi. Cela peut être décrit par un cas « Approuver un devis » et un scénario d’envoi qui vérifie cette condition. Une flèche entre deux ellipses ne remplace pas l’écriture de la règle de seuil.

Test d’acceptation : étant donné un devis envoyé encore valable appartenant au client connecté, lorsqu’il confirme l’accord, alors le devis devient accepté une seule fois et le dossier devient planifiable. Le même test avec un autre client doit produire un refus sans modification.

Scénarios illustrés : comparer les situations

Un scénario sans pièce jointe reste complet

Le client enregistre le besoin et reçoit une référence, même sans ajouter de document. L’extension n’intervient que lorsqu’il souhaite compléter sa demande. Une obligation de pièce justificative demanderait une autre règle, explicitement définie.

Exercices corrigés