Lorsque l'on commence à décrire textuellement les cas d'utilisation et plus particulièrement lorsqu'on s'attache à écrire les scénarios principaux, on se rend compte bien souvent que l'on est obligé de répéter un certain nombre d'étapes. Si on raisonne en terme d'interface homme-machine, c'est souvent le signe qu'un acteur utilise la même partie de l'interface lors d'utilisations différentes du système.
UML permet de définir un certain nombre de relations entre cas d'utilisation afin d'éviter ces redondances. Nous allons les découvrir au cours de cette partie.
Considérons les cas d'utilisation intitulés "retrait d'argent" et "consultation du solde". Le premier est associé au scénario principal suivant :
Retrait d'argent
Quant au second, il est associé au scénario principal suivant :
Consultation du solde
Nous pouvons constater que dans les deux cas, le client doit avant tout s'identifier. Cela se caractérise par la présence de quatres étapes en tête de chaque scénario principal ; nous pouvons regretter cette redondance d'autant plus que seul le résultat final de l'identification compte : ce qui importe c'est que le distributeur ait validé notre identité et non pas comment il l'a validée.
Afin d'éviter cette répétition, nous pouvons introduire un nouveau cas d'utilisation que nous intitulerons "identification" et que nous définirons de la façon suivante :
Identification
Il ne nous reste plus qu'à indiquer dans la description des autres cas d'utilisation que ceux-ci incluent l'identification. Par exemple, pour le "retrait d'argent", on peut définir le scénario principal suivant :
Retrait d'argent
Et pour le cas d'utilisation "consultation du solde", on peut définir le scénario principal qui suit :
Consultation du solde
Nous pouvons constater qu'introduire un nouveau cas d'utilisation et l'inclure dans les autres cas d'utilisation a permis de simplifier la rédaction des descriptions qui leur sont associées. Qu'apporte une telle simplification ? Tout d'abord la documentation sera moins épaisse tout en exprimant exactement la même information ; et, personnellement, plus le volume de la documentation est important moins j'ai envie de la lire ! Ensuite, Si une erreur a été commise dans le scénario de la procédure d'identification, il ne faudra la corriger qu'une seule fois.
Graphiquement, une telle inclusion se caractérise par un lien de dépendance portant le nom "include" entre guillemets comme l'indique le diagramme ci-dessous :
Nous pourrions aussi remarquer que le cas d'utilisation "identification" n'a pas de sens en soi, ie qu'aucun client n'utilisera le distributeur simplement pour saisir son code secret. Aussi, on peut définir ce cas d'utilisation comme étant abstrait, ie qu'on ne le réalise jamais en tant que tel mais toujours au sein d'un autre cas d'utilisation. On exprime le caractère abstrait d'un cas d'utilisation en indiquant son nom en italique :
Pour conclure, on utilise une relation d'inclusion lorsqu'une série d'étapes dont seul le résultat importe est répétée dans les scénarios de plusieurs cas d'utilisation.
Considérons maintenant le cas du retrait d'argent. Au cours d'un retrait, on peut demander un reçu. La question se pose de savoir comment décrire ce cas. Une des premières idées qui vient à l'esprit c'est de le traiter en tant qu'alternative au cas général, ie traiter le cas de retrait sans reçu dans le scénario principal et l'autre dans une alternative. Or nous avons dit dans le chapitre précédent que l'on devait respecter le scénario principal dans la majorité des cas, ce qui signifie que les alternatives surviennent rarement : ce qui n'est pas le cas du retrait d'argent avec reçu. Afin d'indiquer que le retrait avec reçu est une fonctionnalité importante, on peut vouloir l'associer à un cas d'utilisation spécifique. On obtient alors les scénarios qui suivent.
On peut constater (et on s'en doutait) que les deux scénarios sont très proches. Pourtant, on souhaite faire apparaitre clairement les deux cas d'utilisation. Encore une fois, UML propose une solution afin d'éviter ces redondances. Il s'agit de définir dans le cas d'utilisation le plus simple, ie le retrait d'argent sans reçu, ce que l'on appelle des points d'extension. Un point d'extension définit un endroit dans le scénario principal où l'on peut ajouter de nouvelles étapes, dans notre cas, les étapes qui permettent de demander et de récupérer le reçu. On obtient alors pour le cas d'utiisation "retrait d'argent" le scénario principal suivant.
Point d'extension : A
Point d'extension : B
Une fois les points d'extension définis, on peut décrire le cas d'utilisation "retrait d'argent avec reçu" en se basant sur le cas d'utilisation "retrait d'argent" et en introduisant des étapes supplémentaires au niveau des points d'extension. On dit alors que le cas d'utilisation "retrait d'argent avec reçu" étend le cas d'utilisation "retrait d'argent". On obtient alors le scénario simplifié suivant.
Etend le cas d'utilisation "retrait d'argent"
Au point d'extension A :
Au point d'extension B :
Graphiquement, une telle relation de dépendance se matérialise par un lien de dépendance placé entre les deux cas d'utilisation, pointant vers le cas d'utilisation étendu et portant le nom "extend" plac entre guillemets :
Dans la partie concernant l'inclusion, nous avions définit le cas d'utilisation qui était inclu dans les autres comme étant abstrait : en effet, ce cas d'utilisation n'avait de sens que lorsqu'il était inclu dans les autres. Par contre, dans cette partie, le cas d'utilisation "retrait d'argent" peut être réalisé, il n'y a donc aucune raison de le déclarer comme étant abstrait.
| Français | Anglais |
|---|---|
| Acteur | Actor |
| Cas d'utilisation | Use case |
Copyright © 2002-2012 Olivier Mangez – Tous droits réservés