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
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.