用例泛化与扩展 [英] Use case generalization versus extension

问题描述

UML 用例图允许使用两种看似等效的方式来显示给定用例可能以多种不同方式实现，即 用例泛化，而不是用例扩展.我已经看到以下基本示例使用相同频率的任一方法建模，有时在单个源中.

UML Use Case Diagrams allow for two seemingly equivalent ways to show that a given use case might be realised in several different ways namely use case generalizations as opposed to use case extensions. I have seen the following basically example modelled using either approach with equal frequency, sometimes within a single source.

在我看来，扩展是比泛化更弱的关系，因为特定用例对基本用例的直接替换在泛化中必须是可能的，但在扩展中不一定.

To my mind an extension is a weaker relationship than generalization as a direct substitution of the specialised use case for the base case must be possible in generalization but not necessarily in extensions.

在我看来，泛化意味着需要多态实现，而扩展意味着要使用一些分支结构.

It seems to me that generalisation implies a polymorphic implementation is desired while extension implies some branching structure is to be used.

void makePayment(const PaymentDetails* pd)
{
   pd->pay();
}

相对于

void makePayment(const PaymentDetails* pd)
{
   switch(pd->type)
   {
       case EFT:
                payViaEFT(pd); 
                break;
       case PAYPAL:
                payViaPayPal(pd); 
                break;
       case CREDITCARD:
                payViaCreditCard(pd); 
                break;
   }
}

用例阶段对于建模此类实现特定的关注点是否还为时过早?有更合适的 UML 图.关于使用这两者中的哪一个，是否有硬性规定?如果是，那是什么?

Isn't the Use Case stage far too early for such implementation specific concerns to be modelled? There are much more appropriate UML diagrams for that. Is there a hard and fast rule regarding which of the two to use and if so what is it?

推荐答案

在我看来，扩展是一种比泛化更弱的关系作为基本用例的专用用例的直接替代必须可以泛化，但不一定可以扩展.

To my mind an extension is a weaker relationship than generalization as a direct substitution of the specialised use case for the base case must be possible in generalization but not necessarily in extensions.

确实如此.

在我看来泛化意味着多态需要实现，而扩展意味着一些分支结构将被使用.

It seems to me that generalisation implies a polymorphic implementation is desired while extension implies some branching structure is to be used.

该图并未规定任何实现.不过，您可以自己解读图中的提示.UML 仍然独立于那里的语言和解决方案.

The diagram does not dictate any implementation. You can interpret a hint from the diagram for yourself, though. UML remains independent of language and solution there.

对于这样的实现来说，用例阶段是不是太早了要模拟的具体问题?

Isn't the Use Case stage far too early for such implementation specific concerns to be modelled?

好吧，如上所述，UML 不强制执行任何特定类型的实现.但是，您在这里收集了一些重要的功能需求，这些需求可能会极大地影响您的时间安排和工作量.(用信用卡付款"比通过银行转帐提前付款"处理起来要复杂得多).因此，您会努力抓住这一点，但对不同的解决方案保持开放态度.

Well, as indicated above, UML does not enforce any specific kind of implementation. However, you are gathering some important functional requirements here that might greatly influence your time schedule and workload. ("Pay with credit card" is way more complex to handle than "pay in advance by bank transfer"). So you'd strive to capture that but remain open to different solution approaches.

还有更合适的UML图表.

There are much more appropriate UML diagrams for that.

你真的可以同时使用它们 :) 因为它们对同一主题有不同的看法.

You can really use them in parallel :) as they are different views on the same subject.

是否有硬性规定要使用的两个，如果是，那是什么?

Is there a hard and fast rule regarding which of the two to use and if so what is it?

我更喜欢这种情况下的概括，因为实际上扩展错误地表明可能存在一种不使用三个命名选项中的任何一个的支付方式.正如你自己指出的那样.

I prefer the generalization in this case because in fact the extensions falsely suggest there could be a way of paying without using any of the three named options. As you indicated yourself.

这篇关于用例泛化与扩展的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！