Instructions: Cas d'utilisation
Un cas d'utilisation décrit ce que fait le système pour répondre à une exigence. Ces instructions expliquent comment identifier et développer des cas d'utilisation.
Relations
Description principale

Explication

Cette définition contient plusieurs mots clés :

  • Instance de cas d'utilisation. La séquence à laquelle se réfère la définition est en réalité un flux d'événements spécifique à travers le système, dénommé également instance. Plusieurs flux d'événements sont possibles et ils peuvent avoir de très nombreuses similarités. Pour rendre intelligible un modèle de cas d'utilisation, vous devez regrouper des flux d'événements similaires dans un même cas d'utilisation. L'identification et la description d'un cas d'utilisation reviennent à identifier et à décrire un groupe de flux d'événements apparentés.
  • Actions effectuées par le système. Ceci signifie que le système fournit le cas d'utilisation. Un acteur communique avec une instance de cas d'utilisation du système.
  • Un résultat avec valeur observable. Vous pouvez affecter une valeur à un cas d'utilisation exécuté avec succès. Un cas d'utilisation doit garantir qu'un acteur puisse effectuer une tâche associée à une valeur identifiable. Ce point est très important afin de déterminer le niveau de granularité adéquat d'un cas d'utilisation. Le niveau adéquat se réfère à l'élaboration de cas d'utilisation qui ne soient pas trop petits. Dans certaines circonstances, vous pouvez utiliser un cas d'utilisation en tant qu'unité de planification dans une organisation comprenant des individus qui sont des acteurs du système.
  • Actions. Une action désigne une procédure de calcul ou algorithmique. Elle est appelée lorsque l'acteur fournit au système un signal ou lorsque le système reçoit un événement temporel. Une action peut impliquer la transmission de signaux à l'acteur l'ayant appelée, ou à d'autres. Une action est dite atomisée, ce qui signifie qu'elle doit être effectuée intégralement ou pas du tout.
  • Acteur spécifique. L'acteur est crucial afin d'identifier le cas d'utilisation approprié, en particulier car il vous aide à éviter des cas d'utilisation trop volumineux. Prenez pour exemple un outil de modélisation visuelle. Cette application comporte en fait deux acteurs : un développeur, lequel développe des systèmes en s'appuyant sur l'outil en question, et un administrateur système qui gère cet outil. Chacun de ces acteurs a ses propres exigences sur le système et nécessite, par conséquent, son propre ensemble de cas d'utilisation.

La fonctionnalité d'un système est définie par divers cas d'utilisation, chacun d'eux représentant un flux d'événements spécifique. La description d'un cas d'utilisation définit ce qui se produit dans le système lorsque le cas d'utilisation est employé.

Diagramme décrit dans la légende.

Depuis un guichet automatique, le client peut, par exemple, retirer de l'argent d'un compte, transférer des fonds dans un compte ou vérifier son solde. Ces fonctions correspondent à des flux que vous pouvez représenter par des cas d'utilisation.

Chaque cas d'utilisation a sa propre tâche à effectuer. L'agrégation des cas d'utilisation couvre toutes les manières possibles d'utiliser le système. Vous pouvez vous faire une idée de la tâche d'un cas d'utilisation tout simplement en observant son nom.

Rechercher des cas d'utilisation

Les questions suivantes s'avèrent utiles pour l'identification de cas d'utilisation :

  • Pour chaque acteur identifié, quelles sont les tâches dans lesquelles le système serait impliqué ?
  • L'acteur doit-il être avisé de l'occurrence de certains événements dans le système ?
  • L'acteur sera-t-il amené à informer le système de changements extérieurs soudains ?
  • Le système procure-t-il à l'entreprise le comportement correct ?
  • Toutes les fonctionnalités peuvent-elles être exécutées par les cas d'utilisation identifiés ?
  • Quels sont les cas d'utilisation qui assureront le support et la maintenance du système ?
  • Quelles informations doivent être modifiées ou crées dans le système ?

Les cas d'utilisation ci-dessous sont fréquemment oubliés étant donné qu'ils ne représentent pas les fonctions principales du système :

  • Démarrage et arrêt du système.
  • Maintenance du système. Par exemple, ajout d'utilisateurs et configuration de profils utilisateurs.
  • Maintenance des données stockées sur le système. Le système est élaboré, par exemple, pour fonctionner en parallèle avec un système antérieur et les données doivent être synchronisées entre les deux.
  • Fonctionnalité requise pour modifier le comportement du système. Par exemple, une fonctionnalité dédiée à l'ajout de nouveaux états.

