En g\u00e9nie logiciel, les diagrammes de cas d’utilisation aident \u00e0 visualiser les interactions entre les utilisateurs (acteurs) et un syst\u00e8me afin de capturer ses exigences fonctionnelles. \u00c0 mesure que les syst\u00e8mes grandissent, les diagrammes de cas d’utilisation peuvent devenir difficiles \u00e0 g\u00e9rer, remplis de comportements r\u00e9p\u00e9titifs ou complexes qui masquent la fonctionnalit\u00e9 centrale du syst\u00e8me. La relation d’inclusion<\/strong>en UML r\u00e9pond \u00e0 ce d\u00e9fi en permettant d’extraire les comportements communs dans des cas d’utilisation r\u00e9utilisables et modulaires. Cet article explore comment les relations d’inclusion simplifient les diagrammes de cas d’utilisation, leurs principaux avantages et des exemples pratiques pour d\u00e9montrer leur utilit\u00e9.<\/p>\n Une relation d’inclusion<\/strong>en UML pr\u00e9cise qu’un cas d’utilisation de base int\u00e8gre le comportement d’un autre cas d’utilisation, appel\u00e9 cas d’utilisation inclus. Le cas d’utilisation inclus repr\u00e9sente une s\u00e9quence d’actions qui est toujours ex\u00e9cut\u00e9e<\/strong>comme partie du d\u00e9roulement du cas d’utilisation de base. Visuellement, cette relation est repr\u00e9sent\u00e9e par une fl\u00e8che pointill\u00e9e avec une t\u00eate de fl\u00e8che ouverte<\/strong>pointant du cas d’utilisation de base vers le cas d’utilisation inclus, \u00e9tiquet\u00e9e par le st\u00e9r\u00e9otype \u00abinclusion\u00bb.<\/p>\n La relation d’inclusion est analogue \u00e0 un appel de sous-routine en programmation : le cas d’utilisation de base \u00abappelle\u00bb le cas d’utilisation inclus pour effectuer une t\u00e2che sp\u00e9cifique, favorisant une mod\u00e9lisation structur\u00e9e et hi\u00e9rarchique. En extrayant les comportements communs ou complexes dans des cas d’utilisation distincts, les relations d’inclusion r\u00e9duisent la duplication, am\u00e9liorent la clart\u00e9 et renforcent la maintenabilit\u00e9.<\/p>\n Les relations d’inclusion offrent plusieurs avantages lors de la mod\u00e9lisation de syst\u00e8mes volumineux et complexes :<\/p>\n R\u00e9utilisation du comportement commun<\/strong> : La fonctionnalit\u00e9 partag\u00e9e entre plusieurs cas d’utilisation peut \u00eatre encapsul\u00e9e dans un seul cas d’utilisation inclus, \u00e9liminant ainsi la redondance.<\/p>\n<\/li>\n Simplification des cas d’utilisation complexes<\/strong> : Les grands cas d’utilisation peuvent \u00eatre divis\u00e9s en modules plus petits et g\u00e9rables, rendant le diagramme moins encombr\u00e9.<\/p>\n<\/li>\n Ex\u00e9cution obligatoire<\/strong> : Le cas d’utilisation inclus est toujours ex\u00e9cut\u00e9 dans le cadre du cas d’utilisation de base, garantissant l’int\u00e9gralit\u00e9 sans surcharger le flux principal de d\u00e9tails.<\/p>\n<\/li>\n Clart\u00e9 et maintenabilit\u00e9 am\u00e9lior\u00e9es<\/strong> : En s\u00e9parant les pr\u00e9occupations, le cas d’utilisation de base se concentre sur son comportement unique, tandis que les cas d’utilisation inclus g\u00e8rent les s\u00e9quences r\u00e9utilisables, simplifiant ainsi les mises \u00e0 jour.<\/p>\n<\/li>\n Mod\u00e9lisation structur\u00e9e<\/strong> : Les relations d’inclusion soutiennent une conception hi\u00e9rarchique, similaire aux sous-routines, rendant le syst\u00e8me plus facile \u00e0 comprendre et \u00e0 \u00e9tendre.<\/p>\n<\/li>\n<\/ol>\n Pour illustrer la puissance des relations d’inclusion, examinons plusieurs exemples pratiques dans diff\u00e9rents domaines.<\/p>\n Consid\u00e9rons une plateforme de vente en ligne o\u00f9 les utilisateurs peuvent parcourir des produits, ajouter des articles \u00e0 un panier et effectuer la caisse. De nombreux cas d’utilisation, tels que \u00abAcheter un produit\u00bb, \u00abR\u00e9server un article\u00bb et \u00abOffrir un article\u00bb, n\u00e9cessitent que l’utilisateur soit authentifi\u00e9 avant de poursuivre.<\/p>\n Cas d’utilisation de base<\/strong>: \u00ab Acheter un produit \u00bb, \u00ab R\u00e9server un article \u00bb, \u00ab Offrir un article \u00bb<\/p>\n<\/li>\n Cas d’utilisation inclus<\/strong>: \u00ab Authentifier l’utilisateur \u00bb<\/p>\n<\/li>\n<\/ul>\n Au lieu de dupliquer les \u00e9tapes d’authentification dans chaque cas d’utilisation, nous les extrayons dans un seul cas d’utilisation \u00ab Authentifier l’utilisateur \u00bb. Ce cas d’utilisation inclus g\u00e8re des t\u00e2ches telles que la demande des identifiants de connexion et leur v\u00e9rification. Le diagramme de cas d’utilisation montrerait :<\/p>\n Une fl\u00e8che pointill\u00e9e de \u00ab Acheter un produit \u00bb vers \u00ab Authentifier l’utilisateur \u00bb avec \u00ab inclure \u00bb.<\/p>\n<\/li>\n Des fl\u00e8ches similaires de \u00ab R\u00e9server un article \u00bb et \u00ab Offrir un article \u00bb vers \u00ab Authentifier l’utilisateur \u00bb.<\/p>\n<\/li>\n<\/ul>\n Cette approche r\u00e9duit la redondance, car la logique d’authentification est d\u00e9finie une seule fois et r\u00e9utilis\u00e9e dans plusieurs cas d’utilisation, ce qui maintient le diagramme propre et facile \u00e0 maintenir.<\/p>\n Dans un syst\u00e8me bancaire, les clients peuvent effectuer des actions telles que \u00ab Retirer de l’argent \u00bb, \u00ab D\u00e9poser de l’argent \u00bb et \u00ab Transf\u00e9rer des fonds \u00bb. Chacun de ces cas d’utilisation n\u00e9cessite de valider le compte du client avant de poursuivre.<\/p>\n Cas d’utilisation de base<\/strong>: \u00ab Retirer de l’argent \u00bb, \u00ab D\u00e9poser de l’argent \u00bb, \u00ab Transf\u00e9rer des fonds \u00bb<\/p>\n<\/li>\n Cas d’utilisation inclus<\/strong>: \u00ab Valider le compte \u00bb<\/p>\n<\/li>\n<\/ul>\n Le cas d’utilisation \u00ab Valider le compte \u00bb v\u00e9rifie l’\u00e9tat du compte, le solde et les autorisations. En incluant ce cas d’utilisation dans chacun des cas d’utilisation de base, le diagramme \u00e9vite de r\u00e9p\u00e9ter la logique de validation. La repr\u00e9sentation visuelle inclut des fl\u00e8ches pointill\u00e9es \u00e9tiquet\u00e9es \u00ab inclure \u00bb partant de chaque cas d’utilisation de base vers \u00ab Valider le compte \u00bb. Cette modularisation simplifie le diagramme et garantit que la validation du compte est appliqu\u00e9e de mani\u00e8re coh\u00e9rente.<\/p>\n Dans un syst\u00e8me de biblioth\u00e8que, les utilisateurs peuvent \u00ab Emprunter un livre \u00bb, \u00ab Rendre un livre \u00bb ou \u00ab R\u00e9server un livre \u00bb. Chacune de ces actions n\u00e9cessite de v\u00e9rifier la disponibilit\u00e9 du livre.<\/p>\n Cas d’utilisation de base<\/strong>: \u00ab Emprunter un livre \u00bb, \u00ab Rendre un livre \u00bb, \u00ab R\u00e9server un livre \u00bb<\/p>\n<\/li>\n Cas d’utilisation inclus<\/strong>: \u00ab V\u00e9rifier la disponibilit\u00e9 du livre \u00bb<\/p>\n<\/li>\n<\/ul>\n Le cas d’utilisation \u00ab V\u00e9rifier la disponibilit\u00e9 du livre \u00bb v\u00e9rifie si le livre est en stock et non r\u00e9serv\u00e9. En incluant ce cas d’utilisation dans les cas d’utilisation de base, le diagramme reste clair, et les mises \u00e0 jour de la logique de v\u00e9rification de disponibilit\u00e9 (par exemple, l’int\u00e9gration d’un nouveau syst\u00e8me de gestion des stocks) n’ont besoin d’\u00eatre effectu\u00e9es qu’une seule fois.<\/p>\n Dans un syst\u00e8me de gestion hospitali\u00e8re, les patients peuvent \u00ab Planifier un rendez-vous \u00bb, \u00ab Annuler un rendez-vous \u00bb ou \u00ab Reprogrammer un rendez-vous \u00bb. Chacun de ces cas d’utilisation n\u00e9cessite de v\u00e9rifier l’identit\u00e9 du patient.<\/p>\n Cas d’utilisation de base<\/strong>: \u00ab Planifier un rendez-vous \u00bb, \u00ab Annuler un rendez-vous \u00bb, \u00ab Reprogrammer un rendez-vous \u00bb<\/p>\n<\/li>\n Cas d’utilisation inclus<\/strong>: \u00ab V\u00e9rifier l’identit\u00e9 du patient \u00bb<\/p>\n<\/li>\n<\/ul>\n Le cas d’utilisation \u00ab V\u00e9rifier l’identit\u00e9 du patient \u00bb g\u00e8re des t\u00e2ches telles que la v\u00e9rification de la pi\u00e8ce d’identit\u00e9 ou des d\u00e9tails d’assurance du patient. En incluant ce cas d’utilisation dans les cas d’utilisation de base, on s’assure que la v\u00e9rification d’identit\u00e9 est effectu\u00e9e de mani\u00e8re coh\u00e9rente sans dupliquer les \u00e9tapes dans le diagramme. Les fl\u00e8ches pointill\u00e9es \u00ab inclure \u00bb relient chaque cas d’utilisation de base \u00e0 \u00ab V\u00e9rifier l’identit\u00e9 du patient \u00bb, ce qui am\u00e9liore la clart\u00e9.<\/p>\n Sur une plateforme de e-learning, les \u00e9tudiants peuvent \u00ab\u00a0Passer un quiz\u00a0\u00bb, \u00ab\u00a0Soumettre un devoir\u00a0\u00bb ou \u00ab\u00a0Voir leurs notes\u00a0\u00bb. Chacune de ces actions n\u00e9cessite que l’\u00e9tudiant se connecte au syst\u00e8me.<\/p>\n Cas d’utilisation de base<\/strong>: \u00ab\u00a0Passer un quiz\u00a0\u00bb, \u00ab\u00a0Soumettre un devoir\u00a0\u00bb, \u00ab\u00a0Voir leurs notes\u00a0\u00bb<\/p>\n<\/li>\n Cas d’utilisation inclus<\/strong>: \u00ab\u00a0Se connecter\u00a0\u00bb<\/p>\n<\/li>\n<\/ul>\n Le cas d’utilisation \u00ab\u00a0Se connecter\u00a0\u00bb encapsule les \u00e9tapes d’authentification de l’utilisateur. En l’incluant dans les cas d’utilisation de base, le diagramme \u00e9vite de r\u00e9p\u00e9ter les \u00e9tapes de connexion, ce qui le rend plus facile \u00e0 comprendre et \u00e0 maintenir. La repr\u00e9sentation visuelle montre des fl\u00e8ches pointill\u00e9es \u00e9tiquet\u00e9es \u00ab\u00a0include\u00a0\u00bb partant de chaque cas d’utilisation de base vers \u00ab\u00a0Se connecter\u00a0\u00bb.<\/p>\n Dans les diagrammes de cas d’utilisation UML, la relation d’inclusion est repr\u00e9sent\u00e9e comme suit\u00a0:<\/p>\n Une fl\u00e8che pointill\u00e9e<\/strong> avec une pointe de fl\u00e8che ouverte<\/strong>pointe du cas d’utilisation de base vers le cas d’utilisation inclus.<\/p>\n<\/li>\n La fl\u00e8che est \u00e9tiquet\u00e9e avec le st\u00e9r\u00e9otype \u00ab\u00a0include\u00a0\u00bb<\/strong>.<\/p>\n<\/li>\n<\/ul>\n Par exemple, dans l’exemple d’achat en ligne\u00a0:<\/p>\n Acheter un produit<\/strong> \u2192 \u00ab\u00a0include\u00a0\u00bb \u2192 Authentifier l’utilisateur<\/strong><\/p>\n<\/li>\n Le diagramme montre clairement que \u00ab\u00a0Authentifier l’utilisateur\u00a0\u00bb est une \u00e9tape obligatoire du flux \u00ab\u00a0Acheter un produit\u00a0\u00bb.<\/p>\n<\/li>\n<\/ul>\n Cette convention visuelle garantit que les parties prenantes peuvent rapidement comprendre les relations entre les cas d’utilisation et leurs d\u00e9pendances.<\/p>\n Il est important de noter la diff\u00e9rence entre include<\/strong> et extend<\/strong> les relations afin d’\u00e9viter toute confusion\u00a0:<\/p>\n Include<\/strong>: Le cas d’utilisation inclus est toujours ex\u00e9cut\u00e9<\/strong> comme partie du cas d’utilisation de base (obligatoire).<\/p>\n<\/li>\n \u00c9tendre<\/strong>: Le cas d’utilisation \u00e9tendu est facultatif<\/strong> et ex\u00e9cut\u00e9 uniquement sous des conditions sp\u00e9cifiques.<\/p>\n<\/li>\n<\/ul>\n Par exemple, dans le syst\u00e8me de vente en ligne, \u00ab Authentifier l’utilisateur \u00bb est inclus car il est obligatoire, mais un cas d’utilisation comme \u00ab Appliquer un code de r\u00e9duction \u00bb pourrait \u00eatre une relation d’\u00e9tendue, car il est facultatif et d\u00e9pend du fait que l’utilisateur dispose d’un code valide.<\/p>\n Pour maximiser les avantages des relations d’inclusion, consid\u00e9rez ce qui suit :<\/p>\n Identifier les comportements communs<\/strong>: Recherchez des s\u00e9quences d’actions r\u00e9p\u00e9t\u00e9es \u00e0 travers plusieurs cas d’utilisation, telles que l’authentification, la validation ou la journalisation.<\/p>\n<\/li>\n Maintenir les cas d’utilisation inclus centr\u00e9s<\/strong>: Assurez-vous que les cas d’utilisation inclus encapsulent des comportements sp\u00e9cifiques et r\u00e9utilisables plut\u00f4t que des processus complets.<\/p>\n<\/li>\n \u00c9quilibrer la modularit\u00e9 et la simplicit\u00e9<\/strong>: \u00c9vitez de sur-fragmenter les cas d’utilisation, car trop de cas d’utilisation inclus peuvent rendre le diagramme plus difficile \u00e0 suivre.<\/p>\n<\/li>\n Utiliser des conventions de nommage claires<\/strong>: Nommez les cas d’utilisation inclus pour refl\u00e9ter leur objectif (par exemple, \u00ab Authentifier l’utilisateur \u00bb au lieu de \u00ab Processus de connexion \u00bb) afin d’am\u00e9liorer la lisibilit\u00e9.<\/p>\n<\/li>\n Valider l’ex\u00e9cution obligatoire<\/strong>: Confirmez que le cas d’utilisation inclus est toujours requis ; sinon, envisagez une relation d’\u00e9tendue.<\/p>\n<\/li>\n<\/ol>\n Le tableau suivant r\u00e9sume les principaux avantages des relations d’inclusion :<\/p>\nQu’est-ce qu’une relation d’inclusion ?<\/h2>\n
Avantages des relations d’inclusion<\/h2>\n
\n
Exemples de relations d’inclusion<\/h2>\n
Exemple 1 : Syst\u00e8me de vente en ligne<\/h3>\n
\n
\n
Exemple 2 : Syst\u00e8me bancaire<\/h3>\n
\n
Exemple 3 : Syst\u00e8me de gestion de biblioth\u00e8que<\/h3>\n
\n
Exemple 4 : Syst\u00e8me de gestion hospitali\u00e8re<\/h3>\n
\n
Exemple 5 : Plateforme d’apprentissage en ligne<\/h3>\n
\n
Repr\u00e9sentation visuelle en UML<\/h2>\n
\n
\n
Comparaison avec les relations extend<\/h2>\n
\n
Meilleures pratiques pour utiliser les relations d’inclusion<\/h2>\n
\n
R\u00e9sum\u00e9 des avantages<\/h2>\n