我在互联网上搜索了很多帖子，但仍然不知道有时在扩展和泛化之间是否区分开，或者是否是与另一个无关的另一个用例。
例如，我正在尝试构建有关餐厅的系统。为了打印票，服务生可以在记住的情况下输入订单号，但是如果他不记得它，可以在未付款的订单列表中搜索并从中选择机票。
我相信在这种情况下，它将是打印票证的扩展名（通过输入订单将打印票证作为默认票证），然后是从订单列表中选择的扩展名。
还是可能是概括？。
答案 0 :(得分：2)
首先，在很多情况下，建模时我们倾向于尝试使用扩展或泛化，但都不需要。为了实现这种差异，必须添加新元素，例如在更一般和更具体的用例中，有不同的参与者，或者扩展用例的部分可以作为单独的UC存在，可以添加新的参与者，也可以是可重用的部分（尽管后者可能不足以将其分开）。
泛化意味着用例具有相同的目的，但是用（非常）不同的方式执行。想象一下付款。您可以有一个名为Pay的通用（父）UC，只有一个actor-User与之关联。但是您也可以通过各种外部付款方式提供商进行付款，例如信用卡代理，快速电汇代理等。这些付款中的每一个都会引入额外的参与者，并且执行方式不同，因此可能需要考虑将其作为Pay UC的专业化。
在扩展方面，假设您有两个UC：创建客户和下订单。通常，您可以开始下订单并即时创建客户。另一方面，您可以为现有客户创建订单，也可以在第一个订单之前就预先创建客户。因此，上述两个UC可以单独运行，也可以创建“创建客户端”扩展下订单。
在您的情况下，在未付款订单列表中进行搜索将只是UC的替代流程，因此，除非有其他原因，否则最有可能不需要扩展或概括。
答案 1 :(得分：1)
不要让您陷入用例的功能分解。用例应显示使用所考虑系统的参与者的附加值。
概括和<<extend>>关系是开始功能分解的良好指示。别！第一个是（从我的角度来看）绝对不行。由于增加值本身是唯一的，因此使用泛化会产生矛盾。我认为只有一种情况可以归纳为特许经营权。
使用<<extend>>特别表示功能分解。人们开始从用例中提取功能部件，并使其成泡沫。但是它们不是用例，因为它们自己无法提供任何附加值。至少在大多数情况下。
因此，简单的建议是：不要一概而论，不要去概括<<extend>>（以及<<include>>），除非您确切地知道自己在做什么。只需创建有意义的参与者-用例关系即可。句号。