Read First: Event Diagram, Event Type, Operation, resultsIn/isResultOf A trigger rule detects the occurence of an event, tests some conditions before proceeding, then starts an operation if those tests succeed. A trigger rule must supply values for input variables to start an operation. It can calculate these values from the output of previously called operations in the event diagram containing the trigger, inputs to the event diagram, and states of any object that it can derive or access directly by name. Resulting event types of an operation An event diagram may give different trigger rules to each of the event types resulting from an operation. For example, when a woman has a baby, she is both no longer pregnant and a baby is born. Each of these events may have its own effects. An event diagram may also have trigger rules from only some of the event types resulting from an operation. In this case, the diagram may only notate those resulting events types that have trigger rules. Each diagram may choose a different subset of resulting event types to have trigger rules. Diagram-dependent event types An event type may be used in more than one event diagram, but the ocurrence of that event may not be detected by all trigger rules on those events. For example, in the event diagram below, the operation Order Business Cards is used in in a diagram for hiring an employee:
whereas in another case, it is used in the context of promoting an employee: Since Business Cards Ordered is an event type used in both diagrams, they will assign people to report to a new hire just because business cards are ordered. We can solve this problem by making the trigger rules more specific, for example: Business Cards Ordered --> Set Up Office While Hiring in the first diagram, and Business Cards Ordered --> Assign New Reports While Promoting in the second. We could also achieve the same thing by making the event type resulting from Order Business Cards more specific in each diagram. These techniques work unless the same operation is used more than once in the same diagram, for example: Here the diagram is both hiring and promoting, so the trigger rules must be even more specific to distinguish which branch is being taken in the process. OOIE tool-builders should avoid forcing users to write diagram-specific trigger rules, by automatically making the event types or triggers diagram-sensitive. When the user draws diagrams like the ones above, the tool should interpret it to mean that each event type resulting from an operation is actually a specialized type for that particular usage. This is an example of a role type as modelled by hasRoleType/isRoleTypeFor. Some events should not be automatically made diagram-sensitive, for example: Here we want Stock Price Goes Above Threshold to always be applicable, so that we don't miss an opportunity to buy. Events that external as the one above, should not automatically be made diagram-dependent.
Trigger rules have their own conditions and may also have control conditions. This message evaluates both. If the rule succeeds, it should arrange to set the bindings for input variables of the operation to be initiated.