Si vous avez développé un modèle de cas d'utilisation métier et un modèle d'analyse métier, ces artefacts sont un bon point de départ pour l'identification de cas d'utilisation.

Comment évolue un cas d'utilisation

Lors des itérations préliminaires de l'élaboration, seuls quelques cas d'utilisation (ceux considérés comme significatifs du point de vue de l'architecture) sont quelque peu détaillés au delà de leur brève description. Dressez d'abord les contours du cas d'utilisation (étape par étape) avant d'approfondir ses détails. Cet aperçu étape par étape doit être votre première tentative pour définir la structure du flux d'événements du cas d'utilisation (voir Flux d'événements - Structure ci-dessous). Commencez toujours par le flux de base du cas d'utilisation. Après avoir dégagé un consensus sur les grandes lignes du flux de base, vous pouvez lui associer des flux secondaires.

Lorsque l'élaboration tire à sa fin, tous les cas d'utilisation dont une description détaillée a été prévue doivent avoir été achevés.

Tous les cas d'utilisation sont-ils décrits en détail ?

Certains cas d'utilisation dans votre modèle sont d'une telle simplicité qu'une description détaillée de leur flux d'événements n'est pas nécessaire, un aperçu étape par étape est suffisant. Le critère déterminant dans cette décision est l'unanimité des lecteurs sur la signification du cas d'utilisation et la satisfaction des concepteurs et des testeurs sur le niveau de détail fourni par le format étape par étape. Les cas d'utilisation décrivant une entrée unique ou l'extraction de certaines données du système entrent dans cette catégorie.

La portée d'un cas d'utilisation

Il est souvent difficile de décider si un jeu d'interactions utilisateur-système, ou une boîte de dialogue, constitue un seul ou plusieurs cas d'utilisation. Prenez le cas d'une machine à recycler. Le client insère dans la machine des articles consignés, comme par exemple des canettes, des bouteilles et des cageots. Quand il a terminé, il appuie sur un bouton et un reçu est imprimé. Il peut alors échanger ce reçu pour de l'argent.

L'insertion d'un article consigné constitue-t-elle un cas d'utilisation et la réclamation du reçu, un autre cas, ou s'agit d'un seul et même cas d'utilisation ? Deux actions sont impliquées, mais l'une sans l'autre n'a guère de valeur pour le client. La boîte de dialogue globale (insertions et obtention du reçu) est celle qui génère une valeur pour le client (et qui lui semble logique). Par conséquent, l'intégralité de la boîte de dialogue, de l'insertion du premier article consigné jusqu'à la pression sur le bouton et l'obtention du reçu, représente un cas d'utilisation complet.

De plus, vous voudrez conserver les deux actions ensemble afin de pouvoir les examiner en même temps, les modifier et les tester conjointement, rédiger des manuels les concernant et, en général, les gérer comme une unité indissociable. Ceci est d'autant plus évident dans le cas de systèmes de grande envergure.

Réalisation des cas d'utilisation

Un cas d'utilisation décrit les événements survenant dans le système lorsqu'un acteur interagit avec le système afin d'exécuter le cas d'utilisation. Le cas d'utilisation ne décrit pas comment le système s'acquitte de ses fonctions en interne en termes d'objets en collaboration. Cet aspect est illustré par les résultats du cas d'utilisation.

Exemple :

Dans l'exemple du téléphone, le cas d'utilisation indiquerait, entre autres, que le système émet un signal lorsque le combiné est soulevé, reçoit une numérotation, localise le destinataire, émet une sonnerie sur son téléphone, établit la communication, transmet des données vocales, et ainsi de suite.

Dans un système d'exécution, une instance d'un cas d'utilisation ne correspond à aucun objet spécifique du modèle d'implémentation (une instance d'une classe dans le code, par exemple). Elle correspond, par contre, à un flux d'événements spécifique appelé par l'acteur et exécuté sous forme de séquence d'événements sur un ensemble d'objets. En d'autres termes, les instances de cas d'utilisation correspondent à des instances d'objets implémentés échangeant des communications. Ceci est dénommé réalisation du cas d'utilisation. Fréquemment, les mêmes objets participent à la réalisation de plusieurs cas d'utilisation. Par exemple, les cas d'utilisation Dépôt et Retrait dans un système bancaire peuvent tous deux faire appel à un même objet compte pour leur réalisation. Ceci ne signifie pas que les deux cas d'utilisation communiquent mais seulement qu'ils utilisent le même objet dans leur réalisation.

Vous pouvez visualiser un flux d'événements comme composé de plusieurs sous-flux, qui, agglomérés, produisent le flux total des événements. Vous pouvez réutiliser la description d'un sous-flot dans le flux d'événements d'autres cas d'utilisation. Les sous-flux décrits dans le flux d'événements d'un cas d'utilisation peuvent être communs à ceux d'autres cas d'utilisation. Dans la conception, les mêmes objets doivent exécuter ce comportement commun pour tous les cas d'utilisation pertinents ; autrement dit, un seul ensemble d'objets doit être en charge de ce comportement, quel que soit le cas d'utilisation.

Exemple :

Dans un système de guichet automatique, le sous-flot initial est identique dans le flux d'événements des cas d'utilisation Retrait d'argent et Vérification du solde. Ce flux débute par la vérification de l'identité sur la carte et du code d'accès personnel du client.

Multiplicité des instances possibles d'un cas d'utilisation

Une instance de cas d'utilisation peut suivre un nombre presque illimité, mais néanmoins dénombrable, de cheminements possibles. Ces chemins représentent les choix ouverts à l'instance du cas d'utilisation dans la description de son flux d'événements. Le chemin choisi dépend des événements. Les types d'événements comprennent :

  • Entrée effectuée par un acteur. Un acteur peut sélectionner, par exemple, l'étape suivante parmi plusieurs options.

Exemple :

Dans le cas d'utilisation Recyclage d'articles du système Machine à recycler, le client dispose toujours de deux options : retour d'un nouvel article consigné ou obtention d'un reçu pour les articles retournés.

  • Vérification des valeurs ou des types d'un objet ou d'un attribut interne. Par exemple, le flux d'événements peut varier si une valeur est supérieure ou inférieure à une valeur donnée.

Exemple :

Dans le cas d'utilisation Retrait d'argent dans un système de guichet automatique, le flux d'événements sera différent si le retrait demandé est supérieur au solde du compte du client. L'instance du cas d'utilisation suivra donc un cheminement différent.

Simultanéité d'instances de cas d'utilisation

Des instances de plusieurs cas d'utilisation, tout comme plusieurs instances d'un même cas d'utilisation, peuvent opérer simultanément si le système le permet. Lors de la modélisation de cas d'utilisation, vous pouvez présumer que plusieurs instances de cas d'utilisation pourront être actives simultanément sans générer de conflit. Le modèle de conception est supposé résoudre ce problème, dans la mesure où la modélisation de cas d'utilisation ne décrit pas le fonctionnement des éléments. Une manière d'appréhender ce problème consiste à supposer qu'une seule instance de cas d'utilisation est active et que l'exécution de cette instance représente une action atomisée. Dans la modélisation de cas d'utilisation, la "machine interprète" est considérée comme étant infiniment rapide, de sorte que la sérialisation d'instances de cas d'utilisation ne pose aucun problème.

Nom

Chaque cas d'utilisation doit se voir affecter un nom indiquant l'effet de son interaction avec l'acteur ou les acteurs concernés. Le nom peut être composé de plusieurs mots pour faciliter sa compréhension. Chaque cas d'utilisation doit porter un nom unique.

Exemple :

Ci-dessous figurent des variations du nom pour le cas d'utilisation Recyclage d'articles de l'exemple Machine à recycler :

  • Réceptionner des articles consignés
  • Réception d'articles consignés
  • Retourner des articles consignés
  • Articles consignés

Brève description

La brève description du cas d'utilisation doit refléter son objet. Lors de la rédaction de cette description, référez-vous aux acteurs impliqués dans le cas d'utilisation et au glossaire, et définissez de nouveaux concepts, le cas échéant.

Exemple :

Ci-dessous figurent des exemples de brève description des cas d'utilisation Recyclage d'articles et Ajout d'un nouveau type de bouteille dans le système Machine de recyclage :

Articles de recyclage : l'utilisateur utilise cette machine pour comptage automatique des articles retournés (bouteilles, canettes et cageots) et obtention d'un reçu. Le reçu doit être encaissé à une caisse enregistreuse (machine).

Ajout d'un nouveau type de bouteille : de nouveaux types de bouteilles peuvent être ajoutés à la machine en la démarrant en 'mode d'apprentissage' et en insérant 5 échantillons, tout comme si vous retourniez des articles. De cette manière, la machine peut mesurer les bouteilles et apprendre à les identifier. Le gestionnaire doit stipuler le montant du remboursement pour le nouveau type de bouteille.

Flux d'événements - Contenu

Le Flux d'événements d'un cas d'utilisation héberge les informations les plus importantes dérivées des travaux de modélisation de ce cas. Il doit décrire le flux d'événements du cas d'utilisation de manière assez explicite pour être aisément compréhensible à des personnes extérieures. Rappelez-vous que le flux d'événements doit présenter ce que réalise le système et non pas comment il a été conçu afin d'effectuer le comportement requis.

Instructions pour le contenu du flux d'événements :

  • Décrivez comment le cas d'utilisation est déclenché et comment il se termine.
  • Décrivez quelles sont les données échangées entre l'acteur et le cas d'utilisation.
  • Ne décrivez pas en détails l'interface utilisateur, sauf si cette description est nécessaire pour comprendre le comportement du système. Par exemple, il est souvent bénéfique d'utiliser un ensemble restreint de termes spécifiques à Internet quand vous savez de prime abord qu'il s'agira d'une application en ligne. Sinon, vous courez le risque que le texte du cas d'application soit perçu comme excessivement abstrait. Les mots à inclure dans votre terminologie pourraient être "naviguer", "visualiser", "hyperlien", "page", "soumettre" et "navigateur". Cependant, il n'est pas recommandé d'y inclure des références à des "cadres" ou à des "pages Web" de manière à émettre des hypothèses quant à leurs limites respectives, sujet qui relève d'une décision critique au niveau de la conception. 
  • Décrivez le flux d'événements et non pas seulement la fonctionnalité. Pour ce faire, commencez la description de chaque action par "Lorsque l'acteur...".
  • Ne décrivez que les événements relevant du cas d'utilisation et non pas ce qui se produit dans d'autres cas d'utilisation ou en dehors du système.
  • Eviter d'utiliser une terminologie vague.
  • Détaillez le flux d'événements et répondez à toutes les questions qui se posent. Rappelez-vous que les concepteurs de tests devront utiliser ce texte afin d'identifier des scénarios de test.

Si vous avez utilisé certains termes dans d'autres cas d'utilisation, veillez à utiliser exactement les mêmes dans le cas en cours et assurez-vous que leur signification est identique dans les deux contextes. Pour gérer la terminologie commune, placez ces termes dans un glossaire.

Flux d'événements - Structure Haut de la page

Les deux parties principales du flux d'événements sont le flux de base des événements et le flux d'événements alternatifs. Le flux de base doit couvrir ce qui se produit "normalement" lors de l'exécution du cas d'utilisation. Les flux d'événements alternatifs couvrent des comportements à caractère facultatif ou exceptionnel par rapport au comportement normal, ainsi que des variantes du comportement normal. Vous pouvez assimiler les flux d'événements alternatifs à des "détours" du flux de base, certains y retournant et d'autres entraînant l'arrêt de l'exécution du cas d'utilisation.

Diagramme décrit dans la légende.

Structure typique du flux d'événements. La flèche droite représente le flux d'événements de base et les courbes représentent des cheminements alternatifs par rapport au flux normal. Ces derniers peuvent revenir au flux d'événements de base alors que d'autres peuvent provoquer l'arrêt du cas d'utilisation.

Le flux d'événements de base et les flux alternatifs doivent encore être structurés en étapes ou sous-flux. Ce faisant, votre objectif principal doit être la lisibilité du texte (voir aussi la section Flux d'événements - Style ci-dessous). En règle générale, un sous-flot doit être un segment de comportement au sein d'un cas d'utilisation, avec un objectif clair et "atomisé" dans le sens où vous devez exécuter toutes les actions décrites ou aucune. Vous pouvez avoir besoin de plusieurs niveaux de sous-flux, mais évitez d'y recourir si possible car ceci rend votre texte plus complexe et plus difficile à saisir. Vous pouvez illustrer la structure du flux d'événements à l'aide d'un diagramme d'activités, voir Instruction pour le produit : Diagramme d'activités dans le cas d'utilisation.

De par sa nature, ce type de rédaction, structuré en sous-sections consécutives, suggérera au lecteur que les sous-flux sont séquentiels. Pour dissiper les malentendus, spécifiez toujours si l'ordre des sous-flux est fixe ou non. Des considérations de ce type sont souvent associées aux éléments suivants :

  • Règles métier. Par exemple, l'utilisateur doit recevoir des habilitations avant que le système ne lui permette d'accéder à certaines données.
  • Conception de l'interface utilisateur. Par exemple, le système ne devrait pas appliquer une séquence donnée de comportements qui serait intuitive pour certains utilisateurs, mais pas pour d'autres.

Pour clarifier dans quelles circonstances un flux d'événements alternatif peut s'intégrer à la structure, vous devez décrire les éléments suivants pour chaque "détour" du flux de base des événements :

  • A quel endroit du flux d'événements de base le comportement alternatif peut être inséré.
  • La condition devant être remplie pour le lancement du comportement alternatif.
  • Comment et où le flux d'événements de base reprend son cours, ou comment le cas d'utilisation s'arrête.

Exemple :

Il s'agit d'un sous-flot alternatif du cas d'utilisation Retour d'articles dans le système Machine de recyclage.

2.1. Bouteille coincée

Si au cours de la section 1.5, Insertion d'articles consignés, une bouteille se coince dans l'ouverture, ce problème est détecté par les capteurs adjacents et par le sas de calibrage. La bande transporteuse s'arrête et la machine émet un signal d'avertissement à l'opérateur. La machine attend alors que l'opérateur lui indique que le problème a été corrigé. La machine poursuit ensuite son opération à la section 1.9 du flux de base.

Dans l'exemple ci-dessus, le flux d'événements alternatif est inséré à un emplacement spécifique dans le flux de base. Certains flux alternatifs peuvent être insérés à plusieurs endroits, voire à un endroit quelconque du flux de base.

Exemple :

Il s'agit d'un sous-flot alternatif du cas d'utilisation Retour d'articles dans le système Machine de recyclage.

2.2. Panneau frontal retiré

Si quelqu'un retire le panneau frontal de la machine à recycler, le compactage des canettes est désactivé. Le compactage des canettes est inhibé dès lors que le panneau est déposé. L'extraction du panneau déclenche également une alarme pour alerter l'opérateur. Lorsque le panneau est refermé, la machine reprend son opération au stade où elle s'était arrêtée dans le flux de base des événements.

Vous pouvez être tenté, si le flux d'événements alternatif est très simple, de le décrire uniquement dans la section du flux de base des événements (à l'aide d'une construction informelle du type : "if-then-else"). Evitez cette pratique. Un trop grand nombre d'alternatives rend difficile à repérer le comportement normal. De plus, l'inclusion de cheminements alternatifs dans la section du flux de base des événements rappelle un "pseudo-code" plutôt que du texte et rend la lecture de ce dernier plus ardue.

En général, l'extraction de fragments du flux d'événements et leur description séparée améliorent la lisibilité du flux de base des événements, ainsi que la structure du cas d'utilisation et de son modèle. Vous pouvez modéliser ces parties extraites en tant que :

  • Flux d'événements alternatif au sein du cas d'utilisation de base, s'il s'agit d'une simple variante, option ou exception par rapport au flux d'événements de base.
  • Inclusion explicite dans le cas d'utilisation de base (voir Instruction pour le produit : Relation d'inclusion) si vous souhaitez l'encapsuler pour réutilisation éventuelle dans d'autres cas d'utilisation.
  • Inclusion implicite dans le cas d'utilisation de base (voir Instruction pour le produit : Relation d'extension), si le flux d'événements de base du cas d'utilisation de base est complet, c'est-à-dire comporte un début et une fin. La nature du flux d'extension doit être telle que vous préfériez la masquer dans la description du cas d'utilisation de base pour le rendre moins complexe.
  • Sous-flot du flux d'événements de base, éventuellement en tant qu'option supplémentaire, si aucune des alternatives ci-dessus ne s'applique. Par exemple, dans le cas d'utilisation Maintenance des informations sur les employés, des sous-flux distincts peuvent exister pour ajouter, supprimer ou modifier des informations sur les employés.

