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: