Principes et conseils : Cas d'utilisation
Rubriques
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 flot d'événements spécifique à travers le système, dénommé également instance. Plusieurs flots 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 flots 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 flots 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 du système et nécessite, par conséquent, un ensemble distinct de cas d'utilisation.
La fonctionnalité du système est définie par divers cas d'utilisation, chacun d'eux représentant un flot 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é .

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 flots 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.
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 devra-t-il informer le système de changements externes 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-elles ê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.
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. Cette opération devrait constituer votre première tentative de définition de la structure du flot d'événements dans le cas d'utilisation (voir Flot d'événements - Structure, ci-dessous). Commencez toujours par le flots de base du cas d'utilisation. Après avoir dégagé un consensus sur les grandes lignes du flots de base, vous pouvez lui associer des flots alternatifs.
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.
Certains cas d'utilisation dans votre modèle seront d'une telle simplicité qu'une description détaillée de leur flot d'événements serait superflue. Leurs grandes lignes, étape par étape, seront suffisantes. 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.
Il est souvent difficile de déterminer si un ensemble 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 cannettes, bouteilles et 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 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.
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. Il ne décrit pas comment le système s'acquitte de ses fonctions en interne en terme 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 flot 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 imaginer un flot d'événements comme consistant de plusieurs sous-flots qui, agglomérés, produisent le flot total des événements. Vous pouvez réutiliser la description d'un sous-flot dans le flot d'événements d'autres cas d'utilisation. Les sous-flots décrits dans le flot d'événements d'un cas d'utilisation peuvent être communs à ceux d'autres cas d'utilisation. Dans la conception du système, les mêmes objets devraient 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, quelque soit le cas d'utilisation.
Exemple :
Dans un système de guichet automatique, le sous-flot initial est identique dans le flot d'événements des cas d'utilisation Retrait d'argent et Vérification du solde. Ce flot débute par la vérification de l'identité sur la carte et du code d'accès personnel du client.
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 ses flots 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. Le flot d'événements, par exemple, peut diverger selon qu'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 flot 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.
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 être infiniment rapide, de sorte que la numérotation consécutive d'instances de cas d'utilisation ne soulève pas de problème.
Chaque cas d'utilisation doit se voir affecter un nom indiquant l'effet de son interaction avec l'acteur ou les acteurs concernés. Il peut devoir ê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
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, cannettes 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.
Le flot 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 flot 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 flot 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.
Principes et conseils pour le contenu du flot 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. Vous pourriez ainsi inclure dans votre terminologie des termes comme "naviguer", "parcourir", "lien hypertexte"
"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 cruciale au niveau de la conception.
- Décrivez le flot 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.
- Evitez d'utiliser une terminologie floue comme "par exemple", "etc. "
et "information".
- Détaillez le flot d'événements et répondez à toutes les questions "quoi".
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.
Les deux parties principales du flot d'événements sont le flot de base des événements et les flot d'événements alternatifs. Le flot de base doit couvrir ce qui se produit "en temps normal" lors de l'exécution du cas d'utilisation. Les flots d'événements alternatifs recouvrent des comportements à caractère facultatif ou exceptionnel, ainsi que des variantes du comportement normal. Vous pouvez assimiler les flots d'événements alternatifs à des
"détours" du flot de base, certains y retournant et d'autres entraînant l'arrêt de l'exécution du cas d'utilisation.

Structure typique du flot d'événements. Les flèches droites représentent le flot de base des événements et les courbes, des cheminements alternatifs par rapport au flot normal. Ces derniers peuvent revenir au flot de base des événements ou provoquer l'arrêt du cas d'utilisation.
Tant le flot de base des événements que les flots alternatifs doivent encore être structurés en étapes ou sous-flots. Ce faisant, votre objectif principal doit être la lisibilité du texte
(voir aussi la section Flot
d'événements - Style, ci-après). 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 las actions décrites ou aucune. Vous pouvez avoir besoin de plusieurs niveaux de sous flots, mais évitez d'y recourir si possible car ceci rend votre texte plus complexe et plus difficile à saisir.
Vous pouvez illustrer la structure du flot d'événements à l'aide d'un diagramme d'activités (voir Principes et conseils : 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-flots sont séquentiels. Pour dissiper les malentendus, spécifiez toujours si l'ordre des sous-flots 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 flot d'événements alternatif peut s'intégrer à la structure, vous devez décrire les éléments suivants pour chaque "détour" du flot de base des événements :
- A quel endroit du flot d'événements de base le comportement alternatif peut être inséré.
- La condition devant être remplie pour le lancement du flot d'événements alternatif.
- Comment et où le flot d'événements de base reprend son cours, ou comment le cas d'utilisation s'arrête.
Exemple :
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 flot de base.
Dans l'exemple ci-dessus, le flot d'événements alternatif est inséré à un emplacement spécifique dans le flot de base. Certains flots alternatifs peuvent être insérés à plusieurs endroits, voire à un endroit quelconque du flot de base.
Exemple :
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 cannettes est désactivé. Le compactage des cannettes 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 flot de base des événements.
Vous pouvez être tenté, si le flot d'événements alternatif est très simple, de le décrire uniquement dans la section du flot 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 flot 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 flot d'événements et leur description séparée améliorent la lisibilité du flot 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 :
- Flot d'événements alternatif au sein du cas d'utilisation de base, s'il s'agit d'une simple variante, option ou exception du flot d'événements de base.
- Inclusion explicite dans le cas d'utilisation de base (voir Principes et conseils :
Relation d'inclusion) si vous désirez l'encapsuler pour réutilisation éventuelle dans d'autres cas d'utilisation .
- Inclusion implicite dans le cas d'utilisation de base (voir Principes et conseils :
Relation d'extension), si le flot d'événements de base est complet, c'est-à-dire comporte un début et une fin définis. La nature du flot 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 flot 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-flots distincts peuvent exister pour ajouter, supprimer ou modifier des informations sur les employés.
Vous pouvez décrire les cas d'utilisation en vous basant sur plusieurs styles. L'exemple ci-après illustre la description du flot 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 sous lequel surviennent les événements est immédiatement é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 flot d'événements en parcourant le texte et en ne lisant que ces en-têtes.
Dans l'exemple 2 ci-dessous, la description du flot 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 flot d'é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, leur objets mesurés et les fonctions de mesure correspondantes disponibles pour l'opérateur en question. Les éléments réseau disponibles sont ceux en opération et 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 mesuré.
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 mesurés disponibles pour ces éléments. Les 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 enregistrera ensuite l'identité de l'opérateur, la date de création et le statut "planifié" de l'ordre de mesure.
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 du cas d'utilisation : Sous ce style, le texte est facile à lire et le flot d'événements est facile à suivre. Visez ce style dans vos descriptions.
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 mesurés 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" (ses valeurs possibles sont : Planifiée,
En cours d'exécution, Complétée, Annulée et 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 du cas d'utilisation : Ce style est lisible mais le flot des événements n'est pas clair.
'Administration d'instruction' (Identité utilisateur)
REPEAT
<='Affichage menu administration d'instruction'
IF (=> 'Création d'instruction' (Fonction de mesure,
élément réseau, objet mesuré)) THEN
Système recherche un nom unique, des valeurs par défaut pour le moment et
la durée d'exécution de la mesure.
<= 'Affichage instruction' (Attributs par défaut)
REPEAT
=> 'Modification instruction' (Attribut à modifier, Nouvelle valeur de l'attribut)
<= 'Mise à jour de l'écran' (Nouveaux attributs)
UNTIL (Tous les attributs ont été définis)
REPEAT
IF (=> 'Modification instruction' (Attribut à modifier, Nouvelle valeur de l'attribut))
THEN <= 'Mise à jour de l'écran' (Nouveaux attributs)
ELSIF (=> 'Enregistrement instruction' (Identité instruction, Attributs)) THEN
L'instruction est créée et initialisée dans le système avec les
attributs définis, le nom de son créateur,
sa date de création et le statut 'planifiée'.
<= 'Nouvelle instruction créée' (Instruction)
ENDIF
UNTIL (=> 'Quitter')
ENDIF
UNTIL 'Quitter administration 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 flot d'événements est difficile à rendre avec précision.
La description complète du flot d'événements du cas d'utilisation Administration d'instruction, y compris de ses flots alternatifs, pourrait avoir l'apparence suivante :
1. Flot 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, leur objets mesurés et les fonctions de mesure correspondantes disponibles pour l'opérateur en question. Les éléments réseau disponibles sont ceux en opération et 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 mesuré.
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 mesurés 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 enregistrera ensuite l'identité de l'opérateur, la date de création et le statut "planifié" de l'ordre de mesure.
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. Flot 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.
La section Exigences spéciales d'un cas d'utilisation permet de décrire toutes les exigences du cas d'utilisation qui ne sont pas couvertes par le flot 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 rubrique
Principes et conseils : 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 %.
Les notions de précondition et de postconditionpeuvent vous être utiles pour clarifier comment le flot 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.

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 soit le flot alternatif exécuté ; il ne suffit pas qu'elle se concrétise pour le seul flot 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, c'est-à-dire le flot 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.
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 flot 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 flot d'événements du cas d'utilisation de base tous les détails concernant une extension possible du comportement. Voir aussi Principes et conseils : 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, dénommé parfois"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 identité
Emplacement : Après section 1.9 : Sonnerie du téléphone de l'abonné appelé.
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 cette sorte 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 Principes et conseils : Diagramme de cas d'utilisation.
|