在库存达到某一点时自动重新排序的用例中，参与者会是什么

Question

假设有5袋土豆，当它达到两袋时，订单会自动发送给供应商。演员是谁/什么？

Answer 1

显然，您有一个角色来监视队列，如下所示：

​

​

即使Potato Watcher是在SUC内部实现的东西，它本身也是一个参与者。您可以将其拖动到SUC边界内。在最终实现中，轮询队列或队列的订阅者可能是系统任务。但从附加值的角度来看，它只是一个简单的参与者，观察一个队列并对其做一些事情。

Answer 2

因为“订单是自动发送的”，所以系统就是参与者。假设你正在使用软件系统进行自动化。

然而，在现实生活中，这一切都出错了，企业离自动发送订单还很远。Badgerbadger，你需要注意“发送命令”这句话。我们很容易忽略实际的业务流程，之前的子功能级别的回答都起到了推动作用。

更现实的情况是，系统只是启动股票检查的参与者，可能是编排。然后有一个复杂的过程，获得批准，找到预算，检查是否真的需要订购商品等。理论上，所有这些都可以自动化，但在实践中，通常也会有人类参与者的工作。当然，你可能是幸运的，可以避免这一切。

要考虑的悲观场景示例：

1. 它是8袋，但现在是3袋。约翰刚刚从我们这里买了5个袋子，万岁！
2. 系统自动下订单并支付10个袋子。
3. 在10分钟内有人又订购了一个。
4. 系统自动再次下单并支付10个袋子。我们的账户上没有足够的钱，所以我们面对的是overdraft.

​

我们的同事

• 刚刚告诉我们，我们已经错过了供应商对同时订购25+包的八折折扣，这只能通过给公司打电话manager.

才能获得

​

1. John在下订单后的一个小时内取消了订单。
   • 现在我们有36个包，我们的预算有一个漏洞。
   • 和我们的营销经理刚刚告诉我们，订购的绿色包系统现在实际上是打折销售，我们正在淘汰它们，转而采用新的蓝色bags.

系列。

​

Answer 3

你必须在这里考虑各种可能性：

1. 每次使用库存时，系统都会检查是否满足订购条件，如果满足，则订购。由于订购可能涉及另一个参与者(例如供应商的系统)，您可能需要将其建模为单独的UC并使用扩展关系。在这种情况下，您将不会有任何其它参与者起动订单，只有一个起动库存用量的参与者。
2. 系统会定期检查哪些库存达到了自动订货层，并进行单个成批订单。在这种情况下，您必须将Scheduler建模为参与者(实际上，它是运行在服务器上的另一个系统，因此可以将其称为参与者)。有些人更喜欢将这样的演员建模为“时间”，但这是不受欢迎的。