16.10.3 语义

Accept Event Action

AcceptEventAction是一个可以触发一个或多个Events的Action。当一个AcceptEventAction执行时，它等待能与自身触发器匹配的事件出现并将其从上下文对象的事件池中转发来完成执行。AcceptEventAction的上下文对象是它所从属的Behavior执行的上下文对象（有可能是Behavior执行自身，参见13.2.3）。从13.3.3讨论的角度看AcceptEventAction就是一个等待点，不同的是只有这个AcceptEventAction在等待，而不是整个Activity（在AcceptEventActions在等待的时候，Activity中的其它Actions可能在运行）。

如果与AcceptEventAction匹配的一个事件出现从事件池中被转发，那么AcceptEventAction就可以执行。然而，如果宿主Behavior执行有多个与此事件出现相匹配的等待点，那么只能有一个被选中来触发执行。如果某个AcceptEventAction被选中，那么它执行完毕后将结果输出到result OutputPins。

对于等待SignalEvent发生的AcceptEventAction也可以非正式地称作accept signal action。如果一个accept signal action的isUnmarshall=false，那么它必须有一个单一的result OutputPin，用来放置与接受的SignalEvent相关的Signal实例。如果isUnmarshall=true，那么对SignalEvent中的Signal的每个属性都会有一个result OutputPin，用于存放每个属性。

等待一个TimeEvent触发的AcceptEventAction也可以非正式地称为wait time action。wait time action必须有一个单一的result OutputPin。当它接受一个TimeEvent是，时间值就会被置于这个result OutputPin。

如果触发AcceptEventAction的都是ChangeEvents或CallEvents，那么AcceptEventAction没有result OutputPin（除非AcceptEventAction是一个AcceptCallAction，参见下面）。如果除了ChangeEvents和CallEvents外，触发器还包括SignalEvents或是TimeEvents，那么AcceptEventAction的isUnmarshall=false，且有一个单一的result OutputPin，当接受到的是一个ChangeEvent或CallEvent是，它会放置一个空的token。

注意. 尽管AcceptEventAction通常可以包含CallEvents的触发器，它不能接受同步的调用，除非它是一个AcceptCallAction（参见下面）。

如果AcceptEventAction可以被一个AnyReceiveEvent触发，并且用于消息的事件出现没有与此AcceptEventAction的SingalEvent或CallEvent触发器匹配，那么该事件出现就与这个AnyReceiveEvent触发器匹配（参见13.3.3中对Message Events的讨论）。

如果AcceptEventAction用在一个Activity中，对于它的使能还有特殊的规则（参见13.2.3中对于ActivityNodes使能的讨论）。如果AcceptEventAction没有入边，根据通常的规则，当包含它的Activity（或者StructuredActivityNode）开始执行时，它就可以运行。然而，除此之外，一个没有入边的AcceptEventAction在接受到一个事件出现后能然是使能的（enabled）。也就是说，在接受到一个事件出现和输出一些之后，它并不终结，而是继续等待另一个事件出现。这样的一个AcceptEventAction会在直接包含它的Activity（或StructuredActivityNode）终结时终结。

Accept Call Actions

AcceptCallAction是一个专用于处理CallEvent出现的AcceptEventAction。它必须有一个单一的CallEvent触发器。对于CallEvent中所识别的Operation的每一个in和inout自有参数（ownedParameters），它都有一个result OutputPins与之对应。此外，它还有一个returnInformation OutputPin用来提供同步调用所需的返回信息。

AcceptCallAction在匹配CallEvent出现时与通常的AcceptEventAction处理方式一样。与调用消息相关的参数值被置于result OutputPins。此外，用于执行一个随后的ReplyAction（参见下面）所需的信息被置于returnInformation OutputPin。返回信息值的内容在本规范中没有被定义，并且只能用于ReplyAction。

被一个异步的调用所触发的AcceptCallAction仍然会在returnInformaiton OutputPin产生一个值，但接受该值的ReplyAction在异步调用下会立即结束，不产生任何效果。

注意. AcceptCallAction的CallEvent中引用的Operation不应该有一个相关的方法（method）Behavior。否则，对Operation的调用将会产生立即执行这个方法的效果而不会被放置于上下文对象的事件池。从而对Operation的调用永远也不会被转发到AcceptCallAction。（参见13.3.3中对事件转发的讨论。）

Reply Actions

ReplyAction结束对前一个AcceptCallAction（参见上面）中调用的处理。它们两个通过一个返回信息值连接起来，这个值是由AcceptCallAction在它的returnInformation OutputPin产生的，并由包含的Behavior（例如Activity中的一个对象流）放置在ReplyAction的returnInformaiton InutPin中。ReplyAction也识别一个触发器，它应该与关联的AcceptCallAction所拥有的CallEvent触发器相同。ReplyAction的replyValue InputPins应该与CallEvent中识别的Operation的out、inout，以及返回的自有参数依序相对应。

当ReplyAction执行时，它使用replyValue InputPin的值为原始的调用请求消息生成一个应答消息。对于一个同步调用，returnInformaiton InputPin的值用于识别应答消息要发往的调用者。然而，如果返回信息值是一个异步调用的结果，那么不需要发送应答消息，ReplyAction结束不产生任何效果。发送调用请求、编码返回信息，以及发送应答的详细细节在本规范内未定义。

返回信息可能被拷贝、存储在对象中，以及被传递，但它只能在ReplyAction中使用一次。如果相同的返回信息提供给第二个ReplyAction，其语义是未定义的。如果返回信息值与ReplyAction的replyToCall触发器识别的Operation不是同一个，那么语义也是未定义的。然而，不推荐任何profile或执行引擎赋予这些未定义情形为非错误的其它意义。

注意. 如果一个ReplyAction没有在一个同步调用的返回信息上执行，那么调用者将不会收到一个应答，因此将不会结束执行。这并不是不合法的，但通常是我们不希望的。

Unmarshall Actions

UnmarshallAction从一个对象的StructuralFeatures读取值，并将它们置于OutputPins。对象由object InputPin给定，它与给定的unmarshallType Classifier的类型相同，且multiplicity为1..1。UnmarshallAction与unmarshallType（至少有一个属性）的每个Property依序有相应的result OutputPin。

Signal拥有的Properties是有序的，但一个Classifier可能从其它Classifiers继承Properties。此种情形下，unmarshallType的Properties是有序的，其中自有Properties先于所继承的Properties。进一步的，如果unmarshallType的两个祖先具有直接或间接的泛化关系，那么更特化的Classifier所拥有的Properties在次序上先于更一般化的Classifier。然而，对于没有传递关系的泛化关系的多继承情况下，没有定义一个标准的次序。

当UnmarshallAction执行时，从InputPin获取对象，从该对象读取unmarshallType的Properties的值，将它们置于相应的OutputPins。如果某个Property是有序并且多值，那么这些值按序置于相应的OutputPin。

UnmarshallAction很有用，例如，可以获取由AcceptEventAction（isUnmarshall=false）产生的一个Signal实例的属性值。