Flux d'événements - Style Haut de la page

Vous pouvez décrire les cas d'utilisation en vous basant sur plusieurs styles. L'exemple ci-après illustre la description du flux d'événements de base du cas d'utilisation Administration d'instruction d'après trois styles différents, se distinguant principalement par le degré de formalité adopté. Le premier style, présenté dans l'exemple 1 ci-dessous, est recommandé car il est facile à comprendre et l'ordre dans lequel surviennent les événements est vraiment évident. Le texte est divisé en sous-sections nominatives et numérotées. Ces numéros facilitent les références à une sous-section. Les noms des sous-sections permettent au lecteur de se faire un aperçu rapide du flux d'événements en parcourant le texte et en ne lisant que les en-têtes.

Dans l'exemple 2 ci-dessous, la description du flux d'événements ne parvient pas à clarifier l'ordre dans lequel ils se présentent. Si vous rédigez dans ce style, les lecteurs et vous-même risquez d'ignorer des éléments importants concernant le système.

L'exemple 3 ci-dessous illustre encore un autre style qui peut s'avérer utile si vous avez des difficultés à exprimer clairement la séquence d'événements. Le pseudo-code utilisé dans ce style est plus précis mais le texte est difficile à lire et à assimiler si vous ne disposez pas du bagage technique, surtout si vous désirez capter rapidement le flux d'événements.

