Définition
L'article UML: diagrammes de classe nous a permis de comprendre comment traduire sous forme de représentations accessibles à tous l'architecture d'un programme orienté objet. Ces représentations se bornaient à décrire les objets, les classes et leurs interactions, mais pas les modes de réaction du programme modélisé à des scénarios d'utilisation. Or UML permet, par des diagrammes de cas d'utilisation, de représenter comment le système modélisé se comporte du point de vue de l'utilisateur, à savoir un acteur externe. On décrit ainsi la participation d'un acteur à un cas d'utilisation, lequel regroupe plusieurs scénarios d'utilisation du système.

Notation
D'emblée, notons que le terme "cas d'utilisation" (en anglais use case) désigne en fait un scénario d'utilisation (par exemple un acteur "client" va "consulter l'état d'une commande") et, par abus de langage, l'ensemble des scénarios d'utilisation.
Le schéma ci-dessous va nous permettre de clarifier certains concepts de la notation UML (attention: les inscriptions en bleu ne font pas partie de cette notation). D'abord la notion de "paquetage": les paquetages sont des regroupements destinés à clarifier la manière dont un modèle est subdivisé; ils peuvent contenir des sous-paquetages. Ensuite la "note", qui est un simple commentaire placé en rapport à un élément diagramme (auquel elle est attachée par une ligne en pointillé). Puis la notion de "stéréotype": un stéréotype qualifie un certain type d'information; par exemple, si une note doit être considérée comme un élément du modèle, et non un simple commentaire (en d'autres termes, si la note véhicule du contenu dans la sémantique du modèle), elle est une "contrainte". Un stéréotype est noté entre les caractères "<<" et ">>".

Mais revenons à nos cas d'utilisation: nous retrouvons sur le diagramme (purement illustratif) un acteur (il peut y en avoir plusieurs), un système (ce qui est modélisé) et donc des cas d'utilisation. Il existe des relations entre les acteurs et les cas d'utilisation au sein d'un système. Par exemple la relation entre l'acteur "client" et le cas d'utilisation "consulter l'état d'une commande" peut être désignée par "visualise".
Un cas d'utilisation peut-être en relation avec un autre de deux manières: soit il "l'utilise" (includes), soit il "l'étend" (extends). Ainsi par exemple le cas d'utilisation "consulter l'état d'une commande" utilisera peut-être les objectifs des cas d'utilisation "retrouver la commande dans la base" et "afficher l'état d'une commande"; tandis que le cas d'utilisation "afficher une facture" étendra les cas d'utilisation "afficher une facture en francs" et "afficher une facture en euros".

Compléments
La représentation sous forme de diagrammes de cas d'utilisation est bien distincte, dans ses objectifs, de la représentation sous forme de diagrammes de classes. Ces derniers décrivent l'architecture du système modélisé afin de dégager la manière dont les données sont réparties, regroupées, et collaborent, suivant une approche objet; les premiers décrivent le système modélisé tel qu'il se comporte vis à vis de l'utilisateur, afin de dégager la manière dont les données réagissent à une action et interagissent entre elles. On le voit, les deux approches ne sont que deux points de vue différents sur un même modèle, mais sont néanmoins complémentaires car elles aboutissent à des représentations très dissemblables. Ces deux approches sont statiques, dans le sens où elles ne décrivent pas le système en fonctionnement (c'est-à-dire tenant compte de la séquence des activités) mais seulement ses possibilités de fonctionnement. UML propose encore deux autres types de vues statiques: les diagrammes de composants et les diagrammes de déploiement, sur lesquels nous reviendrons.