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

【问题标题】：Activity diagram iteration of loop for fixed number of times and point to a different activity if iteration ends循环的活动图迭代固定次数，如果迭代结束，则指向不同的活动
【发布时间】：2021-07-24 10:13:48
【问题描述】：

我开发了以下活动图。

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

【问题讨论】：

请注意：此图显示了使用多个传入控制流的非常常见的错误。在 UML 中，这相当于一个连接节点，因此这里不会发生任何事情。第一个动作是等待两个令牌，但左边的一个永远不会到达。您需要使用合并节点。最后一个动作也是如此。在这里，我将使用两个操作，因为确认与取消非常不同。
查看我关于为此目的使用计时器的答案：stackoverflow.com/questions/43990743/…

标签： uml activity-diagram

【解决方案1】：

在您最初的尝试之后

一种简单的方法是在您的Payment received witin 5 days / No 分支上添加一个新的决策节点：Customer already contacted 3 times 其中No 将继续初始流程调用，Yes 将导致Cancel booking：

这假设您有一个计算每个付款请求的呼叫次数的计数器。

在您的叙述中，我们看到第一次通话和后续通话之间存在差异。在我看来，这种差异应该在Contact client by phone 内处理，不需要任何特别的照顾。但是，如果在初始呼叫和为提醒而采取的操作之间的活动差异更大，您可能需要考虑更复杂的分支。但原则是相同的：您将使用几个检查呼叫计数器的决策节点。

另一种方法

实际上没有循环。拨打电话的人不会等待监控付款到达以拨打第二个电话。原则上，payment request received 会及时引导到决策节点，不会卡在那里 5 天。 5 天对人类读者来说还可以，但充满了歧义。例如，您是否还会在每次通话后等待 5 天？如果在第 6 天收到付款，但在第 5 天来电者没有立即致电等...

要解决此类计时问题，您最好使用其他 SO answer from qwerty_so 中解释的计时事件。这使您可以清楚地显示正常流程，并隔离时间驱动的活动。

（顺便说一句，由于我们看到实际上活动与付款请求的状态相关，您可以优雅地用状态图补充您的活动图。）

【讨论】：