Perspectives Technical Documentation

Often, we want to make sure that the users of an application take note of some changes. In our party example, it is important for the person throwing the party to note that his invited guests accept (or reject) the invitation. To make sure that some changes do not go unnoticed, we introduce the mechanism of notification.

A notification is something that draws the end users’ attention. Usually, a notification also consists of some message (like a line of text). Crucially, a notification should happen under specific circumstances. In Perspectives, we model this with state transitions.

A context can be in a specific state, and so can a role. This state must be defined in terms of its roles (for a context), while the state of a role is defined in terms of its filling role and/or property values. In Perspectives we can write an expression with some truth (Boolean) value to define a state.

Here is an example:

The state declaration line shows that role state Accepted is simply determined by the value of the Boolean property Accept. As soon as the end user playing the Guest role sets that property to true (e.g. by ticking a box in the invitation screen), the Guest role enters the state Accepted, or transitions to that state.

But what was the previous state of Guest? By default, each context or role is in its resting, or Root, state. So by ticking the box, role Guest transitions from Root state to Accepted state.

Let’s do some lexical analysis. notify Organizer is our lexical position of interest. What is the state transition it applies to? Following the nested scopes upward, we encounter an on entry line. This specifies a transition type (there is only one alternative: on exit). But entry of what state? Continuing our exploration of nested scopes upward, we encounter the state type declaration line for Accepted. Here’s another rule: in the body of a state type definition, that state is the current state. This completes our quest: notify Organizer applies to entering state Accepted.

A little more on the nature of notifications. In the example above, we might be tempted to notify the Organizer with the text “I will come” rather than “X has accepted.”. After all, it is the Guest who accepts and this could be his personal message to the Organizer.

But a notification is not a message from one user to another. It is more like an act of observation by the notified user. The difference is subtle: users should be observant and note what happens to contexts they play a role in. The notification mechanism merely aids them in actually noting that some changes have occurred. It is not a conversation mechanism; we have other means for that.