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. Le même modèle de cas d'utilisation est le résultat de la méthodologie Recueil des exigences et sert d'entrée
aux méthodologies Analyse & Conception de 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. Cependant,
l'objectif le plus important d'un modèle de cas d'utilisation est de communiquer le comportement du système au client
ou à l'utilisateur. 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 correspond 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 un 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 flux 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 :
-
"Petits" cas d'utilisation, signalant que la description du flux d'événements ne comprend qu'une ou quelques
phrases.
-
"Nombreux" cas d'utilisation, signalant 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 avec ces données spécifiques". Par exemple, "Saisie du numéro
d'identification personnel à un guichet automatique" ne devrait pas être 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 flux
d'événements dont le résultat a une valeur pour l'acteur.
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 Concept :
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 flux d'événements du cas d'utilisation ou en tant qu'exigence spéciale de
ce cas (voir Instructions : 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 Produit : 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 ? On dit souvent que les cas d'utilisation ou les exigences logicielles doivent
stipuler "ce que" fait le système, mais 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 flux d'événements complet. "Complet" signifie 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 Instructions : Relation d'inclusion), développent (voir Instructions : Relation d'extension) ou généralisent (voir Instructions sur le produit : 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 flux d'événements correspondant, suit également le flux 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 flux d'événements du cas d'utilisation pour garantir que vos décisions se
fondent sur une compréhension suffisamment précise du 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 Instructions : 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 Instructions : 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 enfant peuvent insérer un nouveau
comportement ou modifier un comportement existant dans la structure dont ils héritent du cas d'utilisation parent.
Voir aussi Instructions sur le produit : 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 Instructions : Généralisation d'acteur.
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 Instructions : 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 un actif fictif "Horloge" pour illustrer le
déclenchement de 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 cible 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.
|