Principes et conseils : Modèle de cas d'utilisation
Rubriques
Un modèle de cas d'utilisation modélise les fonctions prévues du système et son environnement et constitue un contrat entre le client et les développeurs.
Les cas d'utilisation servent de fil unificateur tout au long du développement du système. Ce même modèle de cas d'utilisation est le résultat de la méthodologie Exigences et sert d'entrée aux méthodologies Analyse et Conception et Test.
Le diagramme ci-dessous illustre un fragment d'un modèle de cas d'utilisation du système Machine de recyclage.

Diagramme de cas d'utilisation illustrant un exemple de modèle de cas d'utilisation avec acteurs et cas d'utilisation.
Un système peut être modélisé de nombreuses manières, chacune pouvant servir un dessein différent. Toutefois, l'objet le plus important d'un modèle de cas d'utilisation est de communiquer au client ou à l'utilisateur final le comportement du système. Par conséquent, le modèle doit être facile à comprendre.
Les utilisateurs et tout autre système pouvant interagir avec le système constituent ses acteurs. Comme ils représentent des utilisateurs du système, les acteurs aident à le délimiter et à clarifier ce qu'il est supposé accomplir. Les cas d'utilisation sont développés sur la base des besoins des acteurs. Ceci garantit que le système final corresponde aux attentes des utilisateurs.
Les acteurs tout comme les cas d'utilisation sont identifiés à partir des exigences des clients et des utilisateurs potentiels en tant que source cruciale d'information. Lorsqu'ils sont identifiés, ces cas d'utilisation et acteurs devraient être décrits succinctement. Avant que les cas d'utilisation ne soient décrits en détail, le modèle de cas d'utilisation devrait être inspecté par le client afin de vérifier que tous les acteurs et cas d'utilisation ont bien été isolés et qu'ensemble, ils sont en mesure de répondre aux attentes du client.
Dans une environnement de développement itératif, vous devez sélectionner un sous-ensemble de cas d'utilisation à détailler dans chaque itération. Voir aussi Activité :
Hiérarchisation des cas d'utilisation.
Lorsque les acteurs et les cas d'utilisation ont été identifiés, le flot d'événements de chaque cas d'utilisation est décrit en détail. Ces descriptions indiquent comment le système interagit avec les acteurs et ce qu'il effectue dans chaque cas d'utilisation.
Finalement, le modèle de cas d'utilisation terminé (y compris les descriptions des cas d'utilisation) est passé en revue et les développeurs et clients l'utilisent pour convenir de ce que le système doit effectuer.
Il n'est pas rare de voir dégénérer le modèle de cas d'utilisation en décomposition fonctionnelle du système. Pour éviter cette situation, confirmez l'absence des symptômes suivants :
- Cas d'utilisation trop "petits", signalant que la description du flot d'événements ne comprend qu'une ou quelques phrases.
- Cas d'utilisation trop "nombreux", indiquant que leur nombre est un multiple de 100 au lieu d'un multiple de 10.
- Noms de cas d'utilisation qui sont des constructions du genre "Effectuez cette opération sur ces données spécifiques" ou "Exécutez cette fonction sur ces données spécifiques". Par exemple, "Saisie du numéro d'identification personnel à un guichet automatique" ne devrait pas modélisé en tant que cas d'utilisation distinct puisque personne n'utiliserait le système à cette seule fin. Un cas d'utilisation est composé d'un flot d'événements complet dont le résultat a une valeur pour l'utilisateur.
Pour éviter une décomposition fonctionnelle, assurez-vous que le modèle de cas d'utilisation aide bien à répondre aux questions de ce type :
- Quel est le contexte du système ?
- Pourquoi le système a-t-il été construit ?
- Que cherche à obtenir l'utilisateur lorsqu'il utilise le système ?
- Quelle est la valeur ajoutée du système pour ses utilisateurs ?
Il est facile de percevoir que les cas d'utilisation sont particulièrement appropriés pour capturer les exigences fonctionnelles d'un système. Mais qu'en est-il des exigences non fonctionnelles ? Quelles sont-elles et où sont-elles capturées ?
Les exigences non fonctionnelles sont souvent cataloguées comme des impératifs de convivialité, fiabilité, performance et substituabilité (voir aussi Concepts :
Exigences). Il s'agit fréquemment d'exigences spécifiant une nécessité de conformité avec des exigences légales ou réglementaires. Elles peuvent aussi provenir de contraintes de conception liées au système d'exploitation utilisé, à l'environnement de la plateforme, à des questions de compatibilité ou aux normes d'applications en vigueur. En règle générale, une exigence ne permettant qu'une seule option de conception doit être considérée comme une contrainte de conception.
Beaucoup d'exigences non fonctionnelles s'appliquent à un cas d'utilisation isolé et sont recensées dans les propriétés de ce cas. Elles sont alors capturées dans le flot d'événements du cas d'utilisation ou en tant qu'exigence spéciale de ce cas (voir Principes et conseils : Cas d'utilisation).
Exemple :
Dans le système Machine de recyclage, une exigence non fonctionnelle sur le cas d'utilisation Retour d'articles consignés pourrait être la suivante :
La machine doit être capable de reconnaître les articles consignés avec une fiabilité supérieure à 95 %.
Les exigences non fonctionnelles s'appliquent souvent à l'ensemble du système. Les exigences de cet ordre sont recensées dans les spécifications supplémentaires (voir Artefact :
Spécifications supplémentaires).
Exemple :
Dans le système Machine de recyclage, une exigence non fonctionnelle s'appliquant au système global pourrait être la suivante :
La machine ne pourra servir qu'un seul utilisateur à la fois.
Une difficulté majeure consiste à déterminer quel niveau de détail constitue "le début et la fin" d'un cas d'utilisation. Où débutent les fonctionnalités et où commencent les cas d'utilisation, et où se terminent les cas d'utilisation et débute la conception ? L'on dit souvent que les cas d'utilisation ou les exigences logicielles doivent stipuler "ce que" fait le système mais non pas "comment" il s'y prend. Examinez le graphique suivant :

La destination d'une personne est bien souvent le point de départ d'une autre.
En fonction de votre expérience, vous utiliserez un contexte différent pour déterminer ce qui relève du "quoi" et ce qui relève du "comment". Ceci doit être pris en compte lorsque vous devez décider si un détail doit être exclu ou non du modèle de cas d'utilisation.
Il convient de distinguer entre cas d'utilisation concrets et abstraits. Un cas d'utilisation concret
est déclenché par un acteur et constitue un flot d'événements complet.
"Complet" signifie ici qu'une instance du cas d'utilisation effectue l'opération entière appelée par l'acteur.
Un cas d'utilisation abstrait n'est jamais instancié en soi.
Les cas d'utilisation abstraits sont inclus dans (voir Principes et conseils :
Relation d'inclusion), développent (voir Principes et conseils :
Relation d'extension), ou généralisent (voir Principes et conseils :
Généralisation de cas d'utilisation) d'autres cas d'utilisation. Lorsqu'un cas d'utilisation concret est déclenché, une instance du cas est créée. Cette instance affiche aussi le comportement spécifié par ses cas d'utilisation abstraits associés. Par conséquent, aucune instance séparée n'est créée depuis les cas d'utilisation abstraits.
La distinction entre les deux est importante puisque les acteurs ne "voient" et ne déclenchent dans le système que des cas d'utilisation concrets.
Un cas d'utilisation abstrait doit être signalé par un nom en italiques.
Exemple :

Le cas d'utilisation Création de tâche est inclus dans le cas d'utilisation Enregistrement de commande. Création de tâche représente un nom de cas d'utilisation abstrait.
Dans le système Gestion d'entrepôt, le cas d'utilisation abstrait Création de tâche est inclus dans le cas Enregistrement de commande. Lors du déclenchement du cas Enregistrement de commande, une instance de ce cas est créée, laquelle en plus de suivre le flot d'événements correspondant, suit également le flot décrit dans le cas d'utilisation inclus, Création de tâche. Création de tâche n'est jamais exécutée seule mais toujours dans le cadre d'Enregistrement de commande (ou d'autres cas d'utilisation dans lesquelles elle est inclue). Création de tâche constitue donc un cas d'utilisation abstrait.
On peut mentionner trois raisons principales de structurer le modèle de cas d'utilisation :
- Afin de faciliter la compréhension des cas d'utilisation.
- Afin d'externaliser un comportement commun décrit dans plusieurs cas d'utilisation
- Afin de faciliter la maintenance du modèle de cas d'utilisation.
Vous ne pouvez pas procéder d'emblée à la structuration. Il ne mène à rien de structurer les cas d'utilisation tant que vous n'avez pas d'autres informations sur leur comportement qu'une brève description d'une phrase. Vous devez avoir établi au moins un aperçu pas à pas du flot d'événements des cas d'utilisation pour garantir que vos décisions se fondent sur une compréhension suffisamment précise de leur comportement.
Les cas d'utilisation peuvent être structurés d'après trois types de relations. Vous utiliserez ces relations afin de factoriser les portions de cas d'utilisation pouvant être réutilisées dans d'autres cas d'utilisation, celles qui représentent des spécialisations et celles qui constituent des options à l'utilisation du cas. le cas d'utilisation qui représente la modification est dénommé cas d'utilisation en addition.
Le cas d'utilisation modifié est dénommé cas d'utilisation de base.
- Si une portion de cas d'utilisation de base représente une fonction dont le cas d'utilisation ne dépend que du résultat et non pas de la méthode utilisée pour produire ce résultat, vous pouvez l'externaliser dans un cas d'utilisation en addition. L'addition est insérée explicitement dans le cas d'utilisation de base à l'aide d'une relation d'inclusion.
Voir aussi Principes et conseils : Relation d'inclusion.
- Si une portion de cas d'utilisation de base est facultative, ou n'est pas requise pour comprendre l'objet principal du cas d'utilisation, vous pouvez l'externaliser dans un cas d'utilisation en addition afin de simplifier la structure du cas de base. L'addition est insérée implicitement dans le cas d'utilisation de base à l'aide d'une relation d'extension. Voir aussi Recommandations : Relation d'extension.
- Si des cas d'utilisation ont des points communs au niveau de leur comportement et de leur structure et des objets similaires, leurs parties communes peuvent être externalisées dans un cas d'utilisation de base (parent) qui sera hérité par des cas d'utilisation en addition (enfants).
Les cas d'utilisation enfants peuvent insérer un nouveau comportement ou modifier un comportement existant dans la structure qu'ils héritent du cas d'utilisation parent. Voir aussi Principes et conseils :
Généralisation de cas d'utilisation.
Vous pouvez utiliser une généralisation d'acteur pour illustrer comment les acteurs constituent des spécialisations d'un autre. Voir aussi Principes et conseils : Généralisation entre acteurs.
Exemple :
Cet exemple concerne une partie du modèle de cas d'utilisation d'un système Gestion de commandes.
Il est utile de séparer un client ordinaire d'un client sur Internet dans la mesure où leurs propriétés son sensiblement différentes. Cependant, comme un client sur Internet affiche toutes les propriétés d'un client, l'on peut dire qu'il constitue une spécialisation de Client, indiquée à l'aide d'une généralisation d'acteur.
Les cas d'utilisation concrets dans ce diagramme sont Commande téléphonique (déclenché par l'acteur Client) et Commande par Internet (déclenché par l'acteur Client Internet). Ces cas d'utilisation sont tous deux des variations du cas d'utilisation plus général Passage de commande, qui dans cet exemple est abstrait. Le cas d'utilisation Demande de catalogue représente un segment de comportement facultatif ne faisant pas partie de l'objet principal de Passage de commande. Il a été externalisé dans un cas d'utilisation abstrait afin de simplifier le cas d'utilisation Passage de commande. Le cas d'utilisation Fourniture des données client représente un segment de comportement externalisé étant donné qu'il constitue une fonction distincte dont seul le résultat affecte le cas d'utilisation Passage de commande. Fourniture des données client peut aussi être réutilisé dans d'autres cas d'utilisation. Demande de catalogue et Fourniture de données client représentent des cas d'utilisation abstraits dans cet exemple.

Cet exemple présente une partie du modèle de cas d'utilisation d'un système Gestion de commandes.
Le tableau ci-dessous présente une comparaison plus détaillée des trois relations différentes de cas d'utilisation :
Question |
Extension |
Inclusion |
Généralisation |
quelle est la direction de la relation ? |
Le cas d'utilisation en addition référence le cas d'utilisation de base. |
Le cas d'utilisation de base référence le cas d'utilisation en addition. |
Le cas d'utilisation en addition (enfant) référence le cas d'utilisation de base (parent). |
La relation autorise-t-elle la multiplicité ? |
oui, du côté de l'addition. |
Non. Si vous voulez inclure plus d'une fois le segment de comportement, vous devez le stipuler dans le cas d'utilisation de base. |
Non. |
La relation comporte-t-elle une condition ? |
Oui. |
Non. Si vous voulez exprimer une condition pour l'inclusion, vous devez la mentionner explicitement dans le cas d'utilisation de base. |
Non. |
Le cas d'utilisation en addition est-il abstrait ? |
Fréquemment, mais pas nécessairement. |
Oui. |
Rarement, mais peut l'être. |
Le cas d'utilisation de base est-il modifié par l'addition ? |
L'extension modifie implicitement le comportement du cas d'utilisation de base. |
L'inclusion modifie explicitement l'effet du cas d'utilisation de base. |
Si le cas d'utilisation de base (parent) est instancié, il n'est pas affecté par l'enfant.
Pour acquérir les effets de l'addition, le cas d'utilisation en addition (enfant) doit être instancié. |
Le cas d'utilisation de base doit-il être complet et doté d'une signification ? |
Oui. |
En conjonction avec les additions, oui. |
S'il est abstrait, non. |
Le cas d'utilisation en addition doit-il être complet et doté d'une signification ? |
Non. |
Non. |
En conjonction avec le cas d'utilisation de base (parent), oui. |
Le cas d'utilisation en addition peut-il accéder aux attributs du cas de base ? |
Oui. |
Non. L'inclusion est encapsulée et ne "voit" qu'elle-même. |
Oui, par les mécanismes d'héritage normaux. |
Le cas d'utilisation de base peut-il accéder aux attributs du cas en addition ? |
Non. Le cas de base doit être correctement construit en absence de l'addition. |
Non. Le cas de base ne connaît que l'effet de l'addition. L'addition est encapsulée. |
Non. Le cas d'utilisation de base (parent) doit, en ce sens, être correctement formé en l'absence de l'addition (enfant). |
Un autre aspect de l'organisation du modèle de cas d'utilisation en vue de faciliter sa compréhension consiste à grouper les cas d'utilisation en packages. Le modèle de cas d'utilisation peut être organisé d'après une hiérarchie de packages de cas d'utilisation, avec des "feuilles" qui représentent des acteurs ou des cas d'utilisation. Voir aussi Principes et conseils : Package de cas d'utilisation.

Ce graphique illustre la hiérarchie du modèle de cas d'utilisation. Les flèches indiquent un propriétaire possible.
L'exécution de chaque cas d'utilisation inclut une communication avec un ou plusieurs acteurs. Une instance de cas d'utilisation est toujours déclenchée par un acteur requérant une action du système. Ceci implique que chaque cas d'utilisation doit comporter des associations de communication avec des acteurs. La raison de cette règle est de contraindre le système à fournir uniquement la fonctionnalité requise par les utilisateurs, et rien de plus.
Des cas d'utilisation qui ne sont appelés par aucun utilisateur indiquent une anomalie au niveau du modèle de cas d'utilisation ou des exigences.
il existe toutefois quelques exceptions à cette règle :
- Si un cas d'utilisation est abstrait (non instanciable séparément), son comportement peut ne pas inclure d'interaction avec un acteur quelconque. Dans ce cas, il n'y aura aucune association de communication du cas abstrait avec des acteurs.
- Un cas d'utilisation enfant dans une relation de généralisation ne requiert pas d'acteur associé si le cas parent décrit toutes les communications avec les acteurs.
- Un cas d'utilisation de base dans une relation d'inclusion ne requiert pas d'acteur associé si le cas d'utilisation d'inclusion décrit toutes les communications avec les acteurs.
- Un cas d'utilisation peut être déclenché selon un calendrier (par exemple, une fois par semaine ou une fois par jour), ce qui signifie que l'horloge système elle-même est le déclencheur. Cette horloge est interne au système et le cas d'utilisation n'est pas déclenché par un acteur mais par un événement système interne. Si aucune autre interaction avec un acteur ne se produit dans le cas d'utilisation, il ne comporte aucune association avec des acteurs.
Cependant, pour plus de clarté, vous pouvez utiliser l'acteur fictif, "Horloge" pour illustrer le déclenchement du cas d'utilisation dans vos diagrammes.
Cette description du modèle de cas d'utilisation doit :
- Stipuler quels sont les cas d'utilisation primordiaux du système (la raison pour laquelle il est construit).
- Récapituler les données techniques importantes du système.
- Délimiter le système et ce qu'il n'est pas censé faire.
- Récapituler l'environnement du système, par exemple, les plateformes cibles et les logiciels existants.
- Décrire les séquences d'exécution habituelles des cas d'utilisation dans le système.
- Spécifier les fonctionnalités non couvertes par le modèle de cas d'utilisation.
Exemple :
Description générale du modèle de cas d'utilisation Machine de recyclage :
Ce modèle comporte trois acteurs et trois cas d'utilisation. Le cas d'utilisation central est Recyclage d'articles, qui représente l'objet principal de cette machine.
Les cas d'utilisation auxiliaires sont les suivants :
-
Impression d'état journalier, qui permet à un opérateur d'obtenir un état sur le nombre d'articles recyclés.
-
Administration d'article consigné, qui permet à un opérateur de modifier la valeur de remboursement d'un type d'article consigné ou d'ajouter de nouveaux types.
|