Ah mais oui, je n'y avais pas pensé.
Dans un diagramme de cas d'utilisation, il faut toujours préciser quel type d'acteur a accès à quel cas. Pour cela, on représente simplement un personnage avec un nom selon le profil d'acteur, et on le relie aux cas auxquels il a directement accès. Pour reprendre notre diagramme précédent :
Tu sais maintenant ce qu'il te reste à faire ?
Ajouter les cas d'utilisation pour l'opérateur de maintenance du distributeur ?
Tout à fait, disons qu'il n'a que deux cas qui sont :
- l'arrêt du distributeur
- la réinitialisation du distributeur
Les autres opérations qu'il réalise, comme ajouter des billets, sont manuelles et ne sont pas des fonctionnalités du distributeur. Pour plus de clarté, on va séparer dans un autre diagramme. Je te laisse t'en occuper.
Voilà, mais il n'y a quasiment rien, c'est vraiment utile de le faire ?
C'est indispensable, car ces diagrammes vont définir les différentes fonctionnalités et droits d'accès de ton système. Si tu ne prévois pas ces cas, aussi simples soient-ils, ils ne seront pas prévus dans ton système, et l'opérateur de maintenance ne pourra alors rien faire.
Il reste un type d'acteur particulier dont je ne t'ai pas encore parlé aussi, les systèmes.
Mais ce n'est pas déjà le système que l'on définit avec le diagramme ?
Si, mais un système peut aussi faire appel à d'autres systèmes dont il a besoin. Pour prendre un exemple simple, un système de navigation par GPS va avoir un ensemble de fonctionnalités, comme la recherche d'une adresse et d'un itinéraire entre la position actuelle et la destination.
Mais c'est souvent un autre système qui va se charger de la géolocalisation, afin de récupérer la position actuelle. Dans ce cas, le GPS utilisera ce que l'on appelle une API, c'est à dire un service conçu dans un autre système et qui retourne les informations dont on peut avoir besoin.
Généralement on aura tendance à placer les acteurs système à droite du diagramme et les acteurs utilisateur à gauche du diagramme, mais sache que ce n'est pas une règle formelle, plutôt une habitude.
On va le représenter exactement de la même façon qu'un acteur, mais on précisera « system » au dessus de son nom. Si tu as bien compris, je te laisse réaliser un diagramme très simple de GPS, avec les fonctionnalités recherche d'adresse et recherche d'itinéraire, dont ce dernier fera appel à l'acteur API GéoLocalisation.
Facile !
Parfait, je vois que tu as tout compris.
Et il nous reste quoi à faire maintenant ?
Rien, nous avons finit pour le diagramme de cas d'utilisation, mais il faut bien garder à l'esprit que ce type de diagramme demande beaucoup de rigueur, même s'ils sont simples à faire, un oubli de cas ou une mauvaise extension peuvent avoir des impacts très importants sur le fonctionnement de l'application. Il s'agit surtout de bien réfléchir à ce que l'on souhaite réaliser, le cas d'utilisation n'est qu'un moyen graphique de représenter le résultat de cette réflexion.
Je retiens, j'y ferais particulièrement attention à l'avenir. J'ai terminé cette partie