An operation is a service that can be requested from an object to effect
behavior. In the UML metamodel it is a sub-class of
BehavioralFeature which is itself a sub-class of
Feature.
In the diagram, an operation is represented on a single line within the operation compartment of the class. Its syntax is as follows:
visibility name (parameter list) : return-type-expression {property-string}
You can edit this line directly in the diagram, by double-clicking on it. All elements are optional and, if left unspecified, the old values will be preserved.
A stereotype can be given
between any two elements in the line in the format:
<<stereotype>>.
The following properties are recognized to have special meaning: abstract, concurrency, concurrent, guarded, leaf, query, root and sequential.
The visibility is +,
# or - corresponding to
public, protected or
private visibility respectively.
static and final optionally
appear if the operation has those modifiers.
Any operation declared static will have its whole entry
underlined on the diagram.
There may be zero or more entries in the parameter list separated by commas. Every entry is a pair of the form:
name
:type
The return-type-expression is the type (UML datatype, class or interface) of the result returned.
Finally the whole entry is shown in italics if the operation is declared abstract.
The details tabs that are active for operations are as follows.
ToDoItemStandard tab.
PropertiesSee Section 17.7.2, “Operation Property Toolbar” and Section 17.7.3, “Property Fields For Operation” below.
DocumentationStandard tab. See Section 12.5, “Documentation Tab”.
SourceStandard tab. This contains a declaration for the operation.
ConstraintsStandard tab. There are no standard constraints
defined for Operation within the UML
metamodel.
Tagged ValuesStandard tab.
In the UML metamodel,
Operation has the following standard tagged
values defined.
semantics. The value is a
specification of the semantics of the
operation.
derived (from the
superclass, ModelElement). Values
true, meaning the operation is
redundant—it can be formally derived from other
elements, or false meaning it
cannot.
![]() | Note |
|---|---|
Derived operations still have their value in analysis to introduce useful names or concepts, and in design to avoid re-computation. | |
![]() | Note |
|---|---|
The UML | |
Go
upNavigate up through the package structure.
New
operationThis creates a new operation within the owning class of the current operation, navigating immediately to the properties tab for that operation.
![]() | Tip |
|---|---|
This is a very convenient way to add a number of operations, one after the other, to a class. | |
Add
parameterThis creates a new parameter for the operation, navigating immediately to the properties tab for that parameter.
Add
raised signalThis creates a new raised signal for the operation, navigating immediately to the properties tab for that raised signal.
DeleteThis deletes the operation from the model
![]() | Warning |
|---|---|
This is a deletion from the model not just the diagram. If desired the whole operation compartment can be hidden on the diagram using the style tab (see Section 17.7.2, “Operation Property Toolbar”) or the button 2 pop up menu for the class on the diagram. | |
NameText box. The name of the operation. The name of an operation has a leading lower case letter, with words separated by “bumpy caps”.
![]() | Note |
|---|---|
The ArgoUML critics will complain about operation names that do not have an initial lower case letter. | |
![]() | Tip |
|---|---|
If you wish to follow the Java convention of
constructors having the same name as the class, you will
violate this rule. Silence the critic by setting the stereotype
| |
StereotypeDrop down selector.
There are two UML standard stereotypes for
Operation (from the parent metaclass,
BehavioralFeature), create and
destroy.
![]() | Tip |
|---|---|
You should use | |
Navigate Stereotype
icon. If a
stereotype has been selected, clicking button 1
will navigate to the
stereotype property panel (see Section 17.4, “Stereotype”).
OwnerText box. Records the class which contains this operation.
Button 1 double click on the entry will navigate to the class.
VisibilityRadio box, with entries
public,
protected, and
private.
public. The operation is
available to any artifact that can see the owning
class.
protected. The operation is
available only to the owning class, or artifacts that are
subclasses of the owning class.
private. The operation is
available only to the owning class (and any inner
classes).
ModifiersCheck box, with entries
abstract,
leaf,
root,
query, and
static.
abstract. This operation has
no implementation with this class. The implementation must be
provided by a subclass.
![]() | Important |
|---|---|
Any class with an abstract operation must itself be declared abstract. | |
leafThe implementation of
this operation must not be overridden by any
subclass.
root. The declaration of
this operation must not override a declaration of the
operation from a superclass.
query. This indicates that
the operation must have no side effects (i.e. it must not
change the state of the system). It can only return a
value.
![]() | Caution |
|---|---|
Operations for user defined datatypes must always check this modifier. | |
static. There is only one
instance of this operation associated with the class (as
opposed to one for each instance of the class). This is the
OwnerScope attribute of a
Feature metaclass within UML. Any
operation declared static is shown underlined on the class
diagram.
ConcurrencyRadio box, with entries
sequential,
synchronized, and
concurrent.
sequential. Only one call to
an instance (of the class with the operation) may be
outstanding at any one time. There is no protection, and no
guarantee of behavior if the system violates this
rule.
guarded.
Multiple calls from concurrent threads may occur simultaneously to one
instance (on any guarded operation), but only one is allowed to
commence.
The others are blocked until the performance of the first
operation is complete.
![]() | Caution |
|---|---|
It is up to the system designer to ensure that deadlock cannot occur. It is the responsibility of the operation to implement the blocking behavior (as opposed to the system). | |
concurrent. Multiple calls
to one instance may execute at the same time. The operation
is responsible for ensuring correct behavior. This must be
managed even if there are other sequential or synchronized
(guarded) operations executing at the time.
ParameterText area,
with entries for all the parameters of the operation (see Section 17.8, “Parameter”).
A new operation is always created with one new parameter,
return to define the return type of the
operation.
Button 1 double click on any of the parameters navigates to that parameter. Button 2 click brings up a pop up menu with four entries.
Open. Navigate to the
selected parameter.
Add. Create a new parameter
and navigate to it.
Move Up. Only available where
there are two or more parameters, and the parameter selected is
not at the top. It is moved up one.
Move Down. Only available where
there are two or more parameters listed, and the parameter
selected is not at the bottom. It is moved down
one.
Raised SignalsText area, with entries for all the signals (see Section 17.9, “Signal”) that can be raised by the operation.
![]() | Caution |
|---|---|
ArgoUML at present (V0.14) has limited support for signals. In particular they are not linked to signal events that could drive state machines. | |
Button 1 click on any of the signals navigates to that parameter. Button 2 click brings up a pop up menu with four entries.
Open. Navigate to the
selected signal.
Add. Create a new signal
and navigate to it.
Move Up. Only available where
there are two or more signals, and the signal selected is not at
the top. It is moved up one.
Move Down. Only available where
there are two or more signals listed, and the signal selected is
not at the bottom. It is moved down one.