The Business Use Case

The use case deals with rules for validating data.

These are the simplified rules. The actual rules as specified by the customer (a school) are in appendix A


Group 1

When Entry Code is E2A or E3A or E4A or E09

     *   Grade must be PK through 12

     *   Prior School District must be 99

     *   Prior School State must not be FL

     *   When Entry Code is E09

        *   Prior School Country must not be US

     *   When Entry Code is not E09 (and is one of the other 3 codes above)

        *   Prior School Country must be US

 


Group 2

When Entry Code is E01 or E02 or E03 or E04

     *   Grade must be PK through 12

     *   Prior School District must be 99

     *   Prior School State must be FL

     *   Prior School Country must be US

 


Group 3

When Resident Status is 5 or 7 or 0 or 2

     *   Resident District must be 99

When Resident Status is 4 or 6

     *   Resident District must not be 99

 

The attributes have been highlighted in red and the values in green.

The business object to which they belong is not stated but we’ll assume it’s a Student.


The Vocabulary

The vocabulary will look like this.

Notice that an attribute (isValid) has been added to indicate whether the record is valid or not. Since this value needs to be passed back to the calling application it is not marked as transient attribute.

Figure 1 Vocabulary




 

Design Options

There are a number of different ways we can choose to organize the rules.

  1. All of the rules in a single rule sheet
  2. A separate rule sheet for each group of rules
  3. Groups 1 and 2 in one rule sheet and group 3 in a second rule sheet

 

Corticon does not mind which choice we make. It can handle large numbers of rules in a single sheet, but putting all of the rules in one sheet may be less convenient for the person who has to maintain the rules.

If you examine the rules you can see that groups 1 and 2 use the same set of attributes. However group 3 uses a completely different set of attributes.

 

Design Option #3

For this reason we’ll use design option #3.

Using the ambiguity checker we find there are no conflicts in this rule sheet:

However, the completeness checker finds a number of missing rules:

What do these missing rules mean?

Well, rules 10, 12 and 13 actually express the conditions for a record to be valid.

However, since there are other rules on rule sheet 3 that might also flag a record as invalid we cannot mark the record as valid yet.

If we had all of the rules on a single sheet then we could explicitly set a record to valid or invalid as appropriate

Rule 11 is the condition when the entry code is none of the values explicitly mentioned in the rule specification.

At this point we don’t know if this represents an invalid record or if there are other (not yet specified) rules that deal with other values of the entry code.

Without knowing more our best approach is simply to create a warning rule message that identifies the unknown value.

 

 

 

Design Option #2 (All separate)

Group 1

Figure 2 Natural Language View

Figure 3 Rule Sheet for Group 1

Figure 4 Test Case for Group 1

Group 2

Figure 5 Rule Sheet for Group 2

Figure 6 Test Case for Group 2

Group 3

Figure 7 Rule Sheet for Group 3

Figure 8 Test Case for Group 3




 

Server Test

Figure 9 Server Test

 

Deployment

Rules are deployed as groups called a Decision Service.

A decision Service is defined by creating a rule flow diagram and dragging the appropriate rule sheets on to it. Arrows are drawn to indicate the order in which the rule sheets need to be executed. Within a rule sheet Corticon determines the order of execution.

For example:

  Or 

Depending on which rule sheets we want in the decision.

We can also define some properties for the decision service:

 

Figure 10 Web Console Decision Services

In this web console view you can see that there are two deployed versions of the Skyward decision service. Version 1.0 is deployed with an effective date of Jun17th but is superseded by version 1.1 which becomes effective on June 22nd.

When applications invoke the decision service by name only they will get the version that is affective on the date and time of the call. If they need to execute a prior (or even future) version then they can either specify the version number or the date.

 

Figure 11 Monitored Attributes

 

 

 

Design Variations

 

Appendix A

Original rules as specified by the school district: