| uml
2.5规范将操作定义为
| 操作是一种行为特征
，可以由接口， 数据类型或类拥有。操作也可以被模板化并用作模板参数。操作可以在其特征分类器的实例上直接调用。该操作为这种调用指定名称、类型、参数和约束。 |
在该分类器的实例上调用操作，而该操作是该分类器的一个特征。如果操作标记为isquery，则该操作的执行将使系统的状态保持不变，则不会发生任何影响。默认值为假，因此假定操作具有影响并改变系统状态。
在uml中的操作最多可以有一个返回参数。操作在调用过程中可能引发异常。
操作可以在特征分类器的专门化中重新定义。这种重新定义可以专门化所拥有参数的类型，添加新的前置条件或后置条件，添加新引发的异常，或者以其他方式细化操作的规范。
当操作显示在图表中时，文本应该符合UML规范中定义的语法。注意，UML
2.2到UML 2.4规范似乎对操作的属性有错误的嵌套，使得属性的存在依赖于返回类型的存在。下面提供的语法是非规范的，与UML
2.5规范中的语法略有不同:
operation :: = [ visibility ]
signature [ oper-properties ]
操作的可见性是可选的，如果存在，它应该是以下之一:
visibility ::= '+' | '-' | '#'
| '~'
操作executequery是公共的，受ispoolable保护，
getQueryTimeout-具有包可见性，以及 clearwarnings是私有的。
操作的标记有可选的参数列表和返回规范
signature ::= operation-name '('
[ parameter-list ] ')' [ ':' return-spec ]
operation-name是操作的名称。参数列表是以下格式的操作参数列表
parameter-list ::= parameter [
',' parameter ]*
parameter ::= [ direction ] parm-name
':' type-expression [ '[' multiplicity ']' ] [
'=' default ] [ parm-properties ]
parm-name是参数的名称。类型表达式是指定参数类型的表达式。多重性是参数的多重性。Default是一个表达式，它为参数的默认值定义值规范。
文件有两个静态操作-create和slashify。create有两个参数并返回文件。
slashify是私有操作。操作listfiles返回文件数组。
操作getname和listfiles没有参数或参数被抑制
参数方向描述为以下之一:
direction ::= 'in' | 'out' | 'inout'
| 'return'
如果省略，则默认为“in”。
可选参数属性描述应用于参数的附加属性值。
parm-properties ::= '{' parm-property
[ ',' parm-property ]* '}'
如果存在，返回规范定义为：
return-spec ::= [ return-type
] [ '[' multiplicity ']' ]
返回类型是结果的类型，如果它是为操作定义的。返回规范还具有可选的返回类型多样性。
setDaemon操作有一个输入参数，而changeName只有一个参数
是输入和输出参数。静态枚举返回整数结果
同时也有输出参数-线程数组。
操作isDaemon显示返回类型参数。
它是表示选项，相当于返回操作结果:+isDaemon(): Boolean。
操作的属性是可选的，如果存在，应遵循以下规则:
oper-properties ::= '{' oper-property
[ ',' oper-property ]* '}'
oper-property ::= 'redefines'
oper-name | 'query' | 'ordered' | 'unique' | oper-constraint
操作的性质一般描述操作或返回参数，定义为：
- 重新定义oper-name - 操作重新定义了由oper-name标识的继承操作;；
- query - 操作不会改变系统的状态
- ordered -返回参数的值是有序的；
- unique-参数返回的值没有重复项
- oper-constraint -是应用于操作的约束
操作检查从超类重新定义继承的操作状态。
操作getPublicKey不会更改系统的状态。
操作getCerts返回有序的证书数组，没有重复。
方法
类拥有的操作可能有定义其详细行为的相关方法。
方法在现在已经过时的UML 1.4.2规范的词汇表中被简单地定义为
| 方法是操作的实现。它指定与操作相关联的算法或过程。 |
以下是UML 2.5规范中方法的解释：
| 一个操作也可以有一个方法，它是对其所需行为的详细定义。建模者有责任确保由操作方法建模的详细行为满足操作前后条件给出的行为要求。
但是，请注意，在方法行为的临时执行期间，不需要保留后置条件，而只需要在该行为执行完成的稳定点保留后置条件。类也可能具有不变的条件，这些条件在操作执行前后必须为真，但是在执行操作方法的过程中可能违反该条件。 |
方法解析是允许在调用操作时确定要使用的方法的过程。这一过程应考虑到
- 所请求的操作，
- 接收所述请求的对象
- 输入与请求相关联的参数值。
很奇怪的是
“UML规范并没有要求一致的UML工具支持任何特定的解决过程。一般来说，解决过程可能很复杂，包括诸如前后方法、委托等机制。在这些变化中的一些变化中，单个调用可能会执行多个行为。如果解析过程没有识别出任何方法，那么会发生什么是不确定的。”
根据操作的调用方式，可以同步或异步调用操作的方法。
抽象操作
UML 1.4.2中的抽象操作被定义为没有实现的操作——“类无法实现的操作”。实现必须由类的后代提供。
UML 1.4.2中的抽象操作以斜体显示，或者标记为{abstract}。
在UML 2.5中，默认情况下，行为特征必须在分类器中有一个实现，或者必须继承一些实现。所以默认情况下，一个操作必须有一个方法。
如果操作的isAbstract属性为true，则意味着该操作没有任何实现它的方法，期望实现将由更具体的元素提供。
在UML 2.5中抽象操作没有斜体符号，但是它可能仍然可以用{abstract}来标记。
|
