Business rules should be validated by business domain experts, and hence specified in a language easily understood by business people.  This is the sixteenth in a series of articles on expressing business rules formally in a high-level, textual language.  This article considers the verbalization of deontic rules.

The first article^[1] discussed criteria for a business rules language, and verbalization of simple uniqueness and mandatory constraints on binary associations.  Article two^[2] examined hyphen-binding, and verbalization of internal uniqueness constraints that span a whole association, or that apply to n-ary associations.  Article three^[3] covered verbalization of basic external uniqueness constraints.  Article four^[4] considered relational-style verbalization of external uniqueness constraints involving nesting or long join paths, as well as attribute-style verbalization of uniqueness constraints and simple mandatory constraints.  Article five^[5] discussed verbalization of mandatory constraints on roles of n-ary associations, and disjunctive mandatory constraints (also known as inclusive-or constraints) over sets of roles.

Article six^[6] considered verbalization of value constraints.  Article seven^[7] examined verbalization of subset constraints.  Article eight^[8] discussed verbalization of equality constraints.  Article nine^[9] covered verbalization of exclusion constraints.  Article ten^[10] dealt with verbalization of internal frequency constraints on single roles.  Article eleven^[11] considered verbalization of multi-role, and external, frequency constraints.  Article twelve^[12] discussed verbalization of ring constraints.  Article thirteen^[13] covered verbalization of basic subtype constraints.  Article fourteen^[14] discussed the need for subtype definitions, and how to verbalize them.  Article fifteen^[15] considered the verbalization of basic derivation rules.

Business Rule Modality

Business domains are constrained by various business rules, which specify required or desirable states of affairs or behavior.  Business rules may be of different modalities (e.g., alethic and deontic).  Alethic rules impose necessities, which cannot, even in principle, be violated by the business, typically because of some physical or logical law.  For example:  each employee was born on at most one date; no product is a component of itself.  Deontic rules impose obligations, which may be violated, even though they ought not.  For example:  it is obligatory that each employee is married to at most one person; no smoking is permitted in any office.  Using "constraint" in a liberal sense to include soft as well as hard constraints, deontic rules may also be called deontic constraints.

Various information modeling approaches exist for modeling business domains at a high level, for example Entity-Relationship Modeling (ER),^[16] the Unified Modeling Language (UML),^[21] and Object-Role Modeling (ORM).^[17]  However, with the exception of ORM 2 (second generation ORM), these modeling approaches typically confine their specification of constraints to alethic rules.  It is important for a business to have a clear understanding of all its rules, including deontic constraints, whether or not the business chooses to enforce these rules, or monitor violations of them, by means of an automated system.

In recognition of this need, as well as to facilitate exchange of semantics between businesses, the Object Management Group (OMG) is currently finalizing a proposal to specify a business semantics layer on top of its software-specific layers.  A draft version of this Semantics of Business Vocabulary and Business Rules (SBVR) proposal is now available^[22]  As a contributor to this submission, I focused on the formal logic underpinnings of SBVR, and elsewhere provided a technical discussion of rule modalities, including embedded deontics.^[19]  In this non-technical article, I merely provide an overview of the modal operators, and illustrate ways of verbalizing simple, static, deontic rules, where the only deontic operator is the main operator.  Because of its richer semantics, the main graphic notation used is that of ORM 2,^[18] as implemented in the NORMA tool.^[20]  However, the main ideas could be adapted for UML and ER.

Business rule formulations may use any of the basic alethic or deontic modal operators from modal logic, as shown in Table 1.  These modal operators are treated as proposition-forming operators on propositions (rather than actions).  Other equivalent readings may be used in whatever concrete syntax is used to originally declare the rule (e.g., "necessary" might be replaced by "required", and "obligatory" might be replaced by "ought to be the case").  The derived modal operator "It is forbidden that p" is defined as "It is not permitted that p" (Fp =_df ~Pp).

Table 1. Alethic and deontic modal operators

Alethic		Deontic
Reading	Symbol	Reading	Symbol
It is necessary that		It is obligatory that	O
It is possible that		It is permitted that	P
It is impossible that	~	It is forbidden that	F

