Analyse de cas d’utilisation – Une étude de cas

Quels sont les cas d’utilisation ?

Un  cas d’utilisation  est une technique de capture et de documentation des exigences qui peut être écrite en texte brut pour décrire de manière narrative les actions et les interactions des participants utilisant le système. Enfin, la fonctionnalité du système doit répondre à l’objectif pour lequel les parties prenantes utilisent le système.

Avant d’utiliser du texte pour documenter une description de cas d’utilisation, nous pouvons d’abord utiliser un diagramme de cas d’utilisation pour mettre en évidence le but de l’acteur utilisant le système. Avec la représentation graphique, vous pouvez rapidement comprendre l’ensemble de l’image à partir d’une vue à vol d’oiseau. Définir la portée du système (limites du système) et identifier les principaux objectifs des acteurs (appelés cas d’utilisation) qui prennent en charge l’utilisation des fonctionnalités ou des services du système.

Les diagrammes de cas d’utilisation sont bons pour la communication d’équipe, et c’est dans la nature humaine : utiliser des graphiques est souvent préférable à la communication par des mots.

Une fois que l’équipe a une compréhension initiale et un consensus sur l’apparence générale du système, l’analyste des exigences ouvre l’ovale – cas d’utilisation et décrit le processus de dialogue entre les acteurs et le système dans un format correct et facile à lire.

Augmentez progressivement la précision des cas d’utilisation du plus simple au plus complexe. Ne vous embourbez pas dans des détails compliqués au début, de peur d’investir trop d’esprit dans la mauvaise conception et la mauvaise description. Les diagrammes de cas d’utilisation aident à passer du simple au complexe et à réduire les erreurs inutiles.

Comme on peut le voir sur la figure, la portée de conception de ce système est « système de commande de livres en ligne », l’un des principaux participants utilisant ce système est « client en ligne », le but des participants utilisant ce système est « carnets de commandes ».

Les « carnets de commandes » sont le cas d’utilisation du système, et l’acteur est le « client en ligne ». Après avoir déterminé l’objectif des participants, nous enregistrerons les détails de l’objectif dans le texte narratif, c’est-à-dire enregistrerons l’interaction entre les participants et le fonctionnement du système pour atteindre l’objectif. C’est ce qu’on appelle la description de cas d’utilisation.

Le tableau suivant décrit un cas d’utilisation simple « Order des carnets ».

Origine du cas d’utilisation

Le cas d’utilisation a été publié pour la première fois par le géant du logiciel Jacobson en 1992, ce qui a eu un impact considérable sur la technologie moderne orientée objet. De plus, les spécifications UML ( Unified Modeling Language ) formulées conjointement par les soi-disant « 3 Amigos » – Booch, Jacobson et Rumbaugh et qui ont été révisées par OMG ont été incluses comme une partie importante des principales spécifications standard.

Voici les définitions de cas d’utilisation par plusieurs géants du logiciel.

  • « Un cas d’utilisation est un document narratif qui décrit la séquence de processus d’un acteur utilisant le système pour réaliser un événement » [Jacobson92].
  • « Un cas d’utilisation est un ensemble de scénarios (flux d’événements), qui sont liés à l’objectif d’utilisation commun du système » [Fowler97].
  • « Un cas d’utilisation est une séquence d’actions qu’un acteur (généralement une personne, mais peut-être une entité externe, comme un autre système) effectue au sein d’un système pour atteindre un objectif particulier » [Rosenberg99].
  • « Un cas d’utilisation est un acteur (généralement un utilisateur, mais peut-être une entité externe, comme un autre système externe), une série d’actions pour atteindre un objectif spécifique dans l’interaction avec le système interne ».

Dans le livre « The Unified Modeling Language User Guide », la définition de cas d’utilisation est donnée :

  • « Un cas d’utilisation décrit un ensemble de séquences, dans lequel chaque séquence représente l’interaction des éléments extérieurs au système (ses acteurs) avec le système lui-même (et ses abstractions clés) ».
  • « Le cas d’utilisation décrit une série de séquences, dont chacune exprime l’interaction entre les éléments extérieurs au système (participants) et le système lui-même (et ses abstractions clés). »

De la discussion ci-dessus, nous pouvons obtenir les caractéristiques liées au cas d’utilisation :

  • Un cas d’utilisation est un document narratif décrit en langage naturel (tel qu’un récit en anglais). De manière générale, un cas d’utilisation n’implique pas de graphiques ou de grammaire de langage de programmation (comme java) à décrire.
  • Le scénario décrit dans le cas d’utilisation correspond exactement à ce que les acteurs attendent pour accomplir (obtenir) leur objectif (Goal) à partir de l’interaction et de la communication avec le système.
  • Par exemple, « Acheter des articles » est exactement le but de la consommation des consommateurs :
    « Les consommateurs vérifient les biens achetés, et le caissier enregistre les biens achetés et encaisse le paiement. Une fois terminé, le consommateur repart avec la marchandise.
  • Un cas d’utilisation peut avoir un scénario normal et plusieurs scénarios d’exception. Le scénario normal décrit le processus normal d’interaction entre les participants et le système ; tandis que dans le processus d’interaction avec le système, si l’occurrence d’exceptions est prise en compte, selon la complexité de la situation, elle peut être décrite dans le « chemin alternatif » dans le scénario normal » ou elle peut être décrite dans un autre scénario pour les exceptions complexes.
  • Le système fournira une série de fonctions pour interagir avec les participants, mais les participants n’ont pas besoin de savoir ce qui se passe dans le système ou comment le faire, le système n’a qu’à renvoyer les résultats aux participants. Par conséquent, pour les participants, le système est (ou un groupe de cas d’utilisation) une boîte noire.
  • La description du cas d’utilisation met l’accent sur ce que le système doit faire (que faire), et non sur comment le faire (comment faire). Par conséquent, les détails de la mise en œuvre ne doivent pas être décrits dans la description du cas d’utilisation.
  • L’acteur vient directement au système d’exploitation. Dans le diagramme de cas d’utilisation, bien que l’acteur soit représenté par une icône représentant un « bonhomme allumette », le participant n’est pas nécessairement une personne réelle . Le participant peut également être un système externe et il peut avoir besoin d’obtenir des informations de ce système.

Autres diagrammes UML

Leave a Reply

Votre adresse e-mail ne sera pas publiée.