UML - 用例图选项

Question

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

我一直认为在构建用例图时，我只包含将由系统执行的活动。例如，如果它是银行atm，＆＃34;用户存款＆＃34;将包括在内，因为它涉及用户与atm的交互。然而，＆＃34;用户从工作中获得现金支付＃34;未包含在图表中，即使它可能与场景或情况相关。

全部谢谢

Answer 1

用户以现金支付的事实与information system有关，这是一个涉及人的系统。支付交易必须与您的项目集成，至少从概念的角度来看。换句话说，它应该具有未指定类型与用例的关系，具体取决于上下文。

我认识到我的答案非常混乱：如果你已经厌倦了，直接跳到解决方案部分......

用例图

根据UML User Guide：

  

用例是系统执行的操作序列的描述，它为特定的actor产生可观察的结果。

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

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

关于手头现金支付的几句话。从纯粹的开发过程的角度来看，在建模时有一个敏锐的想法如何付费用户是否正常？这里的范围问题仍然存在：或许它在你的背景下是一个强大的约束。

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

用例本身与付款方式之间的关系不能在图表中表示。但是，即使这不是用例精神，如果它是图表阅读器应该被告知的重要约束，它的完成方式也可以写成注释。

解决方案

在我看来，将这些信息放在用例中的正确位置不是图表本身，而是用例描述。 Martin Fowler在UML distilled中给出了一些暗示。你有a simple use case description example here。这与您使用UML的方式以及您希望描述用例的方式有关（我个人分享Martin Fowler's perception）。

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

Answer 2

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

Answer 3

大多数情况下，用例是在模型的功能/逻辑级别（MDA的PIM级别）使用。这意味着它只描述了将自动化的流程部分。

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

在业务/概念（MDA的CIM级别）级别，无论自动化如何，您都可以对整个流程进行建模。因此，在这个层面上，“用户从工作中获得现金”肯定会取而代之。