【问题标题】：Should I put included use cases from use case diagram in my class diagram?我应该把用例图中包含的用例放在我的类图中吗？
【发布时间】：2020-06-06 08:20:20
【问题描述】：

所以，我为学生在线系统设计了一个用例。问题是我的一些基本案例被细分为许多包含的案例。例如，作为员工生成marksheet，我包含的用例是：选择学生，选择课程，选择模块，选择学期

在我的类图中，我应该为所有较小的用例提供方法还是只为像 generateMarksheet 这样的主要用例提供方法？

【问题讨论】：

选择学生、选择课程、选择模块、选择学期都不是用例。它们是行动。
你的问题很奇怪，如果我重写它就像我必须实现所有用例描述的系统吗？，我认为答案很明显。 ..如果你想得到报酬^^
@bruno 我没找到你
@qwerty_so 你如何区分它们？
基本看Christophe的回答。用例必须为其主要参与者增加价值。如果不是这种情况，则您没有用例，而只有某些活动中的操作。

标签： uml class-diagram use-case use-case-diagram

【解决方案1】：

总之

不，它不是这样工作的。

更多细节

一般没有直接映射

用例是关于从用户角度来看的需求。所以这是关于要解决的问题。通常，它们代表用户的高级目标，例如 Manage students 或 Subscribe to courses。

您的系统类是关于满足这些要求的技术解决方案。但是，一般而言，没有您所描述的直接映射：系统的行为来自系统内许多类之间的交互。

有一些方法可以连接两个世界

如果您想在两个世界之间建立联系，您可以遵循 UML 创始人提倡的统一流程：

从用例开始
您为分析创建了一个ECB class model，其中您为每个单独的用例显示了一个控制类，为用例和参与者之间的每个关联显示了一个边界类，为您创建的每个域对象显示了一个实体类可以从叙述中得出。
然后，您可以多考虑一下边界和控件，看看是否有一些重叠，甚至重用。
然后您考虑设计您的系统。但详细程度会高得多。为了可追溯性，您最终会将自己的解决方案类映射到分析类：对于每个类，您都可以找到与其相关的用例。反之亦然。

但这种方法在敏捷环境中失去了吸引力。也因为解决方案设计经常受到所选架构模型的严重影响（例如 MVP、MVVM、干净架构……），并且这些模型与 ECB 具有不同的逻辑（尽管有一些明显和误导性的相似性），所以这个分析步骤是没有增加足够的价值。

此外，敏捷方法试图避免进行严格的 ECB 方法所需的大量前期分析。

【讨论】：