DRA in Design

Design tends to be the prerogative of techies – and is therefore elegant from the bottom up:  it uses the computational resources very efficiently.  Good design should also be elegant from the top down:  the structure of the solution should be parsimonious and reflect the structure of the decisioning.  Bottom-up design is very specific to the platform, so it is not possible to discuss it in this platform-neutral forum anyway.  Top-down design, however, can be purely functional.  This posting suggests how the decisioning structure exposed in the DRD can be used as the basis for designing a decision flow and an object model.

Designing a decision flow

For each decision point, identify in the DRD all the top-level decisions and all their sub-decisions.  These, together with their dependent knowledge and data nodes, comprise a "sub-DRD" defining the decisioning to be implemented in the decision service to be called at that decision point.  Note that if any decision occurs in more than one decision point you have two design options:  the results can be persisted externally after the first decision point and provided to the second decision point as data, or the decision can be evaluated at both decision points.  Which approach you choose will depend on a number of factors, including whether the data might change between the decision points.

Having prepared the sub-DRD for each decision point, strip it of all nodes except the decisions.  The arrows between these nodes specify a partial ordering of the decisions to be evaluated at this decision point.  This reduced network can be simplified further by removing tautological dependencies:  whenever two decisions are connected both directly and indirectly, remove the direct connection.  The partial ordering below is for the example DRD used in previous postings.

Partial ordering of decisions

Now linearise this partial ordering by choosing an arbitrary sequence for parallel nodes.  The result is a decision flow for a decision service providing the decisioning required at the decision point.

One possible decision flow


This of course assumes you need a decision flow, which is essentially a procedure for ordering decisions in a forward-chaining environment.  Excuse my bias as a Blaze user!  If you are working in a predominantly backward-chaining environment this may be unnecessary:  the dependencies between the decisions in the DRD may be used directly for chaining.

Designing an object model

During rule discovery the business terms required by the rules will have been identified and mapped to nodes in the DRD.  Input data will belong to data areas;  derived values will belong to decisions.  This natural structure should be used for the object model, because it is a whole data area or decision which is relevant or not to any particular decision point:  that is the unit of re-use.  The high-level structure below is based on our same example DRD.  All the detailed data properties and decision results should belong to one of the terminal nodes in this structure.

A natural object model structure

When decision values are persisted externally they should be presented back to subsequent decision points in exactly the same structure (i.e. in decision objects, not data objects).  This means that another decision using these values does not have to know whether they originated "locally" or from another decision point.  A safe (but sometimes costly) approach is that all the decision results from each decision point should be presented to every subsequent decision point.

This will be the last of my series of postings giving a basic introduction to DRA.  I hope it will be useful.