Time 在活动图中同时表示并发性和时间

我不知道如何使用活动图来表达我的场景：

我试图想象的是这样一个事实：

• 收到一条消息
• 发生两个独立的并发操作：记录消息和处理消息
• 记录总是比处理花费更少的时间

图中的第一个活动是正确的，因为这些操作是独立的，但它并不传递这样一个事实，即日志记录所花费的时间肯定少于处理时间

图中的第二个活动是不正确的，因为即使日志记录在处理之前完成，处理看起来似乎取决于日志记录的第一次完成，而这并不代表实际情况

以下是一个与计算机无关的示例：

• 你是观鸟的新手，试着在笔记本上记下你的第一个关于鸟类经过的笔记

• 一群鸟走近，你试图识别尽可能多的细节

• 你想把细节写在笔记本上，但是等一下，你开始意识到你的理论背景在实践中不起作用，应该是快速涂鸦的东西实际上最终毫无意义，因为你什么都没认出

• 与此同时，鸟儿雄伟地飞走了，没有等你，活动也没有了

• 或者你真的写下来了，只花了你一瞬间，鸟儿还在附近，慢慢地飞走了，过了一段时间又结束了活动

• 或者你是如此的敬畏，以至于你一直盯着它们，没有做任何记录——它们飞走了，消失在地平线上，结束了活动

• 几个小时后，你有了足够多的笔记，回家后很开心——也许你没有捕捉到所有的东西，但这足以让你微笑

---

我总是可以在图表中添加注释来表达所有内容，但我想知道，是否有一种更结构化的方式来表达我在活动图表中描述的内容？如果不是活动图，那么您认为哪种图更适合您？谢谢。

您的第一个图表假定日志记录的持续时间总是短于处理时间：

• 如果此假设正确，则上游流将到达flow final节点，其余流将继续，直到第一个流到达activity final节点。在这里，处理继续进行，处理结束时活动结束。这正是你想要的
• 但是，如果有一次，执行将偏离此假设，并且日志记录将由于任何原因而延迟，那么处理的结束将到达activity final节点，导致所有其他正在进行的活动立即中断。因此，日志记录将无法完成。也许这对您来说不是问题，但在大多数情况下，审计期望日志是完整的

您可能对更安全的方式感兴趣，即添加联接节点：

优点是该活动不依赖于任何假设。它将始终有效：

• 每当日志记录速度加快时，该流上的令牌将在加入节点上等待，并且一旦流程完成活动（安全地），就可以进行加入，并且传出令牌到达终点。这正是你目前所期望的
• 如果日志记录速度异常缓慢，则没有问题：处理将结束，但活动将等待日志记录完成

这种强大的表示法使得日志记录就像薛定谔的猫在盒子里一样：我们不必知道什么活动更长或更短。活动结束时，两个操作都已完成

活动图中的时间？ 活动图并不是真正用来表示时间和持续时间的。它是关于控制流和同步的

但是，如果时间对您很重要，您可以：

• 视觉上使一项活动比另一项活动短。从形式化UML的角度来看，这是非常模糊和毫无意义的。但是，当读者看到平行流（一种底层通信；-）时，这是很直观的
• 添加注释，用通俗易懂的英语表达您的假设。这样做的好处是非常清楚和明确
• 使用UML持续时间约束。这通常用于时序图，有时用于序列图，但通常不用于活动图（我个人从未见过它，但UML规范也不排除它）

时间在UML规范中是非常通用的，并且是独立于图表定义的。例如：

8.4.4.2：持续时间是以特定于实现的文本格式给出的相对时间值。通常，持续时间是一个非负整数表达式，表示在此持续时间内可能经过的“时间刻度”数

8.5.1：间隔是两个值之间的一个范围，主要用于断言某个其他元素的值在给定范围内的约束。可以为任何类型的值定义间隔，但它们对于作为相应时间约束和持续时间约束的一部分的时间和持续时间值特别有用

在您的情况下，您有处理的持续时间观察（例如

d

），以及日志记录的持续时间约束（例如

0..d

）

8.5.4.2：间隔约束显示为其约束元素的注释。约束的通用表示法可用于IntervalConstraint，规范间隔以文本形式表示（…）

不幸的是，几乎没有人说更多。唯一的图形示例是序列图中的消息（图8.5和17.5）和时序图（图17.28至17.30）。尽管如此，该符号可以外推到活动图中，但它将b