Perspectives Technical Documentation

3.1.2. Perspectives

A perspective is not a type. A perspective governs what a particular end user, in some user role in a context, can perceive of a role in that context and how he can affect that role. We call the role that a perspective is about, the object role while the user role that the perspective is for is the subject role. A perspective may be built of three type of parts:

the role verbs that the subject role may apply to the object role, such as Create and Delete;
the property verbs that the subject role may apply to given properties of the object role, such as DeleteProperty and SetPropertyValue;
the actions that the subject role may execute. An action is a sequence of assignment statements executed in order, bundled under a name.

Assignment statements are not explained here. See the text Assignment. However, an assignment statement either changes a context by creating or deleting a role instance, or changes a role by filling it with a role (or remove that filler) or by changing the values of its properties.

Here is an example:

domain Parties
  case Party
    thing Wishes
    user Guest
      perspective on Wishes
        all roleverbs

User Guest can apply all role verbs to the Wishes role, in the Party context. In order to prepare ourselves for more involved texts whose meaning may not be immediately clear, lets dissect what we have.

We need two concepts: the current subject and the current object. We’ve already met the current context, and these two new concepts are just like it. Let’s pick the line all roleverbs as our lexical position. We must be able to establish for what user role this line is meant (as part of its perspective). Moving upward through the blocks, we encounter the type declaration line user Guest. Here is a rule: each user role type definition determines the current subject for its body. So we now know all roleverbs is meant for Guest.

How about the current object? Well, a perspective on determines the current object for its body. So, putting it all together, for our lexical position all roleverbs we have

Party as the current context
Guest as the current subject
Wishes as the current object.

Now it happens to be that any non-user role definition sets the current object. And we also have perspective of, setting the current subject. So the following model says exactly the same as our previous example:

domain Parties
  case Party
    thing Wishes
      perspective of Guest
        all roleverbs
    user Guest

Recapitulating: the current object is in scope in:

the block following a perspective on;
the body of a non-user role definition.

The current subject is in scope in:

the block following a perspective of <user>;
the body of a role definition that is a user role; idem
the block of assignments following do for <user>, defining an action (we’ll see examples below).
the expression following notify <user>.

In each of these cases, exactly one user role type is specified. Hence the current subject is always a single named type (but notice this may be a calculated role type that defines the disjunction of two types).