16.1 概要

Action是UML中行为规约的基本单元。Action可以有一些输入并产出一些输出，输入/输出可以为空。一些Actions可能会修改其所在运行系统的状态。

Actions被包含在Behaviors中，尤其是Activities（例如ExecutableNodes，参见15章）和Interactions（参见17章）。这些Behaviors决定Actions何时执行和所需的输入是什么。Actions的抽象语法和语义依赖于Activities，因为它们特例化（specialize）了来自Activities的元素和语义，使得它们可以接受输入并提供输出，并定义了可以整合其它Actions的Actions（结构化Actions，参见16.11）。此外，Actions的具体语法只能出现在活动图中（本章中所有的例子都使用Activity的表示），其中的一些表示法已经在15章中体现过。本章关注于Actions的语法和语义，而不是包含它们的Behaviors，但要更好的理解本章，需要与15章一块儿读。

具体语法

UML规范为Actions提供了一个相对来说最小化的图形化表示。但遵循本规范的工具可以提供一些工具特定的图形化或文本化的展现，只要它们可以映射到标准的Action抽象语法。这些展现被称作具体语法。例如，一个文本式具体语法可以被用来标注状态机（参见14.2.4）中Transtions所附加Behaviros的Actions。具体语法一般既包括基本的Actions，也包括Behaviors所提供的控制机制。

具体语法可以映射Actions抽象语法的高层构造块。例如，创建一个对象涉及初始化属性值或是创建一些必要的链接（Associations）对象。UML规范定义了CreateObjectAction，但它只是创建对象，还需要其它Actions来初始化属性值和创建必要的链接对象。一个具体语法可以用来表示一个包括初始化在内的操作，它可以用作替代一系列底层Actions的单一单元。通常，具体语法可以1对1地实现每个Action，或是定义高层的、复合的结构来为建模者提供更强的表达力和便捷性。

本规范中定义的绝大多数的基本Actions是为了提供更加广范的具体语法映射。特别是，一个基本的Action要么是一个计算，要么是访问对象内存，但不能二者兼得。这么做是为了支持与物理实现的清晰映射。

执行引擎

执行引擎是执行UML Actions的工具。执行引擎可以优化模型的执行以达到特定的性能要求，只要它遵循Actions的语义。例如，一个执行引擎可以在一个任务内完全顺序的执行，而另一个可以根据交互能力分配到不同的处理器，而其它的还可以以客户机-服务器、甚至是个三层架构的形式运行。只要这些优化是被UML语义所允许的，这些执行引擎就都是有效的。

当建模者具备特定的领域解决方案知识的时候，他可以给执行引擎提供（设计时）“提示”以帮助它们实现优化执行。但执行引擎并不需要遵循或检查这些提示。它可以假定建模者是正确的，或者忽略这些提示。执行引擎不必验证建模者的断言为真。

当Actions的执行违反UML的结构化语义时，该Actions的语义被视为无定义的。例如，通过合成（comosite）Associations的方式把一个实例链接到多个宿主的行为是未定义的。一些具体语法会把此视为非法的。运行时需要将Classes作为值的情况也被视为是未定义的。然而，在Actions的执行中，multiplicity的下限是被忽略的，但其语义仍是（完整）定义的，否则，就不可能使用Actions来传递构造满足multiplicity约束的对象配置所需的中间阶段。建模者必须指定何处需要满足最小化的multiplicity，而不是任意地方，否则对象的配置永远也不能够改变。