Uml 我应该把用例图中包含的用例放在类图中吗？

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

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

简言之 不，不是这样的

更多细节 通常没有直接映射 用例是从用户的角度来描述需求的。所以这是关于要解决的问题。通常，它们代表用户的高级目标，例如

管理学生

或

订阅课程

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

有一些方法可以将这两个世界联系起来 如果你想在两个世界之间建立联系，你可以遵循UML创始人所提倡的统一过程：

• 从用例开始
• 您可以为分析创建一个实例，其中为每个用例显示一个控制类，为用例和参与者之间的每个关联显示一个边界类，并为您可以从叙述中派生的每个域对象显示一个实体类
• 然后，您再考虑一些边界和控件，看看是否有一些重叠，甚至重用
• 然后你考虑设计你的系统。但细节层次将高得多。为了便于跟踪，您将最终将自己的解决方案类映射到分析类：对于每个类，您都可以找到与之相关的用例。反之亦然

但这种方法在敏捷环境中已经失去了吸引力。此外，由于解决方案设计通常受到所选体系结构模型（如MVP、MVVM、clean architecture等）的严重影响，并且这些模型与ECB具有不同的逻辑（尽管存在一些明显的、误导性的相似性），因此该分析步骤没有增加足够的价值

---

更糟糕的是，敏捷方法试图避免严格的ECB方法所需的大型前期分析

选择学生、选择课程、选择模块、选择学期都不是用例。它们是动作。你的问题很奇怪，如果我重写它，就像我必须实现所有描述的系统一样，尽管用例？我认为答案很明显。。。如果你想得到报酬，布鲁诺，我没有得到you@qwerty_so你如何区分它们？基本上看Christophe的答案。用例必须为其主要参与者增加价值。如果不是这样，你就没有用例，只有一些活动中的一个动作。