| Description |
An OsidOperator is an
OsidEnabler that governs the operational status
of an Operable. The OsidOperator
itself may be active or inactive. An Operable is
operational when any applied OsidOperator is
active. When all applied OsidOperators are
inactive, then the Operable is not operational.
If isRequirement() is true, then
this OsidOperator must be active regardless of
the state of any other applied OsidOperators.
Operables are active or inactive.
Operables may change their operational status
over time, but if two evaluations occur at the same point in
time each of the evaluations should see the same operational
status. For example, a bridge can be open or closed, but it
cannot be open for one car and closed for another car at the
same time. OsidOperators are rules which govern
the Operable status over time but
OsidOperators do not incorporate context that
varies from one perspective to the next.
OsidOperators define several built-in dimensions
to govern its operational status.
- effective dates: The
OsidEnabler is
operational during these dates and evaluated using a date.
- schedule: The
OsidEnabler is operational
when the date is occurs on the Schedule and
the date is within the effective dates.
- event: The
OsidEnabler is operational
when the date occurs within the Event and the
date is within the effective dates. Events
may be comprised of Schedules and other rules
making them discontinuous.
- cyclic event: The
OsidEnabler is
operational when the date cccurs within the
CyclicEvent and the date is within the
effective dates. CyclicEvents may be complex
recurring events but also recur from one time period to
the next, such as annually.
- time period: The
OsidEnabler is
operational during a TimePeriod.
- cyclic time period: The
OsidEnabler is
operational during a recurring TimePeriod.
For example, any Spring term.
|