1

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

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

谢谢大家

4

3 回答 3

2

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

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

用例图

根据UML 用户指南

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

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

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

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

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

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

解决方案

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

也许您更愿意使用特定于您的建模软件的形式来表示这一点,但我认为这不是使用 UML 的传统方式(适用于Executable UML,不适用于blueprintsketch)。

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

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

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

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

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

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

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