Read Next: resultsIn/isResultOf, hasInput/IsInputOf, output/IsOutputOf,
Variable, Method, hasMethod/isMethodFor
Operation Precondition, Operation Postcondition
An operation in OOIE is a request to achieve a certain goal, independent
of the particular way that the goal is reached. For example, an
operation Fill Order is a request to fill an order, independent of how
the order is filled.
Operation as object type
Operations are a kind of object type because each time the operation is
started, an new object is created. For example, when an order is filled
by running the FillOrder operation, a new object of type FillOrder is
created at the beginning of the activity and destroyed at the end. This
way, there is a unique object representing the activity each time it
happens. The object can be used to record information about the
activity, such as how long it has been going, and to perform other
operations on it, like suspending, resuming, and aborting it.
Specialized operations
Read First: resultsIn/isResultOf, hasInput/IsInputOf, output/IsOutputOf
Method, Operation Precondition, Operation Postcondition
Like all object types, operations can be specialized by reducing the
number of instances they have (see specializes/generalizes). Since
operation instances exist only temporarily, specialization reduces the
possible activities that the process can have as instances.
There are a number of ways to do this:
1) Restrict the type of resulting events.
2) Restrict the types of objects that can be input or output.
3) Restrict the methods of the operation in such a way that the
number of instances is reduced without adding any new ones.
If the the operation is polymorphic, this can be done by
restricting the object types through which the operation can be
requested.
4) Restrict the precondition or postcondition so that the operation
can only be used in more restricted circumstances or create more
restricted conditions.
5) Restrict flow to a subset of the original flow.
Miscellaneous
Operations and Event Types are disjoint, that is, they cannot have
subtypes or instances in common. This isn't currently notated in the
meta-model.
Read Next: resultsIn/isResultOf, hasInput/IsInputOf, output/IsOutputOf,
Variable, Method, hasMethod/isMethodFor
Operation Precondition, Operation Postcondition
Subtypes: None
Read First: Event Diagram, Trigger Rule, Control Condition,
hasCreationEvent/isCreationEventFor
An external operation just diagrammatic sugar for an event that is not
caused by an operation in the diagram. These are called external
events. For example:

This diagram uses the external event Bill Paid, which is an event not
caused by an operation in the diagram. The diagram sends out an
invoice, then waits at the control condition before updating accounts.
When the event occurs saying that the bill has been paid, accounts are
updated.
Using an external operation adds no information, but makes it clearer
that some unknown operation is causing the event:

or

The external operation, shown in gray, is performed by the person
receiving the bill, so it is not under the control of this event diagram
The diagram can only detect that the bill has been paid. So the trigger
to the external operation is not a real part of the model. It is a
placebo, or "hopefully triggers". External operations in OOIE are
actually notated with a dashed border.
Users should generally not labelexternal operations, because it
constrains the processes that can cause the event. For example, if
there are a number of operations that may pay a bill, you don't want to
limit how the bill is paid by specifying it in the external operation.
In fact, the external operation may be any sort of operation, manual or
automatic. If you really think there is only one way to perform an
operation, then you can label the external operation:

In any case, tool-builders for OOIE should ignore external operations
when generated code, whether they are labelled or not.
Implementation of external events
The implementation of the external events is not specified
during analysis. The designer can choose to implement it as polling, or
as a accessor functions that check for event diagrams waiting for a
change, or in whatever way the designer thinks is best.