Exemple 1 :
1.1. Début du cas d'utilisation

Ce cas d'utilisation débute lorsque l'acteur Opérateur demande au système de créer une instruction de mesure. Le système extrait alors tous les acteurs de type Elément réseau, leurs objets de mesure et les fonctions de mesure correspondantes disponibles pour l'opérateur en question. Les éléments réseau disponibles sont les éléments en fonctionnement et ceux auxquels l'opérateur est autorisé à accéder. La disponibilité des fonctions de mesure dépend de ce qui a été configuré pour un type spécifique d'objet de mesure.

1.2. Configuration de l'instruction de mesure

Le système permet à l'acteur Opérateur de sélectionner les éléments réseau à mesurer et présente les objets de mesure disponibles pour ces éléments. Le système permet à l'opérateur de sélectionner les objets voulus et les fonctions de mesure à appliquer à chaque objet.

Le système permet à l'opérateur de saisir un commentaire textuel sur l'instruction de mesure.

L'opérateur demande au système de finaliser l'instruction de mesure. Le système répond en générant un nom unique pour l'instruction de mesure et en définissant des valeurs par défaut pour le moment, la fréquence et la durée de la mesure. Les valeurs par défaut sont uniques pour chaque opérateur. Le système permet ensuite à l'opérateur de modifier ces valeurs par défaut.

