Uml 用例：分开还是不分开？

如果网站的一个成员可以查看他们自己的个人资料和其他用户的个人资料，我应该做两个单独的用例吗？是否应该是会员查看自己的个人资料和会员查看他人的个人资料？或者仅仅是成员视图概要文件就足够了？

根据评论，一个用例可以有一个完整的应用程序场景/特性/功能。因此，如果您谈论的是成员查看概要文件的用例，那么它将是一个用例，但如果您谈论的是验证的测试用例，那么它将是两个测试用例

成员查看自己的个人资料并不意味着他也可以查看其他个人资料。因此，您需要有两个测试用例来验证这两种可能性

---

另一方面，这方面的案例也很少——你应该有一些案例，比如会员可以编辑他的个人资料，编辑其他人的个人资料，这也可以转到各个字段。成员能够编辑其所有详细信息，但能够编辑层次结构中他下面的其他特定成员的一些详细信息，并且不能编辑层次结构中他上面的其他成员的任何详细信息等。

我想说三个用例，如下所示：

---

用例演示参与者如何使用系统来实现他们的目标。因此，用例的结构必须遵循这些目标。你会说，一个演员，例如你的web应用的访问者，会使用你的应用来查看他的个人资料吗？他会用它来查看其他用户的个人资料吗？如果这些是独立的目标，那么用例应该是独立的。但是，如果您想让访问者查看站点上其他用户的信息，一个用例就足够了。

用例不是功能，请查看相关文献（例如Bittner）。@Gabriel-嗯，不确定这是否值得否决。无论如何，我已经编辑了将“功能”更改为“场景”。希望这看起来没问题？@Sachin Shanbhag问题不在于语言（尽管用例代表一组场景，而不是一个特定的场景），而在于内容。上述用例有助于实现参与者的特定目标。这意味着，每个单独的用例都应该对参与者有价值。想象一下，web应用程序的唯一目的（和行为）是向成员显示其信息。这样的应用程序对你有什么帮助吗？你会付钱吗？您可能需要登录屏幕进行身份验证和授权，但这是一项功能，不是一个用例，任何onw都不会为允许登录的应用付费。@Gabriel-我不清楚您想告诉我什么，我想知道这与给定的问题和我的答案有什么关系？我不明白到底是什么错了。我只是简单地回答说OP必须为他的测试保留两个不同的用例。很抱歉请帮我多了解一点。你可能是对的，但我不明白@加布里埃尔-我认为在术语上可能有点混乱。我应该使用testcase而不是usecase。我想这就是困惑所在。谢谢你，伙计。用例是一组测试用例。OP的场景可以有一个用例和两个测试用例。用例不用于构建功能。用例用于分析，而不是系统的设计。你不使用用例中的场景来识别类、属性和操作吗？我知道当一个用例是多个用例的一部分时，它可以分解一个用例，所以你不必重复场景。你提到场景，但我将它们称为用例描述，因为场景是通过用例的一个特定流的示例。这些描述确实如您所说的那样使用，但是它们不包括那些设计元素。这些是用例实现的一部分（例如，使用顺序UML图进行可视化）。包含关系确实是为了避免重复。然而，如果你没有写描述，你怎么知道这会有帮助？我猜一个用例“查看用户配置文件”比这三个用例描述的工作量要小得多。最后还有一个用例点，帮助参与者实现其目标，从而赋予其一些价值。你会买一个只允许你选择一个用户的应用程序吗？有关更多信息，请参阅我上面的评论。好的，我理解，我应该记住，用例是参与者下次执行用例时需要实现的目标，谢谢您的回答。