The following modal negation rules apply:

it is not necessary that it is possible that not (~p ~p);

it is not possible that it is necessary that not (~p ~p);

it is not obligatory that it is permitted that it is not the case that (~Op P~p);

it is not permitted that it is obligatory that it is not the case that (~Pp O~p).

In principle, these rules could be used with double negation to get by with just one alethic modal operator (e.g., p could be defined as ~~p, and Pp could be defined as ~O~p).

In ORM 2, each rule has an associated modality, determined by the logical modal operator that functions explicitly or implicitly as its main operator.  ORM 2 distinguishes between positive, negative, and default verbalizations of constraints.  In positive verbalizations, an alethic modality of necessity is often assumed (if no modality is explicitly specified), but may be explicitly prepended.  For example, the static constraint

Each Person was born in at most one Country.

may be explicitly verbalized with an alethic modality thus:

It is necessary that each Person was born in at most one Country.

We interpret this in terms of possible world semantics, as introduced by Saul Kripke and other logicians in the 1950s.  A proposition is necessarily true if and only if it is true in all possible worlds.  With respect to a static constraint declared for a given business domain, a possible world corresponds to a state of the fact model that might exist at some point in time.  The above constraint means that for each state of the fact model, each instance in the population of Person is born in at most one Country.

A proposition is possible if and only if it is true in at least one possible world.  Impossible propositions are true in no possible world (i.e., false in all possible worlds).  In ORM, the above constraint may be reformulated as the following negative verbalization:

It is impossible that the same Person was born in more than one Country.

In practice, both positive and negative verbalizations are useful for validating constraints with domain experts, especially when illustrated with sample populations that provide satisfying examples or counter-examples respectively.

Many business rules are deontic rather than alethic in nature.  To avoid confusion, when declaring a deontic rule, the deontic modality should always be explicitly included.  In ORM 2, positive verbalizations of deontic rules typically begin with the phrase "It is obligatory that", and negative verbalizations of deontic rules typically begin with the phrase "It is forbidden that".  We now illustrate this approach with examples.

Verbalizing Deontic Uniqueness and Mandatory Rules

Previous articles described how to verbalize alethic uniqueness and mandatory constraints.  In this section we consider deontic versions of such constraints.  Consider the following positive verbalizations of static, deontic rules.

It is obligatory that each Person is a husband of at most one Person.

It is obligatory that each Person is a citizen of some Country.

The first rule is a deontic uniqueness constraint, and the second rule is a deontic mandatory constraint.  Each rule indicates a condition that ought to be satisfied, while recognizing that the condition might not be satisfied.  Including the obligation operator makes the rule much weaker than a necessity claim.  The rules allow that there could be some states of the fact model where a person is a husband of more than one wife (excluding same-sex unions from instances of the husband relationship), and some states where the person is citizen of no country.  For such cases, it is important to know the facts indicating that a person has multiple wives or is a non-citizen.  Rather than reject such possibilities, we allow them and then typically perform an action that is designed to minimize the chance of such a situation arising again (e.g., send a message to inform legal authorities about the situation).  These deontic rules may be reformulated as the following negative verbalizations: 

It is forbidden that the same Person is a husband of more than one Person.

It is forbidden that any Person is a citizen of no Country.

Figure 1  Screenshot from NORMA, showing positive verbalization of some constraints

Figure 1 shows a screenshot from NORMA (Neumont ORM Architect), illustrating positive verbalization of some alethic and deontic constraints in ORM 2.  Object types (e.g., Person, Country) are depicted as named, soft rectangles.  A logical predicate is depicted as a named sequence of role boxes, each connected by a line segment to the object type whose instances may play that role.  The combination of a predicate and its object types is a fact type -- the only data structure in ORM.

A bar spanning one or more roles depicts a uniqueness constraint over those roles (e.g., Each Person was born in at most one Country).  A constraint over multiple roles applies to the combination of those roles (e.g., the citizenship fact type is many:many).  A small "o" (for "obligatory") at the end of a uniqueness bar indicates the constraint is deontic (e.g., It is obligatory that each Person1 is a husband of at most one Person2).  Subscripts distinguish object variables of the same type.  A solid dot on a role indicates a mandatory constraint (e.g., Each Person was born in some Country).  If the dot is open, the constraint is deontic (e.g., It is obligatory that each Person is a citizen of some Country).  Deontic constraints are displayed in blue rather than the violet used for alethic constraints.