1.3. Initialisation de l'instruction

L'opérateur demande au système d'initialiser l'instruction de mesure. Le système enregistre alors l'identité de l'opérateur à l'origine de la création de l'instruction de mesure, sa date de création et son statut en tant que "Planifiée".

1.4. Fin du cas d'utilisation

Le système confirme à l'opérateur l'initialisation de l'instruction de mesure qui peut ensuite être consultée par les autres acteurs.


Description d'un cas d'utilisation : Sous ce style, le texte est facile à lire et le flux d'événements est facile à suivre. Visez ce style dans vos descriptions.

Exemple 2 :
Les demandeurs peuvent créer des instructions de collecte de données de mesure des éléments réseau.

Le système affectera un nom unique à l'instruction tout comme des valeurs par défaut indiquant la durée et le moment de la mesure, ainsi que sa fréquence de répétition. Le demandeur pourra modifier ces valeurs.

Le demandeur doit encore spécifier quelle fonction de mesure, quel élément réseau et quels objets de mesure sont pertinents. Le demandeur peut également ajouter un commentaire personnel à l'instruction.

Lorsque les informations nécessaires ont été définies, une nouvelle instruction est créée et initialisée avec les attributs définis, le nom de son créateur et sa date de création. Le statut de l'instruction est défini à "planifiée". (Les valeurs de statut possibles sont : Planifiée, En cours d'exécution, Complétée, Annulée ou Erronée.)

