Whenever the value of one data item is derived from the values of one or more other data items, then we say that the derived value depends on the values used to derive it. If one or more of the values depended on subsequently change, then the derived data item must be recalculated to obtain its new value.
The Dependency Manager uses the following terms to encapsulate these concepts:
A derived data item whose value is calculated from other data items (precedents).
A data item whose value may be used to calculate derived data items (dependents).
A record of the fact that the value of a particular dependent depends on the value of a particular precedent.
A record of the fact that the value of a particular precedent has changed in some way.
A set of precedent changes items, grouped together for processing; used to identify potentially affected dependents which require recalculation.
The recalculation of a dependent which is potentially affected by one or more of the changes to precedents in a precedent change set.
These concepts are best explained by way of an example.
Let's say that a claimant's entitlement to benefit is calculated from data such as:
Joe, a claimant, has two cases (123 and 124) and Mary, another claimant, has one case (125). There are cases and personal details for other claimants too, and also some allowance rates used for other calculations.
In this example, the calculated entitlement for each case is a dependent and the personal details, evidence and rates/thresholds are precedents.
We can draw a sparse matrix which shows the dependencies between the dependents and the precedents (an "X" signifies the presence of a dependency):
Precedent | Case 123's Entitlement | Case 124's Entitlement | Case 125's Entitlement | Case 126's Entitlement |
---|---|---|---|---|
Joe's Personal Details | X | X | ||
Mary's Personal Details | X | |||
Frank's Personal Details | ||||
Case 123's Evidence | X | |||
Case 124's Evidence | X | |||
Case 125's Evidence | X | |||
Case 126's Evidence | X | |||
Benefit Rates | X | X | X | X |
Income Thresholds | X | X | X | X |
Allowance Rates |
So, to look at some examples from the dependency matrix:
Note that the matrix can be read:
As the number of precedents and dependents in the system grow, the dependency matrix becomes very large. Because the matrix is only sparsely populated (i.e. each dependent depends on only a small fraction of the available precedents), the data in the matrix is stored only for dependencies which are present, as follows:
Dependent | Precedent | |
---|---|---|
Case 123's Entitlement | depends on | Joe's Personal Details |
Case 123's Entitlement | depends on | Case 123's Evidence |
Case 123's Entitlement | depends on | Benefit Rates |
Case 123's Entitlement | depends on | Income Thresholds |
Case 124's Entitlement | depends on | Joe's Personal Details |
Case 124's Entitlement | depends on | Case 124's Evidence |
Case 124's Entitlement | depends on | Benefit Rates |
Case 124's Entitlement | depends on | Income Thresholds |
Case 125's Entitlement | depends on | Mary's Personal Details |
Case 125's Entitlement | depends on | Case 125's Evidence |
Case 125's Entitlement | depends on | Benefit Rates |
Case 125's Entitlement | depends on | Income Thresholds |
Case 126's Entitlement | depends on | Case 126's Evidence |
Case 126's Entitlement | depends on | Benefit Rates |
Case 126's Entitlement | depends on | Income Thresholds |
(Note that the table above is shown sorted by dependent, which makes it easy to see the set of dependencies for each dependent, but it could also be shown sorted by precedent which would make it easy to see the dependents potentially affected by a change in that precedent's value.)
Let's say that Joe's personal details change. Because dependencies are recorded against Joe's personal details, the Dependency Manager is able to identify that cases 123 and 124 require recalculation. When the cases are recalculated, their entitlement values change (due to the change in Joe's personal details); but note that in typical situations, the dependencies themselves do not change - prior to the recalculation, case 123 depended on Joe's person details, the evidence stored against the case, the benefit rates and income thresholds, and the same is true after the recalculation.
It is possible for more than one precedent value to change simultaneously, for example if the agency chooses to alter both its benefit rates and its income thresholds then all cases must be recalculated. Naively, each case would be identified twice (once from the change to benefit rates and once again for the change to income thresholds); however, the Dependency Manager supports the grouping of these two precedent changes into one Precedent Change Set. When the Dependency Manager processes the Precedent Change Set it automatically filters out any duplicate dependents identified so that the minimum work necessary is performed to recalculate the dependents.