Accueil

Les cas d'utilisation, concepts avancés

 

Introduction

Etablir des relations entre acteurs

Etablir des relations entre cas d'utilisation

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.

Inclusion

Considérons les cas d'utilisation intitulés "retrait d'argent" et "consultation du solde". Le premier est associé au scénario principal suivant :

Nom

Retrait d'argent

Scénario principal

  1. le client introduit sa carte
  2. le distributeur vérifie la validité de la carte auprès du système informatique
  3. le client saisit son code secret
  4. le distributeur vérifie le code
  5. le client choisit l'opération "retrait d'argent"
  6. ...

Quant au second, il est associé au scénario principal suivant :

Nom

Consultation du solde

Scénario principal

  1. le client introduit sa carte
  2. le distributeur vérifie la validité de la carte auprès du système informatique
  3. le client saisit son code secret
  4. le distributeur vérifie le code
  5. le client choisit l'opération "consultation du solde"
  6. ...

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 :

Nom

Identification

Scénario principal

  1. le client introduit sa carte
  2. le distributeur vérifie la validité de la carte auprès du système informatique
  3. le client saisit son code secret
  4. le distributeur vérifie le code

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 :

Nom

Retrait d'argent

Scénario principal

  1. identification (voir le cas d'utilisation "identification")
  2. le client choisit l'opération "retrait d'argent"
  3. ...

Et pour le cas d'utilisation "consultation du solde", on peut définir le scénario principal qui suit :

Nom

Consultation du solde

Scénario principal

  1. identification (voir le cas d'utilisation "identification")
  2. le client choisit l'opération "consultation du solde"
  3. ...

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.

Extension

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.

Nom

Retrait d'argent

Scénario principal

  1. identification (voir le cas d'utilisation "identification")
  2. le client choisit l'opération "retrait d'espèces"
  3. le client spécifie la somme à retirer
  4. le distributeur demande au système informatique de débiter le compte
  5. le distributeur rend la carte
  6. le client prend la carte
  7. le distributeur fournit les billets
  8. le client prend les billets

Nom

Retrait d'argent avec reçu

Scénario principal

  1. identification (voir le cas d'utilisation "identification")
  2. le client choisit l'opération "retrait d'espèces"
  3. le client demande un reçu
  4. le client spécifie la somme à retirer
  5. le distributeur demande au système informatique de débiter le compte
  6. le distributeur rend la carte
  7. le client prend la carte
  8. le distributeur fournit les billets
  9. le client prend les billets
  10. le distributeur fournit le reçu
  11. le client prend le reçu

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.

Nom

Retrait d'argent

Scénario principal

  1. identification (voir le cas d'utilisation "identification")
  2. le client choisit l'opération "retrait d'espèces"

Point d'extension : A

  1. le client spécifie la somme à retirer
  2. le distributeur demande au système informatique de débiter le compte
  3. le distributeur rend la carte
  4. le client prend la carte
  5. le distributeur fournit les billets
  6. le client prend les billets

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.

Nom

Retrait d'argent avec reçu

Scénario principal

Etend le cas d'utilisation "retrait d'argent"

Au point d'extension A :

  1. le client demande un reçu

Au point d'extension B :

  1. le distributeur fournit le reçu
  2. le client prend le reçu

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.

Généralisation

  1. identification (voir le cas d'utilisation "identification")
  2. le client choisit l'opération "retrait d'espèces"
  3. le client spécifie la somme à retirer
  4. le distributeur demande au système informatique de débiter le compte
  5. le distributeur rend la carte
  6. le client prend la carte
  7. le distributeur fournit les billets
  8. le client prend les billets
  1. identification (voir le cas d'utilisation "identification")
  2. le client choisit l'opération "retrait de timbres"
  3. le distributeur demande au système informatique de débiter le compte
  4. le distributeur rend la carte
  5. le client prend la carte
  6. le distributeur fournit les timbres
  7. le client prend les timbres
  1. identification (voir le cas d'utilisation "identification")
  2. le client choisit l'opération de retrait
  3. le distributeur demande au système informatique de débiter le compte
  4. le distributeur rend la carte
  5. le client prend la carte
  6. le distributeur fournit ce qu'a demandé le client
  7. le client le prend

Conseils

Termes anglophones

Français Anglais
Acteur Actor
Cas d'utilisation Use case