UML Operation

The UML 2.5 Specification defines operation as

Operation is a behavioral feature that may be owned by an interface, data type, or class. Operations may also be templated and used as template parameters. An operation may be directly invoked on instances of its featuring classifiers. The operation specifies the name, type, parameters, and constraints for such invocations.

Operation is invoked on an instance of the classifier for which the operation is a feature. If operation is marked as isQuery, execution of the operation leaves the state of the system unchanged, no side effects may occur. The default value is false, so operation is assumed to have side effects and change state of the system.

Operation in UML can have at most one return parameter. Operation may raise an exception during its invocation.

An operation may be redefined in a specialization of the featured classifier. This redefinition may specialize the types of the owned parameters, add new preconditions or postconditions, add new raised exceptions, or otherwise refine the specification of the operation.

When operation is shown in a diagram, the text should conform to the syntax defined in UML specification. Note, that UML 2.2 to UML 2.4 specifications seem to have wrong nesting for operation's properties, making presence of the properties dependent on the presence of return type. The syntax provided below is non-normative and slightly different from the one in UML 2.5 specification:
     operation ::= [ visibility ]   signature   [ oper-properties ]

Visibility of the operation is optional, and if present, it should be one of:
     visibility ::=   '+'   |   '-'   |   '#'   |   '~'

Operation executeQuery is public, isPoolable - protected,
getQueryTimeout - with package visibility, and
clearWarnings is private.

Signature of the operation has optional parameter list and return specification.

signature ::= operation-name  '('  [ parameter-list ]   ')'   [ ':' return-spec ]

The operation-name is the name of the operation. The parameter-list is a list of parameters of the operation in the following format:

parameter-list ::= parameter   [   ','   parameter   ]*

parameter ::= [ direction   ]   parm-name ':' type-expression   [   '[' multiplicity ']'   ]   [ '=' default ]   [ parm-properties ]

The parm-name is name of the parameter. The type-expression is an expression that specifies the type of the parameter. The multiplicity is multiplicity of the parameter. Default is an expression that defines the value specification for the default value of the parameter.

File has two static operations - create and slashify. Create has two parameters and returns File.
Slashify is private operation. Operation listFiles returns array of files.
Operations getName and listFiles either have no parameters or parameters were suppressed.

Direction of parameter is described as one of:

direction ::= 'in'   |   'out'   |   'inout'   |   'return'

and defaults to 'in' if omitted.

Optional parm-properties describe additional property values that apply to the parameter.

parm-properties ::= '{'   parm-property [   ',' parm-property ]*   '}'

Return specification if present is defined as:

return-spec ::= [ return-type ]   [   '['   multiplicity   ']'   ]

Return type is the type of the result, if it was defined for the operation. Return specification also has optional multiplicity of the return type.

Operation setDaemon has one input parameter, while single parameter of changeName
is both input and output parameter. Static enumerate returns integer result
while also having output parameter - array of threads.
Operation isDaemon is shown with return type parameter.
It is presentation option equivalent to returning operation result as: +isDaemon(): Boolean.

Properties of the operation are optional, and if present should follow the rule:

oper-properties ::= '{' oper-property   [   ',' oper-property ]*   '}'

oper-property ::=   'redefines'   oper-name   |   'query'   |   'ordered'   |   'unique'   |   oper-constraint

Properties of operation describe operation in general or return parameter, and are defined as:

• redefines oper-name - operation redefines an inherited operation identified by oper-name;
• query - operation does not change the state of the system;
• ordered - the values of the return parameter are ordered;
• unique - the values returned by the parameter have no duplicates;
• oper-constraint - is a constraint that applies to the operation.

Operation check redefines inherited operation status from the superclass.
Operation getPublicKey does not change the state of the system.
Operation getCerts returns ordered array of Certificates without duplicates.

Method

An operation owned by a class may have a related method that defines its detailed behavior.

Method was defined in the Glossary of the now obsolete UML 1.4.2 Specification simply as

Method is the implementation of an operation. It specifies the algorithm or procedure associated with an operation.

Below is the explanation of the method from the UML 2.5 Specification:

An operation may also have a method, which is a detailed definition of its required behavior. It is a modeler responsibility to ensure that the detailed behavior modeled by the method of the operation meets the behavioral requirements given by the pre- and postconditions of the operation.

Note, however, that the postcondition is not required to hold during the transient execution of the method behavior, but only at the stable point of the completion of execution of that behavior. A class may also have invariant conditions that must be true before and after the execution of the operation but may be violated during the course of the execution of the operation method.

The method resolution is a process which allows to determine a method to be used when operation was invoked. This process should take into account

• the operation being requested,
• the object receiving the request, and
• input parameter values associated with the request.

It is quite strange, that

"The UML specification does not mandate that a conforming UML tool support any particular resolution process. In general, the resolution process may be complicated, to include such mechanisms as before-after methods, delegation, etc. In some of these variations, multiple Behaviors may be executed as a result of a single call. If no methods are identified by the resolution process, then it is undefined what happens."

The methods of an operation may be invoked either synchronously or asynchronously, depending on how the operation is called.

Abstract Operation

Abstract operation in UML 1.4.2 was defined as operation without implementation - "class does not implement the operation". Implementation had to be supplied by a descendant of the class.

Abstract operation in UML 1.4.2 was shown with its signature in italics or marked as {abstract}.

In UML 2.5 a behavioral feature by default must have an implementation in the classifier or some implementation must be inherited. So by default an operation must have a method.

If isAbstract property of an operation is true, it means that the operation does not have any methods implementing it, with the expectation that implementations will be provided by more specific elements.

There is no notation in italics for the abstract operation in UML 2.5 but probably it could still be marked using {abstract}.

  Multiplicity