14.1.2. Role state versus context state
A modeller might want to specify that a particular user is notified when a new instance of another role is created. At first sight we’d think this is about context state, as that is determined by its constituent parts. However, it turns out not to be possible to write a first order logic sentence that captures the notion of ‘a new role instance’. This is because the ‘newness’ is relative to a previous state only: we say an instance is new when it was not in existence earlier. But to recognise that situation, we’d have to write an expression that accesses a previous state. However, a Perspectives description of the world does not capture the flow of time; it is a timeless description. We can update that description to reflect a change in the world, but the updating itself is outside of the logical domain. A state condition cannot see it. That would require a whole level of description, and correspondingly a new mechanism to realise it.
However, we can think of this phenomenon in terms of role state. That is, if we interpret the coming-into-being of a role instance as a state transition that we can act upon. In other words, we can specify that our user must be notified in the on entry section of the role root state.
Another example of role state would be an invitation situation, where a Boolean property indicates rejection of the invitation. Again, notifying a user of such rejection can only be expressed in terms of state of the role instance, in this case not the entry of the root state but of some substate.
14.1.2.1. Automatic actions on Role state transitions
We want to be able to prescribe certain automatic actions to be carried out when a Role enters or exits a particular state. These automatic actions are assignments that will change state, possibly leading to new transitions. But what are these actions on?
For context states, we may have the origin variable we can use in statements. This variable will be bound to the current object set and is defined when the state transition is described in the lexical context of an expression that gives a role (we have two such lexical contexts: within a role definition and within the perspective on expression). We may have object; for in the onEntry and onExit expressions written in a top level state definition, no object is available and it is an error to refer to object in assignment statements.
For role states, we can always refer to the origin variable. It is bound to the role instance whose state changed.
Moreover, unless stated otherwise, a property assignment statement always changes the property values of the role instance whose state changed; i.e. the instance bound to object. So these two statements are equivalent:
PropertyType =+ 10 PropertyType =+ 10 for origin
Finally, we can always use the variable currentcontext in our expressions.