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é.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
'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.
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.
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 %.
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.
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.
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é.
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.
|