Uml 确定用例的参与者

我正在做一个小爱好项目，并且正在尝试做一些不同的事情

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

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

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

我有两个问题

1） 向客户销售一系列产品的用例是一个名为“在收银台销售商品”的用例，还是分成几个用例，例如“将产品添加到购物车”和“完成销售”（这将写入销售日志并打印收据）

---

2） 虽然我正在编写目录、销售数据库、销售日志、购物篮等，但我可以在用例中将它们建模为参与者吗？还是只有销售人员和支付合作伙伴才是演员？

我想你需要先退一步。参与者和用例的目的是首先询问：“谁将使用这个系统？”以及“他们为什么要使用它？”。你可以开始将蒂尔、打印机等视为演员——事实上，他们中的一些人可能是演员——但有一种危险，那就是你会错过关键点

根据您的描述，我猜参与者及其用例将遵循以下思路：

• 演员：顾客
  • 主要用例：购买产品。这可能会分解为几个子步骤，例如浏览/比较产品、选择产品（放入购物篮）、结帐等。还将提供支持UCs：检查订单状态、退货、投诉等
• 演员：会计职员
  • 用例：可能与检查订单/付款状态有关

……等等

当您开始为每个UC设计流程时，您可能会确定您需要与之交互的系统外部的其他组件，例如支付合作伙伴。如果你愿意的话，你可以把它们表演成演员（我不喜欢，但那纯粹是个人的）

您还将确定在实现UC行为方面发挥作用的系统的其他元素（例如销售数据库等）。这些是系统的一部分，通常不会显示为参与者

总之：用例旨在帮助您确定系统的用途以及从中获得价值的人，而不是构建内部设计组件

---

hth.

用例不是绝对的。您可以在系统的第一个草图中有一个模糊的用例，例如

管理用户

（我不确定托管用例是否是一个好的实践，但这是为了一个示例…），然后将其分解为更详细的用例图，在此过程中不断细化，直到形成一个基本特性

至于第二个问题，这些听起来像是典型的域对象（将建模为基本类图）。我不认为他们应该被塑造成演员，除非他们扮演积极的角色。参与者可能是物理人，但也可能是与您正在创建的系统交互的其他系统。这些参与者最终可能会成为所谓的替代类

更新

通过查看，似乎使用了actor（与player同义）来限定要添加角色的目标对象。如果这是正确的，那么这个词就有不同的含义

角色是一种特殊类型的对象，可以为另一个角色添加行为 对象（演员或玩家）

---

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

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

用例必须表示定义良好的交互，但不一定是完整的交互。

关系可用于在同一级别上查看完整和部分交互用例的情况。你可以考虑使用一个用例<代码>买东西<代码>包括<代码>浏览产品< /代码>，<代码>添加产品到购物车和<代码>查看取消< /代码>，例如，每一个对客户都有意义。 （对于您的系统是用于实物交易还是在线交易，我有点困惑；有一个收银台和打印的收据似乎意味着前者，一个购物车作为分析中使用的概念的一部分，后者。以上假设一个在线系统。）

然而，在你的例子中，你谈论的是参与者，他们可能被认为是系统本身的一部分。这通常意味着您试图同时定义系统及其子系统，这在您在开始分析之前对（最终）系统设计有良好想法的情况下很常见

然后，您要做的是将分析分为两个级别。在上层（系统）层面上，要非常严格地对待整个系统。在您的情况下，您可能需要参与者

客户

，

支付合作伙伴

，

职员

（对于物理交易系统），

会计

（可能还有

管理员

），以及上面列出的用例，以及

更新产品目录

，

审核销售日志

，等等

然后将系统分解为子系统，并对每个子系统分别进行分析。在这里，子系统可以是彼此用例中的参与者<例如，代码>打印回执，在系统层面上不是一个有意义的用例，因为它本身不是系统与系统之间的交互