Uml 序列图中的发生与执行规范，何时使用？

在序列图中，消息何时应源自发生规范，何时应源自执行规范

同样，消息的目标何时应该是这两个目标中的每一个

术语澄清

我知道大多数人可能不熟悉术语发生规范和执行规范，因此我在序列图上指出了它们

在以下描述中，有两条消息（用红色标记）：

• 从发生规范引出的m12，以及
• m2，从发生规范到执行规范（青色块）

大多数能够绘制UML序列图的工具在默认情况下都会在两侧放置一个执行规范——为什么就像我们的情况一样

及

---

有关这些术语的详细摘要，请参见

第578页上写着

ExecutionOccurrenceSpecification在生命线上表示ExecutionSpecification的开始事件或结束事件

及

ExecutionOccurrenceSpecification由生命线上ExecutionSpecification垂直框的开始或结束端点表示。见图17.2

所以他们只是标记出发生事情的时间点。实际上，规范中有许多示例，其中计时约束也与

ExecutionOccurrenceSpecification

一起应用

在p。567：

执行规范在生命线上用细矩形（灰色或白色）表示（见17.3.4（生命线））

我们还可以用一个更宽的带标签的矩形来表示ExecutionSpecification，其中标签通常标识已执行的操作。如图17.16所示

简单地说：在一个黑盒子里发生了一些事情

现在，对于

发生规范

，在第页的规范中有一个递归定义。566：

OccurrenceSpecification的语义只是单一OccurrenceSpecification的痕迹

对发生规范的理解和更深层次的含义取决于相关信息及其传达的信息

（哇！）。567：

OccurrenceSpecification只是消息末尾或ExecutionSpecification开头/结尾的语法点

实际上，

OccurrenceSpecification

只是

ExecutionOccurrenceSpecification

的一种更一般的形式

---

虽然图17.2使用了执行规范，但下图17.3等没有使用它们。因此，您可以随意使用它们。

消息的开始/结束点始终是一个事件

---

执行规范显示了活动的实例。对于启动实例，未定义是否应该执行。因此，不同的case工具开发人员采取了不同的方法。如果您可以决定，您可以描述实例是否保持活动状态（例如等待回答），但这是modeler的选择。

您的问题是，为什么有些工具在两侧都显示执行规范。原因很简单，他们对交互图的支持非常缺乏。消息的发送方和接收方都不需要执行任何操作，因此不需要执行规范

虽然通常可能是这样的，发送方执行某些行为，在此过程中发送某些消息，而消息接收方执行某个行为以响应接收消息，但情况并非总是这样。发送方可能会自发发送，接收方可能会忽略该消息。即使执行了某些操作，建模者也可能选择不提及它。交互图显示了一些有趣的事件，但并不需要显示所有可能的事件

消息可能以ExecutionOccurrenceSpecification开始或结束，但也可能只是MessageOccurrenceSpecification。ExecutionSpecification也可以独立于消息。也许建模者想要表达的是，一个对象正在执行某个东西，而没有受到任何消息的干扰。甚至可以定义正在执行的行为。然而，我还没有找到一个工具来支持UML的这个强制性特性

---

因此，答案是，工具应该允许消息和执行规范的任意组合，因为这完全取决于建模者，她希望显示哪些事件。

我刚刚发现Magic Draw 19.0 SP 1现在支持行为和操作执行规范。