【发布时间】：2015-02-24 21:07:53
【问题描述】：
我听说过有关这方面相互矛盾的事情，只是想澄清一下。
我一直认为，在构建用例图时，我只包括系统将要执行的活动。例如，如果它是银行 atm，将包括“用户存款”，因为它涉及用户与 atm 的交互。但是，“用户从工作中获得现金”并未包含在图表中，即使它可能与场景或情况相关。
谢谢大家
【问题讨论】：
【发布时间】：2015-02-24 21:07:53
【问题描述】：
以现金支付用户的事实与information system 有任何关系，information system 是一个涉及人的系统。付款交易必须与您的项目集成，至少在概念上是这样。换句话说，它应该与用例具有未指定类型的关系，具体取决于上下文。
我知道我的回答很混乱：如果你已经觉得无聊了，直接跳到解决方案部分...
用例图
用例是对系统执行的一系列操作的描述，这些操作为特定参与者产生可观察的结果。
重点在于对与系统相关的内容进行建模：您的主要问题是考虑项目的范围。
根据您确定的范围，您应该考虑的用例类似于现金提取：从参与者的角度考虑可观察到的结果。无论您是否考虑系统的操作部分，这部分都是非常主观的。我个人不同意这里的其他答案。
关于手头现金支付的几句话。从纯粹的开发过程的角度来看，在建模时有一个敏锐的想法如何用户是正常的吗？这里仍然是范围问题：也许它在您的上下文中是一个强约束。
即使在逆向工程中，用例是面向用户的，它与事情是如何完成的无关，而是做了什么：我认为没什么与特别是自动化的事情有关，即使在谈论系统时也是如此。这里有一个微妙的想法：我考虑的是一个信息系统，一个首先涉及人的系统，而不是一个完全自动化的系统。当然，纯自动化系统可以用 UML 建模，但大多数系统都涉及到用户。
用例本身和如何完成支付的信息之间的关系不必在图表中表示。然而，即使这不是用例精神，如果它是一个重要的约束，图表读者应该被告知，它的完成方式可以写在注释中。
解决方案
在我看来，将这些信息放入用例的正确位置不是图表本身，而是用例描述。 Martin Fowler 在UML distilled 中给出了一些提示。你有a simple use case description example here。这与您使用 UML 的方式以及您希望描述用例的方式有关（我个人分享 Martin Fowler's perception）。
也许您更愿意用特定于您的建模软件的形式来表示这一点，但我认为这不是使用 UML 的传统方式（适用于 Executable UML，不适用于blueprint 或 sketch)。
【讨论】：
-
好答案。大多数情况下，当您在决定应该使用哪些用例时遇到问题时，原因是您没有足够清晰的范围：正在考虑的系统到底是什么，以及谁是与之交互的参与者它？如果您无法为这些问题提供明确的答案，那么您的用例将无处不在。
不包括在内，因为“用户从工作中获得现金”超出了项目的范围，并且您尝试创建的内容不需要。
【讨论】：
-
感谢您的快速回答，我会接受！
最常用于模型的功能/逻辑级别（MDA 的 PIM 级别）的用例。这意味着它只描述了那些将被自动化的流程部分。
因此，除非您的系统具有以某种方式记录用户以现金支付的事实的功能，否则这不是正在构建的系统的一部分。
在业务/概念（MDA 的 CIM 级别）级别，无论自动化如何，您都可以对整个流程进行建模。所以在这个级别上，“用户从工作中获得现金报酬”肯定会适得其反。
【讨论】：