Where used: Event Diagram Model


Trigger_ Rule


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.


Hierarchy:

Attributes: None

Operations: