uml - 识别用例的参与者

Question

我正在开展一个小爱好项目，并尝试以不同的方式做事。

我正在构建的系统是一个ERP系统，包括收银台、产品目录、销售数据库、销售日志(类似于数据库，但用于会计目的)、打印机、付款合作伙伴和购物篮(购物车) )。

虽然打印机是硬件，但我需要编写更高级别的代码来打印收据。

我唯一不需要编程的部分是支付合作伙伴。

我有两个问题。

1) 向客户销售一堆产品的用例是一个名为“在收银台销售商品”的用例，还是会被分成多个用例，例如“将产品添加到购物车”和“完成销售” “(这将写入销售日志并打印收据)。

2)虽然我正在对目录、销售数据库、销售日志、购物篮等进行编程，但我可以将它们建模为用例中的参与者吗？或者唯一的参与者是销售人员和付款合作伙伴？

Answer 1

用例分析看似简单，但这个问题暴露了一些固有的复杂性。

每个用例都必须对所涉及的参与者有意义，因为它必须代表与系统的明确定义的交互。当您谈论系统时，即使使用日常语言，每个参与者和用例也必须有意义。如果您发现自己难以定义参与者或用例，那么系统上下文可能不清楚，因此领域模型可能会有所帮助。

用例必须代表明确定义的交互，但不一定是完整的交互。 <<include>>关系可用于在同一级别上查看完全交互和部分交互用例有意义的情况。您可能会考虑使用用例 buy stuff包括browse products , add product to cart和check out <<xor>> cancel ，例如，每一个对客户来说都是有意义的。

(我有点困惑您的系统是用于实体交易还是在线交易；拥有收银台和打印收据似乎意味着前者，而购物车作为分析中使用的概念的一部分意味着后者.以上假设是在线系统。)

但是，就您而言，您正在谈论可能被视为系统本身一部分的参与者。这通常意味着您尝试同时定义系统及其子系统，这在您开始分析之前对(最终)系统设计有很好的了解的情况下很常见。

然后您要做的是将分析分为两个级别。在上层(系统)层面，要非常严格地将系统视为一个整体。就您而言，您可能需要 Actor customer , payment partner , clerk (对于物理交易系统)，accountant (也许 administrator )，以及上面列出的用例加上 update product catalogue , audit sales log等

然后，您将系统分解为子系统，并对每个子系统进行单独的分析。这里的子系统可以是彼此用例中的参与者。 Print receipt例如，在系统级别上不是一个有意义的用例，因为它本身不是整个系统和系统级参与者之间的交互，但作为打印机子系统的用例，它是有意义的，并且直到成为 Actor 为止。

在开始子系统分解之前，你不需要完成系统级分析，事实上我认为最好让它们同时活跃——尽管这对你作为分析师/设计师提出了更高的要求能够快速切换环境，并在任何给定时间严格控制您所处的工作环境。

所以，毕竟(唷!)我认为你的问题的答案是:

1. 两者都是，只要每个用例对其参与者来说都是有意义的，作为与系统的明确定义(但不一定完整)的交互。
2. 是的，但不在同一级别；通过系统的一个模型和每个子系统的单独模型，您可以将子系统用作彼此用例中的参与者。