Le diagramme Use-Case, appelé diagramme de cas d’uti­li­sa­tion en français, fait partie des dia­grammes de com­por­te­ment du langage Unified Modelling Language, UML en abrégé, avec les systèmes et processus de pro­gram­ma­tion objet ou encore les processus métier. UML n’est donc pas un langage de pro­gram­ma­tion, mais un langage de mo­dé­li­sa­tion. C’est une méthode stan­dar­di­sée qui décrit un système en cours de con­cep­tion, ou déjà existant. Cela se fait à l’aide de dia­grammes, dans lesquels tous les objets impliqués sont struc­tu­rés et liés les uns aux autres.

Nom de domaine
Votre domaine en un clic
  • 1 cer­ti­fi­cat SSL Wildcard par contrat
  • Fonction incluse Domain Connect pour une con­fi­gu­ra­tion DNS sim­pli­fiée

Le diagramme de cas d’uti­li­sa­tion : l’un des nombreux dia­grammes UML

Comme il serait trop compliqué et trop confus d’afficher tous les objets, toutes les relations et tous les processus dans un seul diagramme, 14 types de dia­grammes dif­fé­rents sont utilisés en UML. Ils peuvent être divisés dans les ca­té­go­ries suivantes : dia­grammes de structure, dia­grammes de com­por­te­ment et dia­grammes d’in­te­rac­tion, les dia­grammes d’in­te­rac­tion étant un sous-ensemble des dia­grammes de com­por­te­ment.

Dans les dia­grammes de structure, l’accent est mis sur la car­to­gra­phie de tous les éléments d’un système et de leurs relations les uns avec les autres. Un exemple typique est le diagramme de classes, par lequel les éléments peuvent être regroupés et vi­sua­li­sés de manière hié­rar­chique. Les dia­grammes de com­por­te­ment, pour leur part, ne portent pas sur les struc­tures statiques, mais montrent plutôt le flux de processus prévu ou existant, comme il est attendu à l’uti­li­sa­tion du programme ou du logiciel. Avec ces dia­grammes, c’est donc la dynamique qui est au premier plan.

Le diagramme de cas d’uti­li­sa­tion est cependant un cas par­ti­cu­lier dans ce groupe, car il re­pré­sente quel com­por­te­ment est attendu du système ou du logiciel dans un cas d’uti­li­sa­tion spé­ci­fique. Par rapport aux autres dia­grammes de com­por­te­ment en UML, le diagramme de cas d’uti­li­sa­tion est donc plutôt statique, car il ne sert qu’à décrire l’action globale et l’objectif, mais non la séquence exacte des dif­fé­rents processus et actions élé­men­taires. Pour cela, d’autres types de dia­grammes sont utilisés en UML, par ex. les dia­grammes d’activité pour la re­pré­sen­ta­tion chro­no­lo­gique des processus ou les dia­grammes de séquence pour l’échange de messages entre les dif­fé­rents com­po­sants d’un système.

Le diagramme de cas d’uti­li­sa­tion en pratique

Un diagramme de cas d’uti­li­sa­tion permet de re­pré­sen­ter les fonctions d’un système du point de vue de l’uti­li­sa­teur (appelé « acteur » en UML). Cet acteur ne doit pas né­ces­sai­re­ment être un uti­li­sa­teur humain. Le rôle peut également être attribué à un système externe qui accède à un autre système. Le diagramme de cas d’uti­li­sa­tion montre en fait la relation entre un acteur et ses demandes ou attentes vis-à-vis du système, sans décrire les actions en cours ni les mettre dans un ordre logique.

En pratique, cette structure est bien adaptée pour décrire de manière claire les fonctions et/ou les objectifs les plus im­por­tants d’un système. C’est pour cette raison que l’éla­bo­ra­tion d’un diagramme de cas d’uti­li­sa­tion est souvent l’une des premières étapes lors de la con­cep­tion de logiciels ou de la pla­ni­fi­ca­tion de nouveaux processus métier. Cela permet de vi­sua­li­ser fa­ci­le­ment et clai­re­ment quels cas d’uti­li­sa­tion doivent être pris en compte dans la con­cep­tion pour que les acteurs (et au sens large également l’opérateur ou le client) at­teig­nent les objectifs escomptés – sans tenir compte dans un premier temps de la fai­sa­bi­lité technique.

Briques de base et structure du diagramme de cas d’uti­li­sa­tion

Pour garantir que le diagramme de cas d’uti­li­sa­tion soit im­mé­dia­te­ment com­pré­hen­sible pour tout un chacun, on utilise des briques de base stan­dar­di­sées pour la re­pré­sen­ta­tion. Il y a en premier lieu trois éléments prin­ci­paux :

  • Acteur : les acteurs, que ce soit des personnes ou des systèmes, sont re­pré­sen­tés par des bonhommes en fil de fer.
  • Système : le système auquel se rapporte le cas d’uti­li­sa­tion est re­pré­senté par un rectangle.
  • Use Case : le cas d’uti­li­sa­tion lui-même est re­pré­senté par une ellipse, dans laquelle il y a gé­né­ra­le­ment une courte phrase décrivant le processus.
Image: Représentation de l’acteur, du système et du cas d’utilisation
Symboles utilisés pour re­pré­sen­ter les éléments acteur, système et cas d’uti­li­sa­tion

