Perspectives Technical Documentation

14.3.3. Staged evaluation of state changes

Let’s suppose that SomeRole had been defined like this:

thing SomeRole
  on entry
    do
      AnotherProperty = 20

And let’s change action A as follows:

action A
  create role SomeRole
  SomeProperty = SomeRole >> AnotherProperty + 10 for SomeRole

This will compile, but after executing A, SomeProperty will not have a value. This is because execution of statements proceeds in stages. Let’s work this out for our example:

Stage 1 sees execution of
- the create role statement (but not its on entry clause!)
- the property assignment.
Stage 2 sees execution of the on entry automatic action of the newly created SomeRole instance.

The argument query SomeRole >> AnotherProperty of the property assignment in the action consequently finds no value, hence the entire addition expression has no value.

In other words: when a resource changes state during an execution stage, the effects of this state change will only occur in the next stage. That is, automatic actions due to state changes are postponed till all statements scheduled for the current stage have been executed.

Why this design? Our example is so small that it is easy to form a picture in our mind of how the on entry action would happen, before executing the property assignment. But things get very complicated quickly. Actions carried out automatically may trigger more automatic actions, recursively. The code describing this may be scattered all over a model. In no time at all it is very difficult to piece together what is happening where, when and why.

We’ve chosen this model because it allows the modeller to form a clear picture of what will actually happen locally, that is, the direct consequences for the state of the resources affected by his statements.

This is not to say that understanding automatic actions is always easy.

Another way of looking at this execution model is that state changes of various resources happen in parallel. If a statement sequence triggers state change with automatic actions in two other resources, these will execute (as if) in parallel. This means one should never count on a particular order of their execution!