1

我听说过关于此的相互矛盾的事情，只是想澄清一下。

我一直认为，在构建用例图时，我只包括系统将要执行的活动。例如，如果它是银行 atm，则将包括“用户存款”，因为它涉及用户与 atm 的交互。但是，“用户从工作中获得现金”并未包含在图表中，即使它可能与场景或情况相关。

谢谢大家

4

3 回答 3

2

以现金支付用户的事实在任何方面都与信息系统有关，信息系统是一个涉及人的系统。付款交易必须与您的项目集成，至少在概念上是这样。换句话说，它应该与用例具有未指定类型的关系，具体取决于上下文。

我知道我的回答很混乱：如果您已经感到无聊，请直接跳到解决方案部分...

用例图

根据UML 用户指南：

用例是对系统执行的一系列操作的描述，这些操作为特定的参与者产生可观察的结果。

重点在于对与系统相关的内容进行建模：您的主要问题是考虑项目的范围。

根据您确定的范围，您应该考虑的用例类似于现金提取：从参与者的角度考虑可观察到的结果。无论您是否考虑系统的操作部分，这部分都是非常主观的。我个人不同意这里的其他答案。

关于手头现金支付的几句话。从纯粹的开发过程的角度来看，在建模时对用户如何获得报酬有一个敏锐的想法是正常的吗？这里仍然是范围问题：也许它在您的上下文中是一个强约束。

即使在逆向工程中，用例是面向用户的，它与事情的完成方式无关，而是做什么：我认为与特别自动化的事情无关，即使在谈论系统时也是如此。这里有一个微妙的想法：我考虑的是一个信息系统，一个首先涉及人的系统，而不是一个完全自动化的系统。当然，纯自动化系统可以用 UML 建模，但大多数系统都涉及用户。

用例本身与如何完成支付的信息之间的关系不必在图表中表示。然而，即使这不是用例精神，如果它是图表读者应该被告知的重要约束，它的完成方式也可以写在注释中。

解决方案

在我看来，将这些信息放在用例中的正确位置不是图表本身，而是用例描述。Martin Fowler 在UML中给出了一些提示。您在这里有一个简单的用例描述示例。这与您使用 UML 的方式以及您希望描述用例的方式有关（我个人同意Martin Fowler 的看法）。

也许您更愿意使用特定于您的建模软件的形式来表示这一点，但我认为这不是使用 UML 的传统方式（适用于Executable UML，不适用于blueprint或sketch）。

于 2015-02-25T09:46:52.863 回答
1

它不包括在内，因为“用户从工作中获得现金”超出了项目的范围，并且您尝试创建的内容不需要。

于 2015-02-24T21:10:34.983 回答
1

最常见的用例用于模型的功能/逻辑级别（MDA 的 PIM 级别）。这意味着它只描述了那些将被自动化的过程部分。

因此，除非您的系统具有以某种方式记录用户以现金支付的事实的功能，否则这不是正在构建的系统的一部分。

然而，在业务/概念（MDA 的 CIM 级别）级别，您可以对整个流程进行建模，而不管自动化程度如何。因此，在这个级别上，“用户从工作中获得现金报酬”肯定会适得其反。

于 2015-02-25T07:07:45.123 回答