Activité :
|
Objet
|
Rôle : Analyste système |
Fréquence : Selon les besoins. Généralement au moins une fois pour chaque itération, notamment au cours des phases de création et d'élaboration, et éventuellement lors de la phase de construction. |
Etapes |
Artefacts d'entrée : | Artefacts de sortie : |
Guides d'utilisation de l'outil : |
Détails sur l'enchaînement d'activités : |
Pour structurer le modèle de cas d'utilisation, la première étape consiste à comprendre les exigences communes à plusieurs cas d'utilisation. Analysez chaque cas d'utilisation et notez toutes les similitudes.
Vous utiliserez ces notes lors des étapes ultérieures (inclusions, extensions et généralisations) pour limiter les redondances. L'objectif est de rendre les exigences plus compréhensibles et faciles à gérer, NON de définir une décomposition fonctionnelle à utiliser pour la conception.
La création de nouveaux cas d'utilisation ne constitue pas forcément la meilleure méthode pour gérer les exigences communes. Par exemple, vous pouvez transférer le contenu commun vers d'autres artefacts comme le glossaire ou les spécifications supplémentaires, et créer les liens nécessaires dans les cas d'utilisation.
De la même manière, s'il concerne un cas d'utilisation spécifique, transférez le contenu des spécifications supplémentaires vers ce cas d'utilisation.
Si un cas d'utilisation contient un comportement dont seul le résultat compte, et non la méthode utilisée, ce comportement peut être transféré vers un nouveau cas d'utilisation d'inclusion. Le cas d'utilisation d'origine devient alors le cas d'utilisation de base dans le cadre d'une relation d'inclusion avec le cas d'utilisation d'inclusion. Voir aussi Principes et conseils : Modèle de cas d'utilisation et Principes et conseils : Relation d'inclusion.
Une relation d'inclusion entre deux cas d'utilisation signifie qu'une instance de cas d'utilisation suivant la description du cas d'utilisation de base doit également suivre la description du cas d'utilisation d'inclusion.
La relation d'inclusion peut aider à éclaircir un cas d'utilisation en :
Notez qu'un cas d'utilisation d'inclusion doit servir pour plusieurs cas d'utilisation : sinon, cela ne vaut pas la peine de gérer un cas d'utilisation supplémentaire et la relation d'inclusion associée.
Seul le cas d'utilisation de base connaît la relation entre les deux cas d'utilisation : aucun cas d'utilisation d'inclusion ne sait dans quels autres cas d'utilisation il est inclus.
Décrivez la relation d'inclusion en indiquant brièvement l'objet de l'inclusion, ainsi que l'emplacement où l'inclusion doit être insérée dans le cas d'utilisation de base.
Dans la description du flux d'événements du cas d'utilisation de base, vous devez faire référence à l'inclusion à l'endroit où elle devra être insérée.
Si un cas d'utilisation contient des comportements optionnels ou exceptionnels qui ne sont pas nécessaires à la compréhension de l'objet du cas d'utilisation, transférez ces comportements vers un nouveau cas d'utilisation d'extension. Le cas d'utilisation d'origine devient alors un cas d'utilisation de base, avec lequel le cas d'utilisation d'extension a une relation d'extension. Voir aussi Principes et conseils : Modèle de cas d'utilisation et Principes et conseils : Relation d'extension.
Dans le cas d'utilisation de base, vous pouvez définir des points d'extension qui indiquent où des extensions peuvent être effectuées dans le cas d'utilisation. Voir aussi Principes et conseils : Cas d'utilisation.
Les sous-flux complexes et les comportements optionnels se prêtent particulièrement bien à la relation d'extension. En effet, ces comportements sont souvent complexes et difficiles à décrire : si vous les incluez dans le flux d'événements du cas d'utilisation, vous risquez de perdre de vue le comportement "normal". En décrivant ce comportement optionnel à part, vous favorisez la compréhension du modèle de cas d'utilisation.
Assurez-vous que le flux d'événements du cas d'utilisation de base est toujours complet et compréhensible, sans aucune référence au cas d'utilisation d'extension.
Seul le cas d'utilisation d'extension connaît la relation entre les deux cas d'utilisation. Le cas d'utilisation de base sait uniquement qu'il comporte des points d'extension, mais il ne connaît pas les cas d'utilisation d'extension auxquels il est rattaché.
Décrivez brièvement toutes les relations d'extension que vous définissez. Indiquez les conditions qui doivent être remplies pour que l'extension puisse être réalisée. N'oubliez pas de définir le point d'extension où l'insertion doit être effectuée dans le cas d'utilisation de base.
Si plusieurs cas d'utilisation présentent des structures ou des comportements similaires, vous pouvez transférer ce comportement commun vers un nouveau cas d'utilisation parent. Les cas d'utilisation d'origine deviendront alors des cas d'utilisation enfant dans le cadre de relations de généralisation avec le parent. Le cas d'utilisation enfant hérite de tous les comportements décrits pour le cas d'utilisation parent. Voir aussi Principes et conseils : Modèle de cas d'utilisation et Principes et conseils : Généralisation de cas d'utilisation.
Une relation de généralisation entre deux cas d'utilisation signifie qu'une instance de cas d'utilisation suivant la description d'un cas d'utilisation enfant doit également suivre la description du cas d'utilisation parent.
Notez qu'au moins deux cas d'utilisation enfant doivent hériter du même parent : sinon, cela ne vaut pas la peine de gérer un cas d'utilisation parent et la relation de généralisation associée. Il existe toutefois une exception : deux cas d'utilisation, l'un étant une spécialisation de l'autre, mais chacun d'entre eux devant être instanciables séparément.
Seul le cas d'utilisation enfant connaît la relation entre les deux cas d'utilisation : aucun cas d'utilisation parent ne sait quels cas d'utilisation enfant l'utilisent.
Pour faciliter la compréhension du modèle, décrivez brièvement la relation de généralisation. Expliquez notamment pourquoi vous avez créé cette relation de généralisation.
Dans le flux d'événements du cas d'utilisation enfant, vous devez expliquer comment l'enfant va modifier les séquences de comportement héritées en insérant de nouveaux segments de comportement.
Les acteurs ont des caractéristiques communes que vous devez modéliser en définissant des généralisations entre ces acteurs. Il est préférable de définir ces relations après avoir terminé la première ébauche du modèle de cas d'utilisation.
Rédigez une brève description de ces généralisations entre les acteurs et incluez-les dans les diagrammes de cas d'utilisation, pour plus de clarté.
Voir aussi Principes et conseils : Généralisation entre acteurs.
Vous devez sans cesse revoir les relations d'extension, d'inclusion et de généralisation avec le client et les utilisateurs, et vous assurer qu'ils comprennent bien les cas d'utilisation et les acteurs qui en résultent et sont d'accord avec vos descriptions.
Vous devez évaluer votre modèle de cas d'utilisation à ce stade afin de vous assurer que votre travail semble correct, mais il est inutile de faire un contrôle détaillé. Vous devez revoir les cas d'utilisation et les relations nouvellement définis avec le client et les utilisateurs, afin de vous assurer qu'ils comprennent bien les cas d'utilisation et approuvent les descriptions associées.
Le cas échéant, vous pouvez regrouper les cas d'utilisation pour constituer des packages de cas d'utilisation. Voir Principes et conseils : package de cas d'utilisation pour plus d'informations sur cette possibilité.
Vérifiez également les points de contrôle applicables au modèle de cas d'utilisation sur lequel vous travaillez. Concentrez-vous spécialement sur les points de contrôle relatifs aux acteurs, aux cas d'utilisation et aux modèles de cas d'utilisation, disponibles dans Activité : Revoir les exigences.
RUP (Rational Unified Process)
|