一个用例可以包含和前置相同的其他用例吗？答案

【问题标题】：Can a use-case include and precondition the same other use-case?一个用例可以包含和前置相同的其他用例吗？
【发布时间】：2018-05-04 11:53:17
【问题描述】：

让我们以登录和添加项目为例，作为项目管理系统的两个用例。客户的要求是：（他需要/想要：）

获得对系统资源的合法访问权；
添加项目（创建一个）。

我们也知道未经身份验证的用户不应使用该系统！

我的问题是：

1) “获得访问权限”是一个用例吗？其他用例的先决条件 ?或两者？（知道通过命名用例“Gain Access”而不是“Logging in”，我想强调需要而不是解决方案满足这种需求。

2) 如果“Gain Access”是一个用例，那么“Add Item”用例是否包括“获得访问权限”用例？

用例依赖关系：

顺序依赖

用例前置条件反映用例之间的顺序依赖关系。
带有前置条件 C 的用例 B 只能在用例 A 产生 C 作为后置条件之后启动。在用例 A 之后执行用例 B；它们的连接是异步的。

函数依赖

相比之下，包含关系反映了用例之间的功能依赖关系。
当用例 A 与用例 B 具有包含关系时，这意味着用例 B 的功能是用例 A 整体功能的一部分。用例 B 作为用例 A 的部分执行；它们的连接是同步的。

https://www.batimes.com/articles/use-case-preconditions-a-best-kept-secret.html

【问题讨论】：

Login 不是用例，而是一个约束。阅读比特纳/斯宾塞。
是的，登录不是一个用例，但是“获得合法访问权限”呢？我猜这是一个要求
这是一个要求。这会导致对用例的限制。
好的，但是如果它是一个约束而不是一个用例，如何对扩展“获得访问”的需求进行建模。例如“重置密码”（如果他们希望在登录后重置密码，则需要重置密码）
stackoverflow.com/questions/49692740/…

标签： dependencies include uml software-design use-case

【解决方案1】：

用例必须产生商业价值。 “登录”（或获得访问权限等）本身是否提供了商业价值？系统的用户会 login 然后离开吗？可能不是。因此登录不是用例本身。它可以记录为用例中的一个步骤（如果您对解决方案有足够的了解并且愿意说的话），但请注意不要在用例中指定技术解决方案。您最好指定用户必须被识别为一定级别的身份验证并将其应用为先决条件等。

商业价值是关键。识别商业价值是分析艺术和科学的一部分。例如，如果您不使用用例来建模需求，情况也是如此——例如“作为（角色）需要（行动）以便（业务价值）”形式的用户故事再次以业务价值为重点。归根结底，业务价值是任何功能需求的焦点，明确识别它应该是您的分析接近其目标的主要指标之一。

记住这一点——顺序和功能依赖。注意不要将系统的功能分解为不反映业务价值的单元。经常引用的 ATM 示例：Check Balance 是一个用例，输入 PIN 不是（出于上述原因）。但是，您可能希望在执行提取现金时始终检查余额。如果是这种情况，那么您可以使用 include 来表明 Withdraw Cash 包含 Check Balance，但请注意，两个用例都提供业务自身价值。

【讨论】：