Dependency Manager Concepts

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:

• Dependent

  A derived data item whose value is calculated from other data items (precedents).

• Precedent

  A data item whose value may be used to calculate derived data items (dependents).

• Dependency

  A record of the fact that the value of a particular dependent depends on the value of a particular precedent.

• Precedent Change Item

  A record of the fact that the value of a particular precedent has changed in some way.

• Precedent Change Set

  A set of precedent changes items, grouped together for processing; used to identify potentially affected dependents which require recalculation.

• Dependent 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:

• the claimant's personal details;
• evidence gathered for the claimant's case; and
• benefit rates and income thresholds.

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):

So, to look at some examples from the dependency matrix:

• The entitlement for case 123 depends on Joe's personal details but not on Mary's;
• Joe's personal details are used in the calculation of both his cases (123 and 124); and
• All the cases use the benefit rates and income thresholds but not the allowance rates.
• No case's entitlement depends on Frank's personal details.

Note that the matrix can be read:

• by column, to understand all the precedents upon which a particular dependent depends - these are the set of dependencies that must be maintained every time a dependent is calculated; and/or
• by row, to understand all the dependents which depend upon a particular precedent - these are the set of dependents that must be recalculated every time the value of the precedent changes.

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:

(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.