![\"A](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a0ed6385d42a.png\")
<\/p>\n
\u00c0 travers cette \u00e9tude de cas, vous explorerez les \u00e9l\u00e9ments structurels fondamentaux des cas d’utilisation UML 2.0, apprendrez \u00e0 factoriser le comportement \u00e0 l’aide de\u00a0 D\u00e9fi :<\/strong>Les exigences initiales de NexusBook \u00e9taient stock\u00e9es dans des feuilles de calcul \u00e9parses et des documents r\u00e9dig\u00e9s au pass\u00e9. Les d\u00e9veloppeurs interpr\u00e9taient fr\u00e9quemment \u00e0 tort les cas limites, les \u00e9quipes de QA avaient du mal \u00e0 retracer les sc\u00e9narios de test, et les gestionnaires de produit ne pouvaient pas visualiser les fronti\u00e8res du syst\u00e8me. Le processus de paiement, en particulier, souffrait de logique de connexion redondante, de chemins d’annulation flous et de descriptions trop centr\u00e9es sur l’interface qui r\u00e9v\u00e9laient des d\u00e9tails de conception dans les exigences.<\/p>\n Solution :<\/strong> L’\u00e9quipe a pivot\u00e9 vers une approche structur\u00e9e des cas d’utilisation UML 2.0, en imposant des limites diagrammatiques strictes et une factorisation comportementale<\/p>\n . Les sections suivantes d\u00e9taillent comment ces principes ont \u00e9t\u00e9 appliqu\u00e9s en pratique.<\/p>\n Un cas d’utilisation mod\u00e9lise une unit\u00e9 de fonctionnalit\u00e9 du syst\u00e8me d\u00e9finie par les interactions entre des entit\u00e9s externes et le syst\u00e8me lui-m\u00eame afin d’atteindre un objectif m\u00e9tier sp\u00e9cifique. \u00c0 NexusBook, l’\u00e9quipe a ancr\u00e9 ses efforts de mod\u00e9lisation autour de quatre piliers fondamentaux :<\/p>\n Acteurs<\/strong> : Repr\u00e9sentent des r\u00f4les coh\u00e9rents jou\u00e9s par des entit\u00e9s externes. NexusBook a identifi\u00e9 des acteurs humains tels que\u00a0 Sujet<\/strong>: La fronti\u00e8re du syst\u00e8me en cours de d\u00e9veloppement. NexusBook a explicitement encadr\u00e9 le\u00a0 D\u00e9roulement des \u00e9v\u00e9nements<\/strong>:<\/p>\n Flux principal (parcours de base)<\/strong>: Le \u00ab chemin heureux \u00bb o\u00f9 l’acteur principal r\u00e9ussit sans erreurs. Exemple : Un client effectue avec succ\u00e8s la caisse.<\/p>\n<\/li>\n Flux exceptionnel (parcours alternatif)<\/strong>: Conditions d’erreur, cas limites ou branches optionnelles. Exemple : Refus de paiement, expiration de session ou annulation optionnelle de commande.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n Instance de cas d’utilisation<\/strong>: Un seul chemin d’ex\u00e9cution en temps r\u00e9el. Chaque transaction client chez NexusBook repr\u00e9sentait une instance de cas d’utilisation unique, permettant une cartographie pr\u00e9cise des tests QA.<\/p>\n<\/li>\n<\/ul>\n Pour \u00e9viter des cas d’utilisation monolithiques et non maintenables, NexusBook a utilis\u00e9 les trois m\u00e9canismes de relation de UML 2.0 pour factoriser les comportements communs et g\u00e9rer les parcours vari\u00e9s.<\/p>\n Concept<\/strong>: Un cas d’utilisation de base tire explicitement le comportement d’un cas d’utilisation inclus \u00e0 un point d\u00e9fini. Le cas d’utilisation inclus ne peut pas exister seul.<\/p>\n<\/li>\n Application NexusBook<\/strong>: Les deux\u00a0 Objectif<\/strong>: \u00c9limine la redondance et centralise le comportement partag\u00e9.<\/p>\n<\/li>\n<\/ul>\n Concept<\/strong>: Un cas d’utilisation variant ins\u00e8re implicitement son comportement dans un cas d’utilisation de base uniquement aux points d’extension explicitement nomm\u00e9sPoints d’extension<\/strong>.<\/p>\n<\/li>\n Application NexusBook<\/strong>: Pendant\u00a0 Objectif<\/strong>: G\u00e8re les comportements facultatifs, conditionnels ou peu fr\u00e9quents sans alourdir le flux principal.<\/p>\n<\/li>\n<\/ul>\n Concept<\/strong>: Fonctionne comme l’h\u00e9ritage de classe. Un cas d’utilisation parent d\u00e9finit un mod\u00e8le de comportement que les enfants sp\u00e9cialisent ou remplacent. Les acteurs peuvent \u00e9galement h\u00e9riter des privil\u00e8ges.<\/p>\n<\/li>\n Application NexusBook<\/strong>:\u00a0 Objectif<\/strong>: Permet la classification taxonomique et la mod\u00e9lisation d’acc\u00e8s bas\u00e9e sur les r\u00f4les.<\/p>\n<\/li>\n<\/ul>\n Les diagrammes fournissent l’ossature architecturale de la mod\u00e9lisation des cas d’utilisation. Ci-dessous se trouvent les sp\u00e9cifications exactes de PlantUML utilis\u00e9es par NexusBook, compl\u00e9t\u00e9es par des contr\u00f4les de disposition pour \u00e9viter les graphes enchev\u00eatr\u00e9s.<\/p>\n Cartographie les limites du syst\u00e8me, les acteurs et le facteur comportemental pour le sous-syst\u00e8me de caisse.<\/p>\n\u00abinclude\u00bb<\/code>,\u00a0\u00abextend\u00bb<\/code>, et de la g\u00e9n\u00e9ralisation, ma\u00eetriserez les techniques de diagrammation PlantUML, et appliquerez des directives textuelles \u00e9prouv\u00e9es pour r\u00e9diger des cas d’utilisation solides et pr\u00eats \u00e0 \u00eatre d\u00e9velopp\u00e9s.<\/p>\n
\nContexte de l’\u00e9tude : la plateforme NexusBook<\/h2>\n
\n1. Concepts fondamentaux et \u00e9l\u00e9ments structurels en pratique<\/h2>\n
Les piliers fondamentaux appliqu\u00e9s<\/h3>\n
\n
Client<\/code> et\u00a0Agent d'assistance<\/code>, ainsi que des acteurs syst\u00e8me tels que\u00a0Passerelle de paiement<\/code> et\u00a0Service de messagerie<\/code>.<\/p>\n<\/li>\nSyst\u00e8me de caisse de librairie<\/code>\u00a0et\u00a0Syst\u00e8mes de gestion des stocks et de comptabilit\u00e9<\/code>\u00a0afin de s\u00e9parer le comportement interne des d\u00e9pendances externes.<\/p>\n<\/li>\n\n
\n2. Organisation et structuration des cas d’utilisation<\/h2>\n
I. Inclure (
\u00abinclure\u00bb<\/code>)<\/h3>\n\n
Ajouter \u00e0 la liste de souhaits<\/code>\u00a0et\u00a0Passer \u00e0 la caisse<\/code>\u00a0n\u00e9cessitent une authentification. Au lieu de dupliquer des \u00e9tapes, l’\u00e9quipe a cr\u00e9\u00e9 un cas d’utilisation autonome\u00a0Connexion<\/code>\u00a0et l’a inclus partout o\u00f9 il \u00e9tait obligatoire.<\/p>\n<\/li>\nII. \u00c9tendre (
\u00ab\u00e9tendre\u00bb<\/code>)<\/h3>\n\n
V\u00e9rifier l'\u00e9tat de la commande<\/code>, les clients pouvaient \u00e9ventuellement d\u00e9clencher\u00a0Annuler la commande<\/code>. Cela a \u00e9t\u00e9 mod\u00e9lis\u00e9 comme une extension li\u00e9e au point d’extension[Annulation demand\u00e9e]<\/code>\u00a0d’extension.<\/p>\n<\/li>\nIII. G\u00e9n\u00e9ralisation<\/h3>\n
\n
Effectuer une recherche<\/code>\u00a0a servi de parent \u00e0\u00a0Rechercher par titre<\/code>,\u00a0Rechercher par auteur<\/code>, et\u00a0Rechercher par ISBN<\/code>. De m\u00eame,\u00a0Personnel comptable<\/code>\u00a0a transmis les autorisations de base \u00e0\u00a0Comptable<\/code>\u00a0et\u00a0Comptable adjoint<\/code>.<\/p>\n<\/li>\n
\n3. Strat\u00e9gies de mod\u00e9lisation visuelle et de disposition de PlantUML<\/h2>\n
Sc\u00e9nario A : Relations structurelles (
\u00abinclure\u00bb<\/code>\u00a0&\u00a0\u00ab\u00e9tendre\u00bb<\/code>)<\/h3>\n![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a0ed4d511704.png\")
<\/p>\n
\n
\n