Aliases provide a means of using scope to specify elements of a collection; more specifically, we are using aliases (expressed or declared in the Scope section of the Rulesheet) to represent copies of collections. This concept is important because aliases give you the ability to operate on and compare multiple collections, or even copies of the same collection. There are situations where such operations and comparisons are required by business rules. Such rules are not easy (and sometimes not possible) to implement without using aliases.
Note: To ensure that the system knows precisely which collection (or copy) you are referring to in your rules, it is necessary to use a unique alias to refer to each collection.
For the purposes of illustration, we will introduce a new scenario and business Vocabulary. This new scenario involves a financial services company that compares and ranks stocks based on the values of attributes such as closing price and volume. A model for doing this kind of ranking can get very complex in real life; however, we will keep our example simple. Our new Vocabulary is illustrated in a UML class diagram in the following figure:
Figure 99. Security Vocabulary UML Class Diagram
This Vocabulary consists of only two entities:
Security – represents a security (stock) with attributes like security name (secName), ticker symbol, and rating.
SecInfo – is designed to record information for each stock for each business day (busDay); attributes include values recorded for each stock (closePrice and volume) and values determined by rules (totalWeight and rank) each business day.
The association between Security and SecInfo is 1..* (one-to-many) since there are multiple instances of SecInfo data (multiple days of historical data) for each Security.
In our scenario, we will use three rules to determine a security's rank:
Finally, rules will be used to assign a rank based on the total weight. It is interesting to note that although the rules refer to a security's closing price, volume, and rule weights, these attributes are actually properties of the SecInfo entity. Rulesheets that accomplish these tasks are shown in the next two figures.
Figure 100. Rulesheet with Ranking Model Rules 1 and 2
In the figure above, we see two business rules expressed in a total of four rule models (one for each possible outcome of the two business rules). The rules themselves are straightforward, but the shortcuts (alias values) used in these rules are different than any we have seen before. In the Scope section, we see the following:
Figure 101. Close-up of the Scope Section from Rulesheet with Ranking Model Rules 1 and 2
Security is the scope for our Rulesheet, which is not a new concept. But then we see that there are two aliases for the SecInfo entities associated with Security: secinfo1 and secinfo2. Each of these aliases represents a separate but identical collection of the SecInfo entities associated with Security. In this Rulesheet, we constrain each alias by using Filters; in a later example, we will see how more loosely constrained aliases can represent many different elements in a collection when the Corticon Server evaluates rules. In this specific example, though, one instance of SecInfo represents the current business day (today) and the other instance represents the previous business day (today.addDays(-1).)
Note: For details on the .addDays operator, refer to that topic in the Rule Language Guide.
Once the aliases are created and constrained, we can use them in our rules where needed. In the figure Rulesheet with Ranking Model Rules 1 and 2, we see that the use of aliases in the Conditions section allows comparison of closePrice and volume values from one specific SecInfo element (the one with today's date) of the collection with another (the one with yesterday's date).
The following figure shows a second Rulesheet which uses a Nonconditional rule to calculate the sum of the partial weights from our model rules as determined in the first Rulesheet, and Conditional rules to assign a rank value between 1 and 4 to each security based on the sum of the partial weights. Since we are only dealing with data from the current day in this Rulesheet (as specified in the Filters), only one instance of SecInfo per Security applies and we do not need to use aliases.
Figure 102. Rulesheet with Total Weight Calculation and Rank Determination
We can test our new rules using a Ruleflow to combine the two Rulesheets. In a Ruletest which executes the Ruleflow, we would expect to see the following results:
1. The Security.secInfo collection that contains data for the current business day (we expect that this collection will reduce to just a single secinfo element, since only one secinfo element exists for each day) should be assigned to alias secinfo1 for evaluating the model rules.
2. The SecInfo instance that contains data for the previous business day (again, the collection filters to a single secinfo element for each Security) should be assigned to alias secinfo2 for evaluating the model rules.
3. The partial weights for each rule, sum of partial weights, and resulting rank value should be assigned to the appropriate attributes in the current business day's SecInfo element.
A Ruleflow constructed for testing the ranking model rules is as shown:
Figure 103. Ruletest for Testing Security Ranking Model Rules
In this figure, we have added one Security object and three associated SecInfo objects from the Vocabulary. The current day at the time of the Ruletest is 11/12/2008, so the three SecInfo objects represent the current business day and two previous business days. The third business day is included in this Ruletest to verify that the rules are using only the current and previous business days – none of the data from the third business day should be used if the rules are executing correctly. Based on the values of closePrice and volume in our two SecInfo objects being tested, we expect to see the highest rank of 4 assigned to our security in the current business day's SecInfo object.
Figure 104. Ruletest for Security Ranking Model Rules
We see the expected results produced above. Both closePrice and volume for 11/12/2008 were higher than the values for those same attributes on 11/11/2008; therefore, both rule1Weight and rule2Weight attributes were assigned their high values by the rules. Accordingly, the totalWeight value calculated from the sum of the partial weights was the highest possible value and a rank of 4 was assigned to this security for the current day.
As previously mentioned, the example above was tightly constrained in that the aliases were assigned to two very specific elements of the referenced collections. What about the case where there are multiple instances of an entity that you would like to evaluate with your rules? We will discuss just such an example next.
Our second example is also based on our security ranking scenario but, in this example, the rank assignment that was accomplished will be done in a different way. Instead, we would like to rank a number of securities based on their relative performance to one another, rather than against a preset ranking scheme like the one in Figure 100. In the rules for our new example, we will compare the totalWeight value that is determined for each security for the current business day against the totalWeight of every other security, and determine a rank based on this comparison of totalWeight values. A Rulesheet for this alternate method of ranking securities is shown in the next figure.
Figure 105. Rulesheet with Alternate Rank Determination Rules
In these new ranking rules, we have created aliases to represent specific instances of Security and their associated collections of SecInfo. As in the previous example, Filters constrain the aliases, most notably in the case of the SecInfo instances, where we filter secInfo1 and secInfo2 for a specific value of busDay (today's date). However, we have only loosely constrained our Security instances – we merely have a Filter that prevents the same element of Security from being compared to itself (when sec1 = sec2 ). No other constraints are placed on the Security aliases.
Note that we are not assigning specific, single elements of Security to our aliases. Instead, we are instructing the Corticon Server to evaluate all allowable combinations (i.e., all those combinations that satisfy the 1st Filter) of Security elements in our collection in each of the aliases (sec1 and sec2). For each allowable combination of Security elements, we will compare the totalWeight values from the associated SecInfo element for busDay = today, and increment the rank value for the first SecInfo element (secinfo1) by 1 if its totalWeight is greater than that of the second SecInfo object (secinfo2). The end result should be the relative performance ranking of each security that we want.
Figure 106. Rulesheet for Testing Alternate Security Ranking Model Rules
This figure shows a Ruletest constructed to test these ranking rules. In our data, we have added four Security elements and an associated secInfo element for each (note that each alias will represent ALL 4 security elements AND their associated secInfo elements). The current day at the time of the Ruletest is 2/9/2009, so each Security.secInfo.busDay attribute is given the value of 2/9/2009 (if we had included additional secinfo elements in each collection, they'd have earlier dates, and therefore would be filtered out by the Preconditions on each alias). We have initially set (or initialized) each Security.secInfo.rank equal to 1, so that the lowest ranked security will still have a value of 1. The lowest ranked security will be the one that loses all comparisons with the other securities - in other words, its weight is less than the weights of all other securities. If a security's weight is less than all the other security weights, its rank will never be incremented by the rule, so its rank will remain 1. The values of totalWeight for the SecInfo objects are all different; therefore, we expect to see each security ranked between 1 and 4 with no identical rank values.
Note: If there were multiple Security.secInfo elements (multiple securities) with the same totalWeight value for the same day, then we would expect the final rank assigned to these objects to be the same as well. Further, if there were multiple Security.secInfo entities sharing the highest relative totalWeight value in a given Ruletest, then the highest rank value possible for that Ruletest would be lower than the number of securities being ranked, assuming we initialize all rank values at 1.
Figure 107. Rulesheet for Alternate Security Ranking Model Rules
In this figure, our Ruletest results are as expected. The security with the highest relative totalWeight value ends the Ruletest with the highest rank value after all rule evaluation is complete. The other securities are also assigned rank values based on the relative ranking of their totalWeight values. The individual rule firings that resulted in these outcomes are highlighted in the message section at the bottom of the results sheet.
It is interesting to note that nowhere in the rules is it stated how many security entities will be evaluated. This is another example of the ability of the declarative approach to produce the intended outcome without requiring explicit, procedural instructions.
Figure 108. Ruleflow to test two Rulesheets in succession
