在活动图中表达并发性和时间

如何解决在活动图中表达并发性和时间

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

我试图想象的事实是：

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

图中的第一个活动是正确的，因为这些动作是独立的，但它并没有传达这样一个事实，即日志记录的时间肯定比处理时间短。

图中的第二个活动是不正确的，因为即使日志记录在处理之前完成，看起来好像处理依赖于日志记录的先完成，这并不代表现实。

这是一个非计算机相关的例子：

• 您是一名观鸟新手，正在尝试在您的笔记本中记录有关鸟类经过的第一个笔记

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

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

• 其间，鸟儿不等你，威风凛凛地飞走了，活动结束了

• 也许你真的把它写下来了，只花了你一会儿，鸟儿还在附近，慢慢地飞走，一段时间后再次结束活动

• 或者你可能因为敬畏而一直注视着它们，没有做任何笔记——它们飞走了，消失在地平线上，结束了活动

• 几个小时后，你有足够的笔记，你很高兴回家 - 也许你没有捕捉到一切，但这足以让你微笑

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

解决方法

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

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

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

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

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

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

活动图中的时间？

活动图并不是真的要表达时间和持续时间。这是关于控制流和同步。

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

• 视觉上使一项活动比另一项活动更短。从正式的 UML 的角度来看，这是非常模糊和绝对没有意义的。但是，当读者看到平行流程（一种潜意识的交流;-)）时，这是很直观的。
• 添加注释以用简单的英语表达您的假设。这样做的优点是非常明确无歧义。
• 使用 UML 持续时间约束。这通常用于时序图，有时用于序列图，但一般不会用于活动图（我个人从未见过，但 UML 规范也不排除它）。

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

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

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

在您的情况下，您有处理的持续时间观察（例如 d），以及日志记录的持续时间限制（例如 0..d）。

8.5.4.2：IntervalConstraint 显示为其受约束元素的注释。 Constraints 的一般表示法可用于 IntervalConstraint，规范 Interval 以文本方式表示 (...)。

不幸的是，没有多说。唯一的图形示例是序列图中的消息（图 8.5 和 17.5）和时序图（图 17.28 到 17.30）。尽管如此，该符号可以推断为活动图，但它太不常用了，我宁愿推荐注释注释。