UML，包含，扩展关系 [英] UML, include, extend relationship

问题描述

我无法理解包含和扩展关系的工作原理。
假设我有一个在线购物应用程序。该应用程序允许您在未经过身份验证的情况下添加/检索购物车中的商品。以下是订单方案：
客户点击订单按钮。系统检查用户是否已通过身份验证。如果用户通过身份验证，系统将显示购买页面，否则用户将被重定向到身份验证页面。
我想知道我的认证用例是否包含在订单用例中，如果是这样，为什么？
（我问的是这个问题，因为如果用户已经过身份验证，则无需进行身份验证。）
对不起我的英语

I have trouble understanding how the include and the extend relationships work. Let's say i have an online application for shopping. The application allows you to add/retrieve items from your cart without being authenticated. Here is the "order" scenario: The client clicks on the order button. The system checks if the user is authenticated. If the user is authenticated the system displays the purchase page otherwise the user is redirected to the authentication page. I would like to know if i the "authentication" use case is included in the "order" use case and if so why ? (I'm asking this question because the user doesn't have to authenticate if he already is authenticated.) Sorry for my english

推荐答案

我已经就用例进行了大量的咨询，这一直是一个非常有问题的主题，难以学习和掌握。考虑一些其他方法来指定req和系统功能（如UI原型，线框等）是一个好主意。理论上，用例是非常简洁的工具，但在实践中，它很难学习，耗时，不清楚，使团队和客户感到困惑，难以检查/验证，更难以保持更新等等。

I've done a lot of consulting on use cases and it has always been very problematic topic and hard to learn and master. It is definitelly a good idea to consider some other method to specify reqs and system functionality (like UI prototypes, wireframes, etc). In theory use cases are really neat tool, but in the practice it is ofter hard to learn, time consuming, unclear, confuses the team and the customers, hard to check/verify, even harder to keep updated, etc.

我试图在这里澄清这两种关系，使用你的例子，略微扩展以涵盖两种关系并强调差异：

I've tried to clarify these two relationships here, using your example, slightly extended to cover both relationships and put the emphasis on the differences:

请注意，下订单用例会有几个scenarions，其中两个是相关的：

Note that "Place order" use case will have several scenarions, two of which are relevant here:

• 下订单与之前的身份验证 - 在这种情况下，验证UC将不会调用


• 下订单没有先前的身份验证 - 在这种情况下，身份验证的调用是强制性的，以便成功下订单。

在这种情况下，出现了非常频繁的混淆和UC建模错误。一些建模者认为在包含的上下文中的强制意味着它必须始终在包括UC的上下文中执行，在每个场景中。如果不是这种情况（就像这里一样，只有一种情况是强制性的），他们使用extend。这是一个错误，因为在至少一个场景中UC是必需的。这些详细信息未在图表级别显示，而是在场景描述中显示。

Very frequent source of confusion and mistakes in UC modelling arises from this situation. Some modellers think that MANDATORY in the context of "include" means that it must be ALWAYS executed in the context of including UC, in every single scenario. If it is not the case (like here, there is only one scenario when it is mandatory) they use extend. This is an error, as it is enough that a UC is mandatory in at least one scenario. These details are not shown on the diagram level, but rather in the scenario descriptions.

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