C'est, selon pas mal de processus de développement, le premier diagramme que l'on utilise lors du développement d'un système. Son but est d'exprimer, d'une manière simple, le rôle d'un système, ce qu'il doit faire et les éléments qui interagissent avec lui. C'est généralement utilisé en phase de recueil des exigences, par interview des utilisateurs. C'est également un diagramme qui est simple et permet d'avoir des retours de non-informaticiens.

Voici un exemple de diagramme :

diagramme de use case

La première chose que l'on voit est un ensemble de use case (les patates). Un use case est une fonctionnalité du système modélisé, sur laquelle on pourra plus tard accrocher un scénario plus complexe. Traditionnellement, on les nommera avec des termes "d'action", car le système FAIT quelque chose dans ce cas.

Ensuite, on a des acteurs. Un acteur est un élément externe au système, mais qui interagit avec le système. On pense tout de suite aux utilisateurs en tant que personnes, mais ce n'est pas que ça. Par exemple un capteur mécanique ou un autre système peuvent parfaitement être un acteur. Enfin, signalons qu'il est généralement inutile de faire des liens entre les acteurs, on modélise le système, pas ce qui est autour. Dans l'exemple ci-dessus, inutile de faire hériter modérateur d'utilisateur, ça ne regarde pas mon système.

Enfin dernier cas, ce rectangle qui traine sur le diagramme. C'est ce que l'on appelle le "system boundary", la frontière du système, qui marque les limites du système à modéliser. Il existe également des liens entre les uses cases, destiner à extraire certain sous-ensemble que l'on invoquera lors de plusieurs uses cases. Il y a deux type de liens, <<includes>> qui permet de faire sortir une sous-partie d'un cas d'utilisation (taper son mot de passe est l'exemple bateau), et <<extends>> qui permet de faire de "l'héritage" de use case.

Pour terminez, n'oubliez pas que les dessins sont bien gentils, mais largements insuffisants. Tout cas d'utilisation se doit d'être bien documenté, avec des explication précises, des préconditions (pour poster, un contributeur ne doit pas être banni) et être validé par des cycles de revue.