What is this series of articles about?

This is the twenty-third article in a series in which I describe a practical method of developing unambiguous natural language rule statements.  I've developed this method for a large Australian government agency that has selected the Business Rules Approach and the Object Management Group's Semantics of Business Vocabulary and Business Rules (SBVR)^[1] as representative of best rules practice.

The story so far

We’ve been looking at some of the rules governing airline passenger activities (such as booking flights, checking, and boarding) and airline operations.  So far we’ve created a set of rule statements, the fact types on which the rules are based, and some rule statement templates and sub-templates for generating rule statements.

We’ve also been developing a taxonomy of rules as well as a rule statement development method based on selection of the appropriate template and sub-template(s) for each type of rule.  The taxonomy, templates and sub-templates are listed in the [sidebar] along with all valid rule statements and supporting fact types.

The font and colour conventions used in these articles reflect those in the SBVR.^[2]  In addition, any technical terms (particularly those drawn from the field of linguistics) are rendered in a bold italic font.

More about definitional rules:  complex concepts

In the previous article^[3] I discussed definitional rules; this is a continuation of that discussion.  Any business providing services will of necessity develop concepts (with associated terms) to describe those services and the provision of them.  For example the term return journey has a quite specific meaning, expressed by the following definitional rule statement:

On reflection, this is probably a superior alternative to the approach adopted in an earlier article in this series, in which the individual components of the concept were defined (as in the following rule statements):

Comparison of these rule statements with RS182 reveals that RS83 and RS84 are not quite correct as they stand, as they do not take account of the fact that there can be more than one outgoing flight or return flight.  If these rule statements were to be retained, the following rewordings would be required:

Another concept that has quite a specific meaning, due to the constraints imposed by airline reservation systems, is signified by the term flight booking.  In particular, all passengers specified in a flight booking travel on all flights specified in the booking, depart from the same port(s), and travel to the same port(s).

Thus we can define flight booking using the following definitional rule statement:

Again this is probably superior to the approach, adopted earlier, of defining an individual component of the concept (as in the following rule statement):

Definitional or operative rule statements?

Does the existence of definitional rule statements obviate the need for corresponding operative rules?  It could be argued that if RS182 (or RS83 and RS84) exist, there is no need for the corresponding operative rule statements RS184 and RS185, similarly if RS183 (or RS85) exists, there is no need for the corresponding operative rule statement RS186.

I have even had it put to me that, if the data entry form has been designed in such a way as to prevent different cities being specified as the origin city of the first or only outgoing flight and the destination city of the last or only return flight, or different passengers on different flights, there is no need for operative rule statements such as RS184 to RS186.  That, I think, puts the cart before the horse.  The rules come first and forms should be designed to enforce as many rules as possible.  The fact that a form enforces a rule does not mean that the rule no longer needs to be documented.

The question still remains:  do we need the corresponding definitional rule statements as well as the operative rule statements?  If your focus is solely on documenting an online booking form, then only the operative rule statements are required.  If your focus is on documenting the concepts and terms used by the organisation and the meanings of those concepts and terms, then definitional rule statements are a means of doing that, as described in the previous article.^[3]

The role of the time dimension in rules

And now for something completely different!  Time can play various roles in rules.

Rules governing when something happens

Firstly, there are rules that govern when some event, activity, or process is obliged or permitted to occur (or prohibited from occurring).  For example we’ve already encountered rules that govern check-in and boarding times, such as RS96, RS102, and RS100 (reproduced here):

Rules governing statements about when something is to happen

Related to these are rules governing dates or times of events specified in requests for something to happen.  Again we’ve already encountered rules that govern the departure date and return date specified in flight booking requests (RS19 and RS20, reproduced here) and the departure times of flights specified in flight booking confirmations (there are many of these, of which RS87 and RS90, also reproduced here, are just a sample). 

How do these differ from the three rules reproduced above?  The difference is subtle but significant:  the intention of both classes of rule is to prevent something happening later than can be safely accommodated (and, in the case of RS102, earlier than is appropriate).  The difference with the rules reproduced below is that they deal with a person’s stated intention:  to fly on a particular day at a particular time.  These rules prohibit someone from stating the intention to do something that is impossible, impractical, prohibited, or in the past, whereas those reproduced above simply prohibit someone from doing such a thing.

Rules governing statements about when something happened

If a system provides for recording of events after they have occurred, that system should similarly prohibit someone from stating that something has happened that is impossible, impractical, prohibited, or in the future.  For example, an airline may provide a facility whereby, if a flight previously made does not appear in your frequent flier statement, you can ask for that flight to be added, in which case the following rule would apply:

A digression:  the use of ‘today’

Two rule statements in this article use the word ‘today’.  What does ‘today’ mean in these rule statements?  It is not, of course, the day on which the rule statement is authored, but the day on which the stated rule is applied to each transaction. 

What if there is a requirement to retrospectively test transactions for compliance with rules?  If today I check a flight booking request made yesterday against RS19, it may have quite legitimately specified yesterday as the departure date but that is earlier than today.  To avoid confusion, some practitioners (myself included) prefer not to use ‘today’ but instead refer to the date on which the transaction occurs, as in RS188 (an alternative to RS19) and RS189 (an alternative to RS187):