L'interface utilisateur est alors avisée de la création d'une nouvelle instruction et reçoit la référence de cette instruction pour pouvoir l'afficher.


Description d'un cas d'utilisation : Ce style est lisible mais le flux des événements n'est pas clair.

Exemple 3 :

'Administrer l'instruction' (Identité de l'utilisateur)
REPEAT
    <= 'Afficher le menu Administrer l'instruction'
    IF ( => 'Créer une instruction' (fonction de mesure,
    élément réseau et objet de mesure)) THEN
    Le système trouve un nom unique et des valeurs par défaut pour le moment et
la durée d'exécution de la mesure. 
<= 'Afficher l'instruction' (Attributs par défaut)
REPEAT
    => 'Editer l'instruction' (Attribut à changer, nouvelle valeur pour l'attribut)
    <= 'Mettre à jour l'écran' (Nouveaux attributs)
UNTIL (Tous les attributs ont été définis)
REPEAT
    IF ( => 'Editer l'instruction' (Attribut à changer, nouvelle valeur pour l'attribut))
THEN <= 'Mettre à jour l'écran' (Nouveaux attributs)
ELSIF ( => 'Enregistrer l'instruction' (Identité de l'ordre, attributs)) THEN
    L'instruction est créée et initialisée dans le système avec
    ses attributs définis, le nom de son créateur,
    sa date de création et le statut 'planifiée'.
    <= 'Nouvelle instruction créée' (L'instruction)
ENDIF
UNTIL (=> 'Quitter')
    ENDIF
UNTIL 'Quitter Administrer l'instruction'

Description du cas d'utilisation : Le rédacteur a choisi ici un style formel faisant appel à du pseudocode. Ce style ne permet pas de comprendre rapidement les étapes du processus mais peut être utile si le flux d'événements est difficile à capturer avec précision.

Flux d'événements - Exemple

La description complète du flux d'événements du cas d'utilisation Administration d'instruction, y compris de ses flux alternatifs, pourrait avoir l'apparence suivante :

1. Flux de base des événements

1.1. Début du cas d'utilisation

Ce cas d'utilisation débute lorsque l'acteur Opérateur demande au système de créer une instruction de mesure. Le système extrait alors tous les acteurs de type Elément réseau, leurs objets de mesure et les fonctions de mesure correspondantes disponibles pour l'opérateur en question. Les éléments réseau disponibles sont les éléments en fonctionnement et ceux auxquels l'opérateur est autorisé à accéder. La disponibilité des fonctions de mesure dépend de ce qui a été configuré pour un type spécifique d'objet de mesure.

1.2. Configuration de l'instruction de mesure

Le système permet à l'acteur Opérateur de sélectionner les éléments réseau à mesurer et présente les objets de mesure disponibles pour ces éléments. Le système permet à l'opérateur de sélectionner les objets voulus et les fonctions de mesure à appliquer à chaque objet.

Le système permet à l'opérateur de saisir un commentaire textuel sur l'instruction de mesure.

L'opérateur demande au système de finaliser l'instruction de mesure. Le système répond en générant un nom unique pour l'instruction de mesure et en définissant des valeurs par défaut pour le moment, la fréquence et la durée de la mesure. Les valeurs par défaut sont uniques pour chaque opérateur. Le système permet ensuite à l'opérateur de modifier ces valeurs par défaut.

1.3. Initialisation de l'instruction

L'opérateur demande au système d'initialiser l'instruction de mesure. Le système enregistre alors l'identité de l'opérateur à l'origine de la création de l'instruction de mesure, sa date de création et son statut en tant que "Planifiée".

1.4. Fin du cas d'utilisation

Le système confirme à l'opérateur l'initialisation de l'instruction de mesure qui peut ensuite être consultée par les autres acteurs.

2. Flux d'événements alternatifs

2.1. Aucun élément réseau disponible

Si à l'étape 1.1, Début du cas d'utilisation, il s'avère que pour cet opérateur, aucun élément réseau n'est disponible pour mesure, le système avise l'opérateur concerné. Le cas d'utilisation se termine alors ici.

2.2. Aucune fonction de mesure disponible

Si à l'étape 1.2, Configuration de l'instruction de mesure, aucune fonction de mesure n'est disponible pour les éléments réseau sélectionnés, le système informe l'opérateur et lui permet de sélectionner d'autres éléments.

2.3. Annulation de l'instruction de mesure

Le système permet à l'opérateur d'annuler toutes les actions à n'importe quel point de l'exécution du cas d'utilisation. Le système retourne à l'état où il se trouvait avant le début du cas d'utilisation et termine le cas d'utilisation.

Exigences particulières Haut de la page

La section Exigences particulières d'un cas d'utilisation permet de décrire toutes les exigences du cas d'utilisation qui ne sont pas couvertes par le flux d'événements. Il s'agit d'exigences non fonctionnelles qui exerceront une influence sur le modèle de conception. Voir aussi la discussion sur les exigences non fonctionnelles dans la rubriqueInstruction pour le produit : Modèle de cas d'utilisation. Vous pouvez organiser ces exigences en catégories comme : Facilité d'utilisation, Fiabilité, Performances et Substituabilité, mais elles sont en général si peu nombreuses que l'utilité d'un tel regroupement est marginale.

Exemple :

Dans le système Machine de recyclage, une exigence spéciale du 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 %.

Préconditions et postconditions

Les notions de précondition et de postcondition peuvent vous être utiles pour clarifier la façon dont le flux d'événements débute et se termine. Ne les utilisez toutefois que si les destinataires du cas d'utilisation perçoivent qu'elles apportent une contribution.

Diagramme décrit dans la légende.

Une précondition désigne l'état requis du système et de son environnement avant que le cas d'utilisation ne puisse débuter. Une postcondition spécifie les états dans lequel peut se trouver le système lorsque se termine le cas d'utilisation.

Prenez en compte les points suivants :

  • Les états décrits par les préconditions ou les postconditions doivent être des états que l'utilisateur peut constater. "L'utilisateur s'est connecté au système" ou "L'utilisateur a ouvert le document" sont des exemples d'états observables.
  • Une précondition est une contrainte affectant le début d'un cas d'utilisation. Il ne s'agit pas de l'événement qui déclenche le cas d'utilisation.
  • Une précondition pour un cas d'utilisation ne concerne pas un unique sous-flot bien que vous puissiez définir des préconditions et des postconditions au niveau du sous-flot.
  • Une postcondition pour un cas d'utilisation doit se concrétiser quelque soient les flux alternatifs exécutés ; il ne suffit pas qu'elle se concrétise pour le seul flux principal. Vous devez couvrir les situations d'échec dans la postcondition en spécifiant "L'action est complétée et, en cas d'échec, l'action n'est pas effectuée", plutôt que simplement "L'action est complétée".
  • Lorsque vous utilisez des postconditions de pair avec des relations d'extension, vous devez veiller à ce que le cas d'utilisation d'extension n'insère pas de sous-flot violant la postcondition instaurée dans le cas d'utilisation de base.
  • Les postconditions peuvent constituer un outil puissant pour décrire les cas d'utilisation. Vous devez d'abord définir ce que le cas d'utilisation est censé réaliser, c'est-à-dire la postcondition. Vous pouvez ensuite décrire comment atteindre cette condition - le flux d'événements requis.

Exemple :

Précondition pour le cas d'utilisation Retrait d'argent dans le système Guichet automatique : Le client détient une carte personnelle adaptée au lecteur de cartes, un numéro d'identification personnel lui a été remis et il est enregistré dans le système bancaire.

Postcondition pour le cas d'utilisation Retrait d'argent dans le système Guichet automatique : A l'issue du cas d'utilisation, tous les journaux de transaction et de comptes sont équilibrés, la communication avec le système bancaire a été réinitialisée et la carte du client lui a été restituée.

Points d'extension

Un point d'extension offre au cas d'utilisation la possibilité de déboucher sur une extension. Il dispose d'un nom et d'une liste de références vers un ou plusieurs emplacements dans le flux d'événements du cas d'utilisation. Le point d'extension peut référencer un emplacement unique entre deux étapes de comportement du cas d'utilisation ou un ensemble d'emplacements discontinus.

L'utilisation de points d'extension nominatifs permet de séparer la spécification du comportement du cas d'utilisation d'extension de celle des données internes du cas de base. Le cas d'utilisation de base peut être altéré, ou son ordre modifié, sans impact sur le cas d'utilisation d'extension tant que les noms des points d'extension demeurent inchangés. De même, vous n'avez pas à charger dans le texte décrivant le flux d'événements du cas d'utilisation de base tous les détails concernant une extension possible du comportement. Voir aussi Instruction pour le produit : Relation d'extension.

Exemple :

Dans un système téléphonique, le cas d'utilisation Appel peut être étendu par le cas d'utilisation hypothétique Affichage de l'identité de l'appelant. Ce service, souvent dénommé "ID de l'appelant", est optionnel et peut avoir été souscrit ou non par l'abonné appelé. La description du point d'extension dans le cas d'utilisation Appel pourrait avoir la forme suivante :

Nom: Afficher l'identité

Emplacement: Après la section 1.9 Sonnerie du téléphone de l'abonné appelé.

Diagrammes de cas d'utilisation

Vous pouvez illustrer la relation entre un cas d'utilisation, les acteurs et d'autres cas d'utilisation à l'aide d'un diagramme (et pour les cas inhabituels, plusieurs diagrammes), dont le cas d'utilisation concerné sera propriétaire. Cette approche est utile lorsque le cas d'utilisation met en jeu plusieurs acteurs ou comporte des relations avec plusieurs autres cas d'utilisation. Un diagramme de ce type est, par nature, "local" puisqu'il envisage le modèle de cas d'utilisation depuis la perspective d'un seul cas et n'est pas destiné à expliquer des phénomènes généraux concernant le modèle global de cas d'utilisation. Voir aussi Instruction pour le produit : Diagramme de cas d'utilisation.