我应该在UML用例图中包括系统的任务/响应吗？

有一个练习要求我们为银行绘制用例图， 描述说客户可以存款和取款。对于那个用例场景，我只需要画一张图吗 存款和取款？或者我应该同时为它们更新平衡函数吗？

---

更新平衡是一个用例吗？演员有什么附加值吗？我想不是。这是一个简单的函数，作为其他两个用例的一部分执行。您正试图像大多数人一样执行功能分解。仅仅两个用例共享一个公共函数并不能使该函数成为用例。用例是关于正在考虑的系统向其参与者交付的附加值。当您在用例中描述场景时，您可能会提到场景是其他用例。每个场景步骤都将以一个动作结束。当您描述取款时，您可以简单地参考makedeposit中描述的操作更新余额。但是，更新平衡是一个简单的添加操作的结果。那么，为什么要把它称为一个普通函数呢？

有一条黄金法则可以帮助我解决类似的情况，希望它能对你有所帮助

用例定义：参与者和系统之间为获得附加值而进行的一系列交互

因此，正如您所看到的，存在交互，基本上一个用例是一系列交互

哪些交互用于更新平衡？没有，只是一个计算系统，而不是演员所做的

让我们假设这个用例是一个业务用例，是一个ATM

1个Actor 1按下“启动按钮” 2系统显示当前卡片屏幕 3.一张礼品卡 4带选项的系统显示菜单。。。 5 Actor1选择撤消。。。 6系统显示屏幕，更新 均衡 7.1选择。。。。 所以这是非常直观的，一开始不是用例，因为没有涉及交互。因此，不需要检查是否带来附加值。只是众多互动中的一个重要部分

在某些例外情况下，您可能会选择该快捷方式，例如，如果您希望在模型中更加清晰，或者如果您希望根据用例划分工作内容。但我认为这根本不是用例

您可能有“显示余额”，但这将只是一次交互，除非您有屏幕显示或自动取款机打印等选项

---

希望有帮助。

没有。身份验证符合您的正确定义，没有用例，因为它不会增加任何价值。身份验证是一个纯粹的约束。IMHO当您包含UC时，对附加值的需求与图表的目的相比会减弱。但你有一个公平的观点，我将从解释中删除它。因为这只是我的风格和观点，而你的是事实。