3.2.4 Cas d’utilisation, lien de communication et système

• Un cas d’utilisation est un moyen de représenter les différentes possibilités d’un système
• Il correspond à une suite d’interactions entre un acteur et le système
• Il définit une fonctionnalité utilisable par un acteur

    précédent     suivant 

Un cas d’utilisation est « quelque chose » qui fournit un résultat mesurable à un acteur du système ; le cas d’utilisation capture une fonctionnalité que le système fournit. Un cas d’utilisation décrit les exigences du système d’un point de vue strictement extérieur au système : il indique la valeur que le système apporte aux utilisateurs. Ainsi, voyant les fonctionnalités décrites, le client ou l’utilisateur peut indiquer ses priorités, par analogie aux formules classiques du cahier des charges telles que « le système doit » ou « le système devrait ». Dans la première formulation, la fonctionnalité est incontournable et doit exister dans une solution minimale au problème alors que dans la seconde cette fonctionnalité est optionnelle dans une version minimale du système. Un cas d’utilisation est donc une spécification de séquence d’actions qu’un système peut réaliser en interaction avec des acteurs extérieurs au système.

Le lien de communication entre un acteur et un cas d’utilisation indique que l’acteur utilise le système par cette fonctionnalité : il en a besoin, ou autrement dit, il modifie l’état du système en « exécutant » cette fonctionnalité. Le lien de communication montre l’acteur participant au cas d’utilisation. L’élément de modélisation est appelé dans la terminologie UML une association. Quelquefois, les diagrammes de cas d’utilisation ajoutent des flèches, appelées navigabilités, aux liens de communication pour spécifier comment l’acteur est impliqué dans le cas d’utilisation : l’acteur reçoit des informations ou démarre le cas d’utilisation et fournit de l’information. Cependant, ce n’est pas le rôle premier du lien de communication ; il est donc préférable de ne pas mettre de navigabilité.

Les cas d’utilisation du système sont rassemblés dans un rectangle / une boîte pour signifier plus clairement les limites entre l’intérieur et l’extérieur du système. L’équipe n’est pas « payée » pour réaliser les fonctionnalités hors du périmètre du système.

D’autres relations entre cas d’utilisation existent :

• «include» = réutilisation complète sans changement,
• généralisation spécialisation ou héritage = spécialisation de certaines actions du cas d’utilisation d’origine,
• «extend»⁷ = ajout de fonctionnalité facultative.

Les relations entre cas d’utilisation ont pour but de décomposer le système en fonctionnalités à granularité plus fine, suivant ainsi l’adage « diviser pour régner ». Il existe trois types de décompositions ou relations entre cas d’utilisation, les deux principales étant l’inclusion et l’héritage, la troisième (l’extension) étant d’utilisation mal aisée et déconseillée⁸.

La relation la plus simple à comprendre entre deux cas d’utilisation est l’inclusion notée par une dépendance stéréotypée « «include» ». L’inclusion exprime le fait qu’un cas d’utilisation comprend une séquence d’actions consécutives qu’il est possible de factoriser avec d’autres cas d’utilisation. Dans notre étude de cas Studs, la vérification des droits est similaire, à quelques paramètres près, et peut être factorisée pour la création et la participation à un scrutin. Lorsque le système modélisé atteint une certaine taille, il est important de montrer les relations d’inclusion qui définissent alors des parties du système réutilisables par d’autres parties.

La relation de généralisation spécialisation ou héritage est utile pour montrer qu’un cas d’utilisation est un type spécial d’un autre : le cas d’utilisation le plus spécialisé diffère quelque peu de l’original. Le premier spécialise certaines étapes de la séquence d’actions du second en les remplaçant par des « versions » plus spécialisées. Ainsi, toutes les étapes du cas d’utilisation original doivent être exécutées, certaines étant remplacées par des « versions » plus spécialisées. Dans notre étude de cas, nous pouvons imaginer que le client demande de concevoir l’authentification comme une « brique » générique spécialisable selon les protocoles existants. Par exemple, nous spécialisons le cas d’utilisation « vérifier droits » en utilisant la méthode M1 et créons le nouveau cas d’utilisation « authentification M1 ».

La relation d’extension entre cas d’utilisation est très controversée. Les concepteurs du langage UML ont voulu montrer qu’un cas d’utilisation peut réutiliser un cas d’utilisation complet, de manière similaire à l’inclusion, mais que cette réutilisation est optionnelle et dépend des conditions d’exécution. Dans l’exemple de la figure de cette diapositive, l’authentification par la méthode M1 peut être complétée de manière facultative par l’enregistrement de toutes les tentatives, y compris celles qui ont été infructueuses, dans le but d’auditer a posteriori le système ou de lancer des alertes sécurité en cas d’attaques du système lorsque des suites de tentatives infructueuses proviennent d’un même domaine d’adresse IP (attaque dite de déni de service).

D. Conan, C. Taconet, C. Bac, Télécom SudParis, CSC 4002, Octobre 2015