Recording the history of a changing attribute or relationship

There is frequently a requirement to record the history of a changing attribute or relationship.  This is done for an attribute by recording the value of that attribute during each of a series of time periods.  For example, the status of a member of a frequent flier program may change over time, and the airline may record not only the current status of each member but previous statuses and the time periods in which those statuses applied.  A record of a changing relationship is maintained by recording the time period(s) with which each pair of entities is associated.  For example, each trackable aircraft component (such as an engine, tire, rudder assembly, etc.) may be installed on different aircraft over time.

The time periods in such records are generally represented using start and end dates (or effective and expiry dates).  There is an implicit rule that governs all such time periods, namely that the start date cannot be later than the end date.  Such a rule can be expressed as if it governs the start date, as in RS190, or as if it governs the end date, as in RS191.

Do we need both of these rule statements?  In fact not only do we not need both but it is incorrect to specify both rule statements, since a quality criterion of the rule book is that no two rules duplicate each other.  So we need only one of them, but each of them is equally correct, so which do we choose?  I’ve heard it suggested that the rule governing the end date should be retained in favour of the rule governing the start date, because users normally enter the end date after the start date.  But what if a transaction containing a valid start date/end date pair is subsequently updated by changing the start date to be later than the end date?  We need a rule to govern the start date too.

This dilemma is best resolved by a rule statement, such as RS192, which governs the combination of start date and end date.

In fact, a start date and associated end date are not really separate data items but components of a complex data item defining a time period.

Other rules governing records of history

Where the history of a changing attribute or relationship is recorded, various rules may govern those historic records:

1. There is usually a temporal data non-overlap constraint, a requirement that the time periods specified in the records relating to a given person or thing do not overlap each other, e.g.:

2. There is usually also a temporal data completeness constraint, a requirement that the time periods specified in the records relating to a given person or thing are contiguous and between them completely span some other time period (in this case, the total period of membership of the member), e.g.:

Note that the ‘exactly one’ determiner in this rule statement implies the corresponding non-overlap constraint.  If a non-overlap constraint does not apply but the completeness constraint does apply, the determiner ‘at least one’ should be used instead.

3. There is usually also a temporal data inclusion constraint, a requirement that the time periods specified in the records relating to a given person or thing do not fall outside some other time period (in this case, the total period of membership of the member), e.g.:

4. A less obvious requirement raised in [4] arises from the fact that it is theoretically possible to create two records with two contiguous time periods and all other content identical.  For example, if Member #123 was assigned a new status both on 1 January 2010 and 5 April 2011, there should be a single status record for Member #123 that covers the period 1 January 2010 to 4 April 2011. 

There is, of course, nothing to stop us recording this situation using two otherwise identical Frequent Flier Member Status records covering the periods 1 January 2010 to 4 April 2010 and 5 April 2010 to 4 April 2011.  However, to do so causes a variety of problems, e.g., a query as to which members changed status in April 2010 would erroneously include Member #123.  Creation of such multiple records can be prevented by requiring (in this case) that a new status record only be created for a change of status, as in ‎RS196.  Date, Darwen, & Lorentzos refer to the presence of such multiple records as “circumlocution”; given the fact that these constraints require a temporal state of affairs to be recorded using a single record rather than multiple records, I refer to them as temporal single record constraints.

Time-dependent attributes

There are rules that govern time-dependent attributes or make permission dependent on a time-dependent attribute.  For example, we’ve already encountered various rules that make permission or obligation dependent on a passenger’s age, such as the following:

Note that RS154 and RS155 do not yet have the qualifying clause “at the time of travel”.  What are the implications of omitting that qualifying clause ?  Consider RS155:  someone approaching their 71st birthday and intending to travel after that birthday could apply for travel insurance to cover that journey.  Since the age restriction is based on assessment of the increased risk of claims from older passengers, the insurance company will base the acceptability of writing a policy on the age of the intending traveller at the intended time of travel; the fact that he or she is less than 71 years of age at the time they apply for the insurance is immaterial.

In fact, any rule statement referring to a time-dependent attribute should qualify the term signifying that attribute so as to make clear when the value of that attribute is to be tested by the rule, so RS154 and RS155 should be rewritten as follows:

To be continued...
In the next article, we will look at some templates to support time-related rules and revisit the way fact types provide a foundation for rule statements.

References

[1]  Semantics of Business Vocabulary and Business Rules (SBVR), v1.0.  Object Management Group (Jan. 2008).  Available at http://www.omg.org/spec/SBVR/1.0/PDF  

[2]  The font and colour conventions used in this and other well-formed rule statements and fact types in these articles reflect those in the SBVR, namely underlined teal for terms, italic blue for verb phrases, orange for keywords, and double-underlined green for names and other literals.   Note that, for clarity, less than well-formed rule statements will not use these conventions.  

[3]  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 22)," Business Rules Journal, Vol. 12, No. 8 (Aug. 2011), URL:  http://www.BRCommunity.com/a2011/b611.html  

[4]  Date, C. J., Darwen, H., & Lorentzos, N. A. (2003). Temporal Data and the Relational Model. San Francisco, CA, USA: Morgan Kaufman.

# # #