作为用例的身份验证与具有该特权的参与者之间有区别吗？

Question

第一个 UML 图展示了一个与电子商务网站交互的基本用户，其中明确包含了下订单、添加到购物车和结帐等操作的身份验证。

在第二张图中，我通过引入“经过身份验证的用户”参与者简化了身份验证过程。这消除了在每个特定用例中进行显式身份验证的需要。

我想知道这是否可行以及您建议遵循哪个流程。

我知道身份验证不是一个用例，但我还没有找到具体的示例来进行这种比较。

我问了我的教授，他们说只有第一张图适用。我也在互联网上做了一些研究。

Answer 1

身份验证不是一个用例

首先，

authenticate

并不是真正的用例：

• 从用例分析的角度来看，这不是用户的目标。没有用户会仅仅为了进行身份验证而购买系统。这只是某些行为完成所必需的约束。

• 从严格的 UML 角度来看，一个用例

  指定了该主体执行的一组行为，这会产生一个“可观察的结果”，对于参与者或其他利益相关者来说“具有价值” 但是执行身份验证可能不一定是可观察的（例如，如果身份验证是通过幕后的单点登录功能执行的），并且用户可能不会重视身份验证的结果，而只会重视身份验证的其他用例的价值是一个约束。

  没有为用例定义顺序。用例并不意味着描述工作流程，而您的两个图表都需要一个顺序。 （顺便说一句，我假设在第二张图中，
User

也应该与

authenticate
• 相关联）

  身份验证应该是一个约束，或者是要执行的某些活动（可能是有条件的，例如，如果用户已经通过身份验证）作为描述用例背后的详细信息的活动图的一部分。

最后但并非最不重要的一点是，越来越多的身份验证不再在系统中执行，而是由作为身份提供者的外部系统执行。

什么图替代更合适

我强烈不同意你的教授的观点：第一个替代方案不是推荐的，因为它是你的用例的功能分解。虽然 UML 中并未禁止这样做，但

Bittner & Spence

等主要作者认为这是不好的做法。

第二个在这方面更加优雅，因为您的参与者专业化（完全合法）允许查看经过身份验证的用户可以做什么以及未经身份验证的用户可以做什么。唯一的缺陷是 authenticate 用例。但如果你删除它，它仍然是正确的并表达了你的设计意图。如何管理身份验证是一个技术或用户界面细节。

一些旁注：

如果您坚持保留

authenticate

，则至少添加与

User

•  的关联
  

  您不需要

  navigate products

  和
Authenticated user
• 之间的冗余关联，因为此关联继承自

  User

  （用户可以执行的所有操作，经过身份验证的用户也可以执行）您应该从参与者和用例之间的关联中删除箭头。这种旧的表示法不再有效（即使您会在互联网和书籍中找到许多示例，如有疑问，请参阅 UML 2.5.1 规范）。