Effective rule processing may be the most important requirement in AOA and the most difficult to address in an automated development system. At the heart of the requirement is clarity: clarity of the data being processed; clarity of the transformation process rules themselves and clarity of the resulting data object structure. Of course, that clarity cannot come at the expense of any limitations on flexibility, as high productivity is of no value at all if it doesn’t deliver the necessary end system.

A related attribute to clarity is readability. This presentation has stated multiple times that the key to overall productivity is reusability, which is only possible if an object and its related rules can be understood and easily modified. Thus there is little emphasis in AOA on brevity of statements. Instead the emphasis is on the power and comprehensibility of individual statements and their combination into a set of rules.

As is probably expected at this point, clarity and readability revolve around the structure of the AOA object and the VML language that processes that structure. The VML language has been introduced earlier in this presentation in the AOA Components section. It is the single logical, procedural language that is used for all rules processing, whether that involves managing work flow or handling special customer algorithms, as is addressed in this section. The resulting operations can then be interpreted or generated into C or Java for execution.

Two examples of rules processing will be presented below, both from customer processing areas in OpenCUAS that deliver special flexibility and function. The first describes part of the billing rules that generate charges from the services provided for a student. The second describes part of the rules for generating Financial Aid awards from the many characteristics of a student’s record.

Billing Rules – Generating Student Charges

The billing rules in OpenCUAS provide particular flexibility. In the first sample shown,  the rule is looping through all enrollment entries to total credits for the term. However, there are several exceptions to the process, as Adult Studies classes are charged separately and there are two kinds of discounts that may be applicable, ESL and PBS. Because determining PBS eligibility itself involves checking several rules, it is defined separately and just executed here. Note that there are further exceptions in the handling of audited classes. What is particularly demonstrated in this sample is the complete flexibility of the rules.

In the second sample shown, the rule is generating charges when the student is considered part-time. A couple of points to note are:

The mSAChrgT object contains the student account transactions and associated charges. The entity, SAInternalRuleVariable, contains the charge per credit value and we need to position on the one with Name, “PT Chg/CR” to pick up the correct value. The rule gives an error if for some reason the charge wasn’t defined.

The rule provides for very precise wording of each charge item on the bill. Note the regular charge states “P/T Undergrad Tuition”, followed by a display of the number of credits. If a PBS Discount applies, a new billing line is generated stating “Undergrad Tuition PBS Disc, followed by a display of the number of credits. The example to the right shows several such billing lines, here shown as a small part of an MS Windows interface.

Financial Aid Auto Awarding – Generating Awards from Rules

As should be expected, the financial aid auto awarding rules provide considerable flexibility of function. However, they also provide an additional feature, which may be singular in the industry: They generate a detailed summary of how each rule component was evaluated, so the person running the rules not only sees the awards generated, but also a “play-by-play” description of the processes that went into generating those awards. A sample of the summary is shown to the right.

The key to the power and the flexibility of the rules is the object, mFAAutoR, part of which is shown to the right.  This object contains all of the data that will be used within the rules. If a new rule is developed that uses additional data, that data is simply added to mFAAutoR object. That object is activated at the beginning of rules processing for a student and is passed into each operation processing a set of rules.

A sample of the rules is shown to the right. Three things from the sample should be particularly noted.

A SummaryMessage is generated for each major processing decision, which are usually the awarding or aborting of an Award. The SummaryMessage is also duplicated as a DetailMessage.

A DetailMessage is generated to show the result of the execution of each rule component. The message is a combination of standard text for the rule and variable data from the object.

The rules are primarily composed of a series of checks against data in the object and messages displaying the results of those checks. For example, in one case, a check is made to see if the entity FAISIRParent exists, and if so, a second check is made against the value of the AdjustedGrossIncome attribute. Both are part of the student’s FAFSA definition and are necessary to get the parent’s AGI value.