15.4.1. The problem in detail
Consider Figure 1. It shows a somewhat contrived model for a family and the birthdays of father and mother, respectively (all contexts). Both birthday contexts use an Aspect Party that has a role Present with a property Price. The role Present Father uses Present as Aspect Role and so does Present Mother. The result is that both Birthday Mother and BirthDay Father have a Price property on their Present roles.
Furthermore, the Father role of Family is a calculated role in Birthday Mother and has a perspective on Present Mother. Notice the cross-over: Father has access to the Price property of the Present Mother role; Mother has access to the Price property of the Present Father role.
Consequently, this perspective is inverted and attached to the Price property, leading to Birthday Mother, naming (the Calculated) Father role as one that should be informed when Price changes. Symmetrically, we have an inverted query from the Price property to Birthday Father.
But remember that Father is calculated. So when we detect a Price change in Present Mother, we first find an instance of Birthday Mother and then calculate Father.
Now look at the red lines from Price to Father and Price to Mother. They consist of many hops from entity to entity and this reflects the query path that connects the property to the user role that should be informed when the property changes (consisting of two parts: the inverted path from price to Birthday Mother, and the normal path from that context to the Father role of Family). Obviously, when the price of mother’s present changes (maybe a child sets it), father should know (but mother should not!).
We can now state the problem precisely. The two inverted queries are both stored with the definition of Property Price. When the actual property value of the actual role instance of Present Mother changes, we look up the inverted queries stored with Price and execute them to find the role instances that should be informed. So we find two queries. But, by coincidence, both queries will give a result when applied to either the price of Present Mother, or to the price of Present Father. Hence, we’ll find that both Father and Mother will be informed when the price of either present changes – clearly an unwanted situation and not the one that was modelled.
Figure 1. This model contains a synchronization problem for Price. The red lines are paths to follow when Price changes; the lines with long dashes represent an Aspect relation. The lines with short dashes represent the fact that the roles are calculated with respect to their contexts. So: Father is an Enumerated role of Family, and a Calculated role of Birthday Mother, while Price is an Aspect Property of Present Mother (and Present Father, too).