14.1.3. How to use state in models
14.1.3.1. Defining state
We introduce into the written form of the Perspectives Language (PL) a new construct:
state <identifier> = <booleanQuery>
We can add a notification like this:
state <identifier> = <booleanQuery>
on entry
notify "Entering state X."
This will cause the system (i.e. the combination of the Perspectives Distributed Runtime (PDR) and the end user application, MyContexts) to bring this state change to the end users’ attention (the string may contain queries that must evaluate to string values).
This governs the first use of states: notification. No more is needed to bring state changes to the end users attention.
14.1.3.2. Using state to make things happen
A state change is an event and we can use it to make more things happen:
on entry of <state name>
do
<assignment>+
and
on exit of <state name>
do
<assignment>+
where, obviously, <state name> must refer to a defined state.
Such declarations are part of a user perspective. Automatic actions are only carried out on behalf of a user!
14.1.3.3. State in user perspectives
Finally, we use state in the specification of a user perspective:
perspective on: <RoleExpression>
in state <state name>
only Consult
in state <another state>
except Delete
action <identifier>
<assignment>+
This shows how some verbs are available to the user in just some states. It also illustrates an action available in just a single state. An action is a series of assignments that can be triggered as a whole by the end user. So, to prevent misunderstanding, an action is never carried out automatically, in contrast to rules and on-entry and on-exit assignments.