Exemples d'instructions de modélisation de cas d'utilisation
Version <n.m>
Dernière mise à jour <aaaammjj>
Historique de révision
Date |
Version |
Description |
Auteur |
|
|
|
|
|
|
|
|
1.3 Définitions, acronymes et abréviations
2. Instructions générales relatives à la modélisation de cas d'utilisation
2.2 Utilisation de la relation <<Communicates>>
2.3 Utilisation des relations <<Include>> et <<Extend>>.
2.3.1 Utilisation de la relation<<Include>>.
2.3.2 Utilisation de la relation <<Extend>>.
2.4 Utilisation de la généralisation d'acteur
2.5 Utilisation des diagrammes d'interaction
2.6 Utilisation des diagrammes d'activité
3. Comment décrire un cas d'utilisation
3.1 Instructions relatives aux acteurs
3.1.1 Chaque cas d'utilisation concret doit être en interaction avec au moins un acteur
3.1.2 Nom(s) d'acteurs intuitifs et descriptifs
3.1.3 Utilisation cohérente des noms d'acteurs
3.3 Description abrégée du cas d'utilisation
3.4 Utilisation cohérente de l'impératif
3.5 Utilisation des termes du glossaire
3.6 Utilisation des termes liés à l'action
3.6.1 Définir quand le système est chargé de proposer l'option d'action
3.6.2 Utilisation cohérente du terme dans l'ensemble du cas d'utilisation
3.7 Paragraphes distincts pour le comportement de l'acteur et celui du système
3.8 Sous-flux et flux alternatifs
3.9 Préconditions et postconditions
3.10 Utilisation de marques de réservation pour les détails manquants (à venir)
3.11 Définition des spécifications supplémentaires et références y renvoyant
3.12 Contrôle croisé avec la conception/le prototype d'interface utilisateur
3.13 Flux exceptionnels (facultatif)
Instructions de modélisation de cas d'utilisation
Cet ensemble d'instructions vise à garantir la cohérence du modèle de cas d'utilisation. Il fournit des instructions sur la manière de documenter un cas d'utilisation ainsi qu'une aide générale sur les sujets connexes posant souvent des problèmes aux spécificateurs d'exigences et autres analystes système.
Ces instructions peuvent être utilisées en l'état ou être personnalisées afin de répondre aux besoins de la plupart des projets.
Voir : Glossaire Rational Unified Process.
Aucune
Cet ensemble d'instructions est organisé en deux sections, dont la première décrit la méthode conseillée pour la modélisation des cas d'utilisation, tandis que la seconde fournit des instructions relatives au contenu du modèle de cas d'utilisation et à la désignation des éléments qui le composent.
Les cas d'utilisation doivent être écrits à l'aide du canevas fourni avec le processus Rational Unified Process, en apportant certains changements de style et de mise en forme afin de convenir aux normes documentaires qui s'appliquent pour le projet.
L'association entre un acteur et un cas d'utilisation est appelée relation Communicates. Il est recommandé de rendre cette association unidirectionnelle. En utilisant cette stratégie de modélisation, nous ferons la distinction entre :
q
Acteur actif
L'acteur est considéré comme actif dans une paire acteur-cas d'utilisation lorsque l'acteur initie (ou déclenche) l'exécution du cas d'utilisation. La flèche située sur la relation Communicates pointe vers le cas d'utilisation.
q
Acteur passif
L'acteur est considéré comme passif dans une paire acteur-cas d'utilisation lorsque le cas d'utilisation initie la communication. Les acteurs passifs sont généralement des périphériques ou des systèmes externes avec lesquels notre système doit communiquer. La flèche située sur la relation communicates pointe vers l'acteur.
Cette recommandation a son importance, car la notion d'acteur actif et passif apporte un plus au lecteur du modèle de cas d'utilisation.
Dans la première instance, il est recommandé d'éviter d'utiliser ces relations. Cette recommandation a son importance, car la capacité de ces relations à causer le désordre et la confusion en cas de mauvaise utilisation dépasse largement leur capacité de simplification du modèle de cas d'utilisation. La meilleure pratique consiste à éviter, à la base, ce type de décomposition et à envisager de recourir à ces relations à une étape ultérieure du processus. Ces relations peuvent permettre de :
1. Isoler le comportement commun à deux cas d'utilisation ou plus.
2. Isoler le comportement du cas d'utilisation de base qui n'est pas nécessaire à la compréhension de la finalité première du cas d'utilisation, car seul compte son résultat.
3. Montrer qu'il peut exister un ensemble de segments de comportement dont un ou plusieurs peuvent être insérés au niveau d'un point d'extension dans un cas d'utilisation de base.
Ces relations ne doivent toutefois être utilisées que lorsqu'elles confèrent une valeur ajoutée en contribuant à la simplification et à la gestion du modèle de cas d'utilisation.
La relation d'inclusion décrit un segment de comportement qui est inséré dans une instance de cas d'utilisation exécutant le cas d'utilisation de base. Il s'agit d'un mécanisme qui s'apparente à un sous-programme et qui est le plus souvent utilisé pour isoler un comportement commun.
Pour plus d'informations, voir les instructions relatives aux relations d'inclusion dans le processus Rational Unified Process.
Il est beaucoup plus difficile de profiter de la relation d'extension, principalement car le cas d'utilisation d'extension n'est pas connu du cas d'utilisation de base. D'une manière générale, dans la plupart des systèmes métier, rares sont les emplacements où cette relation est utile. Gardez toutefois à l'esprit que les règles ont toujours des exceptions et que ce mécanisme peut être utile dans certaines circonstances.
Pour plus d'informations, voir les instructions relatives aux relations d'extension dans le processus Rational Unified Process :
En temps normal, la généralisation d'acteur peut permettre de mieux définir les différents rôles joués par les utilisateurs du système à développer. Cela s'avère particulièrement utile pour les applications comptant différentes « catégories » d'utilisateurs finals. Ainsi, seules les fonctionnalités pertinentes sont présentées à chaque catégorie d'utilisateurs et il est possible de contrôler les droits d'accès à partir de ce regroupement.
Règle empirique : chaque cas d'utilisation n'est initié que par un acteur. Cette "règle" peut être enfreinte, auquel cas la description du cas d'utilisation doit justifier cette décision.
Exemple du domaine métier Université :
Bibliothécaire et Professeur sont des exemples de rôles (acteurs) existants dans le domaine Université. Ces rôles comportent certaines tâches communes et d'autres qui sont propres à leur rôle dans le métier. La méthode recommandée pour modéliser ceci est indiquée ci-dessous.
Pour plus d'informations, voir les instructions : généralisation d'acteur dans le processus Rational Unified Process.
Dans certains cas, il est bénéfique d'inclure, outre le flux d'événements au format texte, un diagramme d'interaction pour illustrer le flux d'événements « de haut niveau » du cas d'utilisation. Il est recommandé de dessiner un diagramme de séquence à cet effet dans Rational Rose. N'incluez toutefois que la communication entre les acteurs et les objets frontière (couvrant à la fois les messages entrants et les messages de sortie) et traitez le système comme une boîte noire. Utilisez les objets frontière avec les noms logiques définis dans le flux d'événements du cas d'utilisation, sans les affecter à des classes à ce stade.
Chaque cas d'utilisation ne doit pas obligatoirement avoir un diagramme d'interaction correspondant, car il s'agit d'un produit facultatif.
Lorsqu'un diagramme d'activité apporte un plus en aidant à définir, à clarifier et à compléter le flux d'événements dans le cas d'utilisation, il est recommandé de modeler ce dernier dans Rational Rose. Une bonne règle empirique consiste à penser aux diagrammes d'activité pour les cas d'utilisation complexes (contenant plusieurs flux alternatifs et/ou exceptionnels). Le diagramme d'activité montre un arbre de décisions des flux du cas d'utilisation.
Chaque cas d'utilisation ne doit pas obligatoirement avoir un diagramme d'activité correspondant, car il s'agit d'un produit facultatif.
Pour des informations générales et des instructions complémentaires sur les cas d'utilisation, voir le processus Rational Unified Process.
Pour des informations générales et des instructions complémentaires sur les acteurs, voir le processus Rational Unified Process.
Chaque cas d'utilisation concret est-il en interaction avec au moins un acteur ? Si tel n'est pas le cas, il y a un problème ; un cas d'utilisation qui n'interagit pas avec un acteur est superflu et vous devez le supprimer ou identifier l'acteur correspondant.
Dans certains cas, plusieurs acteurs peuvent jouer un rôle dans l'interaction de cas d'utilisation. Veillez bien à vérifier que l'utilisation de plusieurs acteurs dans un même cas d'utilisation est autorisée (voir Généralisation d'acteur).
Les acteurs ont-ils des noms intuitifs et descriptifs ? Les utilisateurs et les clients comprennent-ils les noms ? Il est important que les noms d'acteurs correspondent à leurs rôles. Si ce n'est pas le cas, changez-les.
Il est conseillé de se référer au modèle de cas d'utilisation pour vous assurer que vous utilisez le bon nom d'acteur pour chaque acteur de votre cas d'utilisation.
La spécification de cas d'utilisation doit être écrite en utilisant les noms d'acteur de manière cohérente. Il convient de s'assurer que la désignation de l'acteur est claire et sans ambiguïtés.
Ne faites pas référence de manière générique à « l'acteur » ; utilisez plutôt le véritable nom utilisé pour distinguer ou définir l'acteur. On peut envisager le nom de l'acteur comme le rôle joué dans un ensemble d'interactions système.
Le nom du cas d'utilisation doit être unique, intuitif et explicite afin de définir de manière claire et sans ambiguïté la valeur finale observable dégagée à partir du cas d'utilisation.
Une bonne vérification du nom du cas d'utilisation consiste à étudier si les clients, les représentants commerciaux, les analystes et les développeurs comprennent tous le nom et la description des cas d'utilisation. N'oubliez pas : vous définissez un résultat de valeur observable du point de vue des acteurs.
Chaque nom de cas d'utilisation doit décrire le comportement pris en charge par le cas d'utilisation. Ce nom doit associer l'action réalisée et l'élément clé s'y rapportant. La plupart du temps, il s'agit d'une simple combinaison verbe/nom. Le cas d'utilisation doit être nommé du point de vue de l'acteur qui le déclenche. Exemples : "Inscription à un cours", "Sélectionner un cours à enseigner".
Le cas d'utilisation doit contenir une brève description, dont la longueur doit être comprise entre 1 et 3 paragraphes. Cette description doit fournir des explications sur la finalité première, la proposition de valeur et les concepts relatifs au cas d'utilisation.
Lorsque cela apporte un plus, il est possible d'inclure un échantillon de récit dans cette description afin de fournir un complément de contexte. Cet échantillon doit généralement suivre le flux de base et comprendre, si besoin, des données.
Il convient d'utiliser des formes impératives ou indicatives pour rédiger les exigences système des cas d'utilisation. Ce principe permet de décrire les exigences de manière cohérente. Ainsi, vous ne devez pas utiliser des formes ou des termes passifs qui pourraient laisser penser que l'exigence en question est facultative ou non définie (éviter ainsi "devrait", "peut-être", "etc", "pourrait", "est susceptible de" et autres formulations apparentées).
Tous les termes métier utilisés dans un cas d'utilisation doivent être définis dans le glossaire du projet. Si un terme métier existe dans un cas d'utilisation qui n'existe pas dans le glossaire, ce terme doit, au choix :
1. Etre ajouté au glossaire, accompagné d'une brève description (un paragraphe maximum).
2. Etre modifié dans le cas d'utilisation afin de refléter le bon terme métier défini dans le glossaire.
Le cas d'utilisation doit énoncer de manière explicite les cas où le système est chargé de proposer une action comme option que l'acteur peut sélectionner. Dans la plupart des cas, les options disponibles doivent être proposées dans le cadre du flux de base et doivent être référencées comme point d'entrée dans la première instruction du flux alternatif correspondant.
Les termes New (Nouveau), Modify (Modifier), Cancel (Annuler), Delete (Supprimer), OK et Print (Imprimer) doivent être utilisés de manière cohérente dans l'ensemble du cas d'utilisation : toute référence à une même action logique doit toujours se faire avec la même terminologie. Il conviendra tout particulièrement de veiller à ce que les termes d'action utilisés dans les flux alternatifs correspondent bien à ceux utilisés dans le flux de base.
Chaque fois que l'interaction entre l'acteur et le système change de perspective (acteur ou système), le segment de comportement suivant doit ouvrir un nouveau paragraphe. Commencez avec un acteur, puis passez au système.
La phrase doit commencer par 'Le <nom-acteur> doit xxxxx', ou 'Le système doit xxxx'. Citez toujours le nom de l'acteur correctement, en toutes lettres, plutôt qu'au moyen d'une abréviation.
Chaque flux alternatif ou sous-flux doit définir de manière claire et explicite tous les points d'entrée dans le flux et tous les points d'exit du flux possibles.
Le flux alternatif établit également de manière explicite le point d'exit et ce qu'il advient de l'acteur - soit il retourne à une étape précise, soit il se termine.
Lorsque le flux d'événements devient désordonné du fait d'un comportement complexe ou lorsque la longueur d'un flux unique dépasse une page imprimée, il est possible de recourir aux sous-flux pour rendre les choses plus claires et gérer la complexité. Les sous-flux doivent être écrits en déplaçant un groupe logique et autonome de comportement détaillé dans un sous-flux et en référençant ce comportement sous forme de résumé dans le flux d'événements.
La spécification de cas d'utilisation doit inclure un ensemble de conditions (également appelées postulat) qui doivent théoriquement être vraies avant que le cas d'utilisation ne démarre (préconditions) et après sa fin (postconditions). Il est à noter que le cas d'utilisation peut se terminer de différentes façons et que chaque "postcondition" doit être décrite en conséquence.
Lorsque les informations n'ont pas encore été définies ou pas encore choisies, le cas d'utilisation doit inclure une référence au problème ou à l'élément et doit inclure la marque de réservation : TBD (à venir).
Lorsqu'il existe d'autres exigences qui ne peuvent pas être décrites naturellement au cours du flux d'événements, ces exigences doivent être définies comme des exigences supplémentaires. Les exigences spécifiques à un cas d'utilisation doivent être définies dans la section Exigences particulières de la spécification de cas d'utilisation.
Les exigences qui sont applicables à tout le système (particulièrement celles qui ne sont pas du type fonctionnel) doivent être définies dans un ou plusieurs documents de spécifications supplémentaires distincts.
Exemples :
Fiabilité : - Le système doit être disponible 24/24h et 7/7j.
- Le système doit s'exécuter pendant 48 heures (moyenne des temps de bon fonctionnement).
Performances : - Le système doit fournir une réponse en ligne inférieure ou égale à 5 secondes dans les conditions normales de charge prévues.
Le contenu du cas d'utilisation doit faire l'objet d'un contrôle croisé par rapport à la conception/au prototype d'interface utilisateur afin de garantir qu'aucune exigence système ne manque dans le cas d'utilisation ou la conception/le prototype d'interface utilisateur. Si cela s'avère nécessaire, des changements doivent être apportés au cas d'utilisation (Modification du prototype d'interface utilisateur doit alors figurer parmi les sujets à aborder en vue d'une action future).
Les instructions suivantes sont fournies afin d'aider à la recherche de flux exceptionnels :
Pour chaque étape du cas d'utilisation, réfléchissez aux problèmes susceptibles de survenir. Chaque exception unique peut être enregistrée comme flux exceptionnel. Dans certains cas, un unique flux exceptionnel doit être utilisé dans l'ensemble du cas d'utilisation, par exemple "Dépassement du temps alloué". C'est le type d'exigence métier qui s'applique lorsque survient l'exception (c'est-à-dire : quelle devrait être l'expérience des acteurs ?) qui constitue l'information clé à enregistrer.