15.2.2. Perspectives on users: the user graph
In the most symmetrical case, every user type has a perspective on every other user type. This makes synchronisation easy. All we have to do for a given change is to calculate which peer types have a perspective on the structural element that has been changed, and then send the change to their instances.
This may be a context (to which roles may have been added), a role (that may have gotten a filler) or a role one of whose property values has been changed. Finally, we can have the situation that a new context instance has been created.
15.2.2.1. Hidden peers
But we can think of many realistic cases where peers do not all ‘see’ each other. For example:
-
In a scientific peer review, the reviewers are hidden to the authors;
-
In an examination, a second examinator may be hidden to the student;
-
A controller may have access to financial facets of sales contexts, without clients needing to see that controller;
-
A shop has many clients but these generally are not aware of each other.
In each of these situations, disclosing the identity of the hidden roles to the other peers may be considered a breach of privacy. Of course each participant can be aware that others may be involved in the context, by reflecting on the model. But they can never recover the identity of those others.
15.2.2.2. The User Graph
Consider a graph where the user roles form the nodes and the perspectives on user roles the edges. Incomplete graphs will reveal challenges to synchronisation, as we will see below. In fact, a first and immediate problem will be recognised when the graph consists of two unconnected subgraphs: in such a case, there are really two contexts, with peers that will never know of each other’s existence.
Why is that a problem? Because the PDR of a user is only able to communicate deltas to peers it knows about. So if a user in one subgraph makes a change, none of the users in the other subgraph will ever know about it – even if they have perspectives that would allow them to perceive the changed element. See Figure 1 for a simple example. We call this situation incomplete synchronisation.
Figure 1. The users are unconnected by perspectives, hence they form two separated subgraphs of the user graph. They both have a perspective on non-use role R. But a change to R made by either user will never be communicated to the other user.
The user graph shows us how users connect, gives us paths between user roles. We will use those paths to spread changes beyond the immediate circle of peers a given user can see.