【发布时间】：2018-05-11 17:29:02
【问题描述】：
【问题讨论】：
标签： uml use-case use-case-diagram
【发布时间】：2018-05-11 17:29:02
【问题描述】：
有一条黄金法则可以帮助我解决类似的情况，希望对您有所帮助。
用例定义：参与者与系统之间的一系列交互以获得附加值。
所以，正如您所见，存在交互，基本上一个用例就是一系列交互。
哪些交互用于更新余额？无，只是系统（而不是演员）所做的计算。
让我们specify 假设用例是业务用例并且是 ATM。
- 1) Actor1 按下“开始按钮”
- 2) 系统显示当前卡片屏幕
- 3) Actor1 出示卡片
- 4) 带有选项的系统显示菜单...
- 5) Actor1 选择退出 .... ...
- 6) 系统显示屏幕已更新 余额
- 7) Actor1 选择 ....
所以这是非常直观的，首先不是用例，因为不涉及交互。因此，无需检查是否带来附加值。只是所涉及的众多交互之一的重要组成部分。
在某些例外情况下，您可能会采用该捷径，例如，如果您希望在模型中更加清晰，或者您是否需要根据用例划分工作。但恕我直言，这根本不是用例。
您可能有“显示余额”，但这只是一次互动，除非您有“在屏幕上显示”或“在 ATM 上打印纸”等选项
希望对你有帮助。
【讨论】：
-
不。身份验证根据您的（正确）定义没有用例，因为它没有增加任何价值。身份验证是一个纯粹的约束。
-
恕我直言，当您包含 UC 时，对附加值的需求会稀释图表的目的。但是你有一个公平的观点，我将从解释中删除它。因为这只是我的风格和观点，而你的观点是事实。
Update Balance 是用例吗？演员有什么附加价值吗？我猜不是。这是一个简单的功能，作为其他 2 个用例的一部分执行。您正在尝试（像大多数人一样）执行功能分解。仅仅两个用例共享一个公共功能并不能使该功能成为一个用例。用例是关于系统提供给其参与者的附加值。当您在用例中描述场景时，您可能会参考其他用例的场景。每个场景步骤都将以一个动作结束。当您描述Withdraw money 时，您可以简单地参考Make deposit 中描述的操作Update balance。但是，Update balance 是简单添加操作的结果。那么，为什么将其称为一个通用功能呢？
【讨论】：