Généralisation de cas d'utilisation par rapport à l'extension
UML Diagrammes de Cas d'Utilisation permettent apparemment deux façons équivalentes de montrer qu'un cas d'utilisation peut être réalisé de plusieurs manières différentes, à savoir cas d'utilisation des généralisations par opposition à cas d'utilisation des extensions. J'ai vu la suite fondamentalement exemple modélisé à l'aide de l'approche de fréquence égale, parfois au sein d'une seule source.
À mon avis, une extension est une relation moins que la généralisation d'un remplacement direct des effectifs de cas d'utilisation pour le cas de base doit être possible dans la généralisation, mais pas nécessairement dans les extensions.
Il me semble que la généralisation implique une mise en œuvre polymorphe est souhaitée, alors que l'extension implique une certaine ramification de la structure doit être utilisé.
void makePayment(const PaymentDetails* pd)
{
pd->pay();
}
par opposition à
void makePayment(const PaymentDetails* pd)
{
switch(pd->type)
{
case EFT:
payViaEFT(pd);
break;
case PAYPAL:
payViaPayPal(pd);
break;
case CREDITCARD:
payViaCreditCard(pd);
break;
}
}
N'est pas le Cas d'Utilisation en scène beaucoup trop tôt pour une telle mise en oeuvre des préoccupations spécifiques à modéliser? Il y a beaucoup plus approprié de diagrammes UML. Est-il une règle dure et rapide sur les deux à utiliser et si oui, quel est-il?
source d'informationauteur DuncanACoulter | 2013-02-28
Vous devez vous connecter pour publier un commentaire.
Qui est vrai.
Le diagramme n'impose pas la mise en œuvre.
Vous pouvez interpréter un indice à partir du diagramme pour vous-même, cependant. UML reste indépendant de la langue et de la solution.
Bien, comme indiqué ci-dessus, UML n'impose aucun type spécifique de mise en œuvre.
Cependant, vous êtes la collecte de certaines importantes exigences fonctionnelles ici qui peut fortement influencer votre emploi du temps et de la charge de travail. ("Payer par carte de crédit" est plus complexe à gérer que "payer à l'avance par virement bancaire"). Donc, si vous voulez cherchent à tirer, mais reste ouvert à différentes approches de solutions.
Vous pouvez vraiment l'utiliser en parallèle 🙂 comme ils sont des points de vue différents sur le même sujet.
Je préfère la généralisation dans ce cas, car en fait, les extensions faussement à penser qu'il pourrait être un moyen de payer sans l'aide de l'un des trois nommés options. Comme vous l'avez indiqué vous-même.
Lors de la modélisation avec un étendre la relation, l'extension de cas d'utilisation (pay via xxx) est exécutée lors de l'utilisation prolongée de cas (paiement) est à un endroit précis (donnée par le point d'extension, type de paiement) si la condition pour en étendre la relation détient (par exemple, pour "Payer par Paypal", la condition serait payment_type=PAYPAL). Dans ce modèle, "Payer par Paypal" ne traite uniquement avec les détails de réalisation d'une transaction de paiement avec Paypal, tandis que "procéder au Paiement" désigne l'ensemble des comportements qui sont indépendantes de la méthode de paiement (tels que le calcul du montant total, et de sauvegarder le résultat de la transaction, une fois qu'il a été réalisé).
D'autre part, la généralisation (qui est défini non seulement pour les cas d'utilisation, mais aussi pour un classificateur) est un concept plus large, car il n'a pas de détails (au niveau des diagrammes) les détails de quand et comment spécialisées comportements sont exécutées. Si "Payer par Paypal" ont été une spécialisation de "procéder au Paiement", il serait de redéfinir le comportement de "procéder au Paiement", ce qui pourrait être sensiblement différent du comportement de "Payer par carte de crédit".
Être une extension de cas d'utilisation ne signifie pas que les solutions doivent être codées en dur. En effet, votre premier exemple est aussi valable la mise en œuvre d'étendre la relation, depuis
pd->pay(pd)va invoquer des comportements différents selon le type de paiement sélectionné. En fait, le diagramme de cas d'utilisation de modèles ce qu'un système est censé fairetandis que le faible niveau de mise en œuvre sont précisés dans les diagrammes d'activité.Un exemple d'une extension serait un "Entrez le Code de Remise" cas d'utilisation. De la saisie d'un code de réduction à faire un paiement, mais vous n'avez pas à entrer dans le but d'effectuer le paiement.
Vous pouvez regarder le "est" une relation pour déterminer lequel utiliser. Payer par PayPal "est un" faire un paiement, une façon particulière de faire un paiement. Entrez le code de remise ne l'est pas. C'est quelque chose supplémentaire que vous pouvez faire un paiement.