Uml 循环的活动图迭代次数固定，如果迭代结束，则指向不同的活动

我开发了以下活动图

客户被要求付款，如果他在5天内没有付款，公司会打电话给客户，如果他仍然想要上课，公司会得到更新。但是，我想重复这个循环，我们检查是否在5天内收到付款，并打电话给客户进行更新，因为公司会容忍这3次，否则预订将被取消。然而，我不确定如何在我的活动图上显示这一点

初次尝试后 一个简单的方法是，在您的

分公司5天内收到的付款/No

上添加一个新的决策节点：

客户已经联系了3次

，其中

No

将继续最初的呼叫流程，

Yes

将导致

取消预订

：

这假设您有一个计数器，用于计算每个付款请求的呼叫数

在您的叙述中，我们看到第一次通话与后续通话之间存在差异。在我看来，这种差异应该在

通过电话联系客户
的范围内处理，不需要特别注意。然而，如果活动在初始调用和提醒所采取的动作之间的差异较大，则可能需要考虑更复杂的分支。但原理是sam：您将使用两个决策节点来检查呼叫计数器

另一种方法
实际上，没有循环。打电话的人没有等待付款到达再打第二个电话。原则上，
收到的付款请求
将毫不延迟地引导到决策节点，并且不会在那里停留5天。这5天对人类读者来说是可以的，但充满了歧义。例如，您是否会在每次通话后等待5天？如果在第6天收到了付款，但打电话的人在第5天没有立即打电话，等等，该怎么办

为了解决这样的时间问题，您最好使用本文中解释的时间事件。这允许您清楚地显示正常流程，并隔离时间驱动的活动

（顺便说一句，因为我们看到实际上活动与付款请求的状态相关，所以您可以用状态图优雅地补充活动图。）
请注意：此图显示了使用多个传入控制流的常见错误。在UML中，这相当于一个连接节点，因此，这里不会发生任何事情。第一个动作是等待两个令牌，但左侧的令牌永远不会到达。您需要使用合并节点。最后一个动作也是如此。在这里，我将使用两个动作，因为确认与取消是非常不同的。请参阅我关于为此目的使用计时器的回答：