Les relations entre ces éléments sont re­pré­sen­tées par des lignes de connexion, appelées as­so­cia­tions. Une ligne continue entre un acteur et un cas d’uti­li­sa­tion indique clai­re­ment que l’acteur et le cas d’uti­li­sa­tion décrits dans l’ellipse sont liés. Il y a aussi des lignes poin­til­lées pour re­pré­sen­ter une relation entre dif­fé­rents cas d’uti­li­sa­tion. Comme il existe deux types dif­fé­rents d’as­so­cia­tion entre les cas d’uti­li­sa­tion, les lignes sont com­plé­tées par un mot-clé appelé « sté­réo­type » en UML et re­pré­senté entre crochets. Une pointe de flèche montre par ailleurs une relation de dé­pen­dance entre cas d’uti­li­sa­tion. Une dis­tinc­tion est faite entre ces deux sté­réo­types :

  • L’as­so­cia­tion d’inclusion (include) : le cas d’uti­li­sa­tion d’où part la ligne de connexion en poin­til­lés inclut un deuxième cas d’uti­li­sa­tion, pointé par la pointe de flèche.
  • L’as­so­cia­tion d’extension : le cas d’uti­li­sa­tion d’où part la ligne de connexion en poin­til­lés commence peut, sous certaines con­di­tions, étendre le cas d’uti­li­sa­tion pointé par la tête de flèche. Mais ce n’est pas toujours le cas.
Image: Représentation des relations entre acteur et cas d’utilisation, ainsi qu’entre différents cas d’utilisation
Les lignes mettent en évidence les relations entre les éléments in­di­vi­duels par le biais des pointes de flèche et des sté­réo­types.

Alors que l’as­so­cia­tion d’inclusion nécessite la prise en compte des deux cas d’uti­li­sa­tion, la prise en compte du deuxième cas d’uti­li­sa­tion, dans l’as­so­cia­tion d’extension, dépend de certaines con­di­tions. Ces con­di­tions sont spé­ci­fiées dans le diagramme de cas d’uti­li­sa­tion UML par le biais d’un point d’extension. Ceci est re­pré­senté de deux manières dif­fé­rentes :

  • Extension de l’ellipse du cas d’uti­li­sa­tion : le point d’extension possible est nommé et briè­ve­ment décrit sous le nom du cas d’uti­li­sa­tion.
  • Note : le sté­réo­type d’extension est relié par une ligne en poin­til­lés à une note stylisée (rectangle avec un coin plié) intitulée « Condition » et « Extension ». Derrière « condition », on spécifie entre accolades quelle condition doit être remplie pour que le deuxième cas d’uti­li­sa­tion soit pris en compte. Derrière le point d’extension, on renvoie à son nom dans l’ellipse du cas d’uti­li­sa­tion afin que l’extension puisse être attribuée sans équivoque.
Image: Représentation d’un point d’extension, qui constitue la condition d’un cas d’application éventuel
Si les con­di­tions définies dans le point d’extension s’ap­pli­quent, le cas d’uti­li­sa­tion B se produira et modifiera le cours du cas d’uti­li­sa­tion A.

Vous con­nais­sez main­te­nant toutes les briques de base dont vous aurez besoin pour créer votre propre diagramme de cas d’uti­li­sa­tion.

Le diagramme de cas d’uti­li­sa­tion par l’exemple

Jusqu’à ce point, vous avez reçu beaucoup de con­nais­sances théo­riques. Pour vous donner une meilleure idée de la mise en œuvre pratique, nous allons main­te­nant vous montrer comment créer un diagramme d’ap­pli­ca­tion en utilisant l’exemple d’un client de banque qui souhaite retirer de l’argent à un dis­tri­bu­teur au­to­ma­tique.

Note

Dans la pratique, assurez-vous toujours de ne pas rendre votre diagramme de cas d’uti­li­sa­tion trop complexe. Cela peut vite se produire si vous affichez plusieurs cas dans le même diagramme, d’autant plus s’ils sont également liés par des as­so­cia­tions « include » et « extend ». En cas de doute, il est pré­fé­rable de créer un diagramme de cas d’uti­li­sa­tion distinct pour chaque cas.

Cela signifie que le DAB est le système et que le client de la banque est l’acteur, qui souhaite exécuter le cas d’uti­li­sa­tion « retirer de l’argent ». Ceci est lié à deux autres cas d’uti­li­sa­tion via des as­so­cia­tions d’inclusion, à savoir « au­then­ti­fi­ca­tion » et « vé­ri­fi­ca­tion du code PIN et du compte ». Si l’au­then­ti­fi­ca­tion échoue, la demande du client ne peut pas être traitée. Pour que les ten­ta­tives du client ne se pour­sui­vent pas à l’infini, la carte doit être avalée si le code PIN a été saisi trois fois de manière in­cor­recte. Pour le cas d’uti­li­sa­tion « au­then­ti­fi­ca­tion », on crée donc un point d’extension avec la condition « trois PIN erronés ». Si cette condition est remplie, le cas d’uti­li­sa­tion « avaler carte » est exécuté ; il est connecté au cas d’uti­li­sa­tion « au­then­ti­fi­ca­tion » via une as­so­cia­tion d’extension. Le diagramme de cas d’uti­li­sa­tion de cet exemple ressemble à ceci :

Image: Illustration d’un diagramme de cas d’utilisation pour « retirer de l’argent » avec les associations d’inclusion et d’extension correspondantes
Le diagramme de cas d’uti­li­sa­tion pour le cas d’uti­li­sa­tion « retirer de l’argent », illustre comment les dif­fé­rents cas d’uti­li­sa­tion sont liés les uns aux autres.
Aller au menu principal