Artefact :
|
![]() |
Un package de cas d'utilisation est un regroupement de cas d'utilisation, d'acteurs, de relations, de diagrammes et d'autres packages ; il permet de structurer le modèle de cas d'utilisation en le fragmentant en unités plus petites. |
---|---|
Autres relations : |
Partie de Modèle de cas d'utilisation
|
Rôle : | Spécificateur d'exigences |
Caractère facultatif/Occurrence: | Le <<package de cas d'utilisation>> peut être exclu. |
Modèles et rapports : |
|
Exemples : | |
Représentation UML : | Package dans le modèle de cas d'utilisation, soit son package de plus niveau, soit banalisé en tant que <<package de cas d'utilisation>> |
Informations supplémentaires : |
Entrée d'activités : | Sortie d'activités : |
Les personnes suivantes sont amenées à utiliser les packages de cas d'utilisation :
Nom de la propriété |
Brève description |
Représentation UML |
---|---|---|
Nom | Nom du package. | Attribut "Nom" pour l'élément de modélisation. |
Brève description | Brève description du rôle et de l'objet du package. | Valeur marquée, de type "texte court". |
Cas d'utilisation | Cas d'utilisation contenus directement dans le package. | Appartenance via l'agrégation "propriétaire de". |
Acteurs | Acteurs contenus directement dans le package. | - " - |
Relations | Relations contenues directement dans le package. | - " - |
Diagrammes | Diagrammes contenus directement dans le package. | - " - |
Packages de cas d'utilisation | Packages contenus directement dans le package. | - " - |
Le partitionnement en packages de cas d'utilisation est effectué dès lors que le modèle de cas d'utilisation devient trop volumineux pour être géré comme une structure à plat. Ceci peut se produire dès la phase de création ou ultérieurement, lors des phases d'élaboration ou de construction.
Un spécificateur d'exigences est responsable de l'intégrité du package, garantissant que :
Il est recommandé que le spécificateur des exigences responsable d'un package de cas d'utilisation soit aussi responsable des cas d'utilisation qu'il contient. Pour plus d'informations, reportez-vous à : Principes et conseils : Cas d'utilisation.
+ Fournit une structure de modèle hiérarchique avec des unités fonctionnelles distinctes. Celle-ci est plus facile à comprendre qu'une structure de modèle à plat (sans packages) lorsque le modèle de cas d'utilisation et le système sont relativement volumineux.
+ Offre une occasion favorable de répartir le travail et les responsabilités entre plusieurs développeurs en fonction de leur domaine de compétence. Cet aspect et particulièrement important lorsque vous construisez un système de grande envergure. Les packages de cas d'utilisation fournissent aussi une base sécurisée si vous désirez maintenir la confidentialité et faire en sorte que seuls quelques developpeurs puissent connaître la fonctionnalité complète du système.
+ Dans la mesure où les packages doivent être des unités à haute cohésion, la modification d'un package ne devrait pas affecter les autres.
- La maintenance des packages de cas d'utilisation entraîne un surcroît de travail pour l'équipe de modélisation des cas d'utilisation.
- L'utilisation de packages de cas d'utilisation signifie que les développeurs doivent assimiler un autre concept notationnel.
Si vous employez cette technique, vous devrez décider combien de niveaux de packages seront utilisés. En règle générale, chaque package de cas d'utilisation devrait contenir approximativement de 3 à 10 unités plus petites (cas d'utilisation, acteurs ou autre packages). Le tableau ci-dessous offre quelques suggestions sur le nombre de packages à utiliser en fonction du nombre de cas d'utilisation et d'acteurs. Les propositions se chevauchent étant donné qu'il est impossible de donner des recommandations exactes.
RUP (Rational Unified Process)
|