Figure 2 displays a screenshot from NORMA, illustrating negative verbalization of a deontic uniqueness constraint spanning the first two roles of the ternary fact type:  Room at HourSlot was booked for Course.  The constraint verbalization (It is forbidden that the same Room at the same HourSlot is booked for more than one Course) uses the deontic F (~P) operator.  All verbalizations in NORMA are performed automatically via XSLT transforms, and hence may be readily adapted for different native languages.  In practice, most business rules include only one modal operator, where this is the main operator of the whole rule expression.  For these cases, we simply tag the constraint as being of the modality corresponding to its main operator, without committing to any particular modal logic.

Figure 2  NORMA screenshot illustrating negative verbalization of a deontic constraint

The only impact of tagging a rule as a necessity or obligation is on rule enforcement.  Enforcement of a necessity rule should never allow the rule to be violated.  Enforcement of an obligation rule should allow states that do not satisfy the rule condition, and take some remedial action (e.g., generate a message when an update violates the rule).  A business person ought to be able to specify a deontic rule first at a high level, without committing at that time to the precise action to be taken if the condition is not satisfied; the action still needs to be specified later in refining the rule to make it fully operational.

If a role has both deontic uniqueness and deontic mandatory constraints, these two constraints may be captured in a single verbalization as shown below.  The first example caters for the case where a predicate reading starts at the constrained role, and the second example caters for the case where a predicate reading from the other role only exists.

It is obligatory that each immigrant has exactly one Passport.

For each immigrant, it is obligatory that exactly one Passport belongs to that immigrant.

Verbalizing Other Deontic Rules

Previous articles discussed verbalization of several other kinds of constraints, including value, subset, exclusion, equality, inclusive-or, exclusive-or, frequency, subtyping, and various ring constraints.  This section illustrates deontic versions of some these constraints.

Deontic, inclusive-or constraints:

It is obligatory that each Vehicle is purchased or is rented.

It is obligatory that each Vehicle was purchased on some Date or was rented on some Date.

It is obligatory that each Vehicle was purchased from some Branch of some AutoRetailer or is rented.

Deontic value constraints:

The permitted values of Grade(letter) are 'A' to 'F'.

The permitted values of PassScore are at least 50.

The permitted values of LuggageMass(kg) are at least 0 and at most 150.

The permitted values of AboveAverageIQ(nr) are above 100.

The permitted values of NonZeroTemperature are below 0, above 0.

Deontic subset constraints:

It is obligatory that each Patient who is cured pays for the treatment.

It is obligatory that each Person who drives some Car has some DriverLicense.

For each Person, it is obligatory that

if that Person drives some Car

then that Person has some DriverLicense.

It is obligatory that if some Person migrated to some Country on some Date

then that Person had an entry visa for that Country on that Date.

Irreflexive ring constraints:

No Person is a parent of the same Person.

It is obligatory that no Person reviews a paper by the same Person.

It is forbidden that some Person reviews a paper by the same Person.

It is impossible that some Part contains the same Part in some Quantity.

It is obligatory that no Person gave some Rating to the same Person.

It is forbidden that some Person gave some Rating to the same Person.

It is impossible that some Person1 introduced the same Person to some Person2.

Other examples of deontic ring constraints are discussed in a previous article.^[12]  That should be enough to illustrate the main verbalization patterns.  Detailed specifications of all the constraint verbalization patterns (alethic and deontic) implemented by NORMA will be made available in technical reports on the NORMA website.^[20]

References

[1]  T.A. Halpin.  "Verbalizing Business Rules (Part 1)," Business Rules Journal, Vol. 4, No. 4 (April 2003).  URL: http://www.BRCommunity.com/a2003/b138.html  

[2]  T.A. Halpin.  "Verbalizing Business Rules (Part 2)," Business Rules Journal, Vol. 4, No. 6 (June 2003).  URL: http://www.BRCommunity.com/a2003/b152.html  

[3]  T.A. Halpin.  "Verbalizing Business Rules (Part 3)," Business Rules Journal, Vol. 4, No. 8 (August 2003).  URL: http://www.BRCommunity.com/a2003/b163.html  

[4]  T.A. Halpin.  "Verbalizing Business Rules (Part 4)," Business Rules Journal, Vol. 4, No. 10 (October 2003).  URL: http://www.BRCommunity.com/a2003/b172.html    

[5]  T.A. Halpin.  "Verbalizing Business Rules (Part 5)," Business Rules Journal, Vol. 5, No. 2 (February 2004).  URL: http://www.BRCommunity.com/a2004/b179.html  

[6]  T.A. Halpin.  "Verbalizing Business Rules (Part 6)," Business Rules Journal, Vol. 5, No. 4 (April 2004).  URL: http://www.BRCommunity.com/a2004/b183.html  

[7]  T.A. Halpin.  "Verbalizing Business Rules (Part 7)," Business Rules Journal, Vol. 5, No. 7 (July 2004).  URL: http://www.BRCommunity.com/a2004/b198.html  

[8]  T.A. Halpin.  "Verbalizing Business Rules (Part 8)," Business Rules Journal, Vol. 5, No. 9 (September 2004).  URL: http://www.BRCommunity.com/a2004/b205.html  

[9]  T.A. Halpin.  "Verbalizing Business Rules (Part 9)," Business Rules Journal, Vol. 5, No. 12 (December 2004).  URL: http://www.BRCommunity.com/a2004/b215.html  

[10]  T.A. Halpin.  "Verbalizing Business Rules (Part 10)," Business Rules Journal, Vol. 6, No. 4 (April 2005).  URL: http://www.BRCommunity.com/a2005/b229.html  

[11]  T.A. Halpin.  "Verbalizing Business Rules (Part 11)," Business Rules Journal, Vol. 6, No. 6 (June 2005).  URL: http://www.BRCommunity.com/a2005/b238.html  

[12]  T.A. Halpin.  "Verbalizing Business Rules (Part 12)," Business Rules Journal, Vol. 6, No. 10 (October 2005).  URL: http://www.BRCommunity.com/a2005/b252.html  

[13]  T.A. Halpin.  "Verbalizing Business Rules (Part 13)," Business Rules Journal, Vol. 6, No. 12 (December 2005).  URL: http://www.BRCommunity.com/a2005/b261.html  

[14]  T.A. Halpin, "Verbalizing Business Rules (Part 14)," Business Rules Journal, Vol. 7, No. 4 (April 2006), URL:  http://www.BRCommunity.com/a2006/b283.html  

[15]  T.A. Halpin, "Verbalizing Business Rules (Part 15)," Business Rules Journal, Vol. 7, No. 6 (June 2006), URL:  http://www.BRCommunity.com/a2006/b294.html  

[16]  P. P. Chen.  "The Entity-Relationship Model -- Towards a Unified View of Data," ACM Transactions on Database Systems, Vol. 1, No. 1 (1976), pp. 9-36.  

[17]  T.A. Halpin.  Information Modeling and Relational Databases.  Morgan Kaufmann: San Francisco (2001).  

[18]  T.A. Halpin.  "ORM 2," On the Move to Meaningful Internet Systems 2005: OTM 2005 Workshops.  eds. R. Meersman, Z. Tari, P. Herrero, et al.  Cyprus:  Springer LNCS 3762 (2005), pp. 676-687.  

[19]  T.A. Halpin.  "Business Rule Modality," Proc. CAiSE'06 Workshops.  eds. T. Latour & M. Petit.  Namur University Press (2006), pp. 383-394.  URL: http://www.orm.net/pdf/RuleModality.pdf  

[20]  NORMA website:  http://sourceforge.net/projects/orm  

[21]  Object Management Group.  UML 2.0 Infrastructure.  Object Management Group (2003).  URL:  http://www.omg.org/uml  

[22]  Object Management Group.  Semantics of Business Vocabulary and Business Rules (SBVR), Interim Specification (September 2006).  Available as dtc/06-08-05 at http://www.omg.org  

# # #