Rules

Objective

Rules can be found everywhere, at every time along application life-cycle. Moreover, as they appear at the very beginning, in the midst of unstructured objects and activities, their expression can be seen as a dual undertaking of requirements capture and analysis.

Hence, the need to clarify their nature: scope, semantics, formats, and modus operandi.

Scope

From a logical perspective, requirements capture should distinguish between three categories of rules:

• Deontic rules are meant to describe necessary conditions. Used for system modeling, that means conditions to be verified by business contexts independently of symbolic representations. Those must be enforced if system objects are to represent business contexts.
• Alethic (aka modal) rules describe possible, necessary or contingent conditions. Used for system modeling, those conditions may be directly applied to symbolic representations.
• Temporal rules describe conditions whose truth value is time-related. Those rules cannot be used for system modeling without taking into account the way symbolic representations take heed of external events.

As it happens, and not by chance, the distinction between deontic and alethic rules coincides with the one between business and functional requirements, the former for rules defined by the environment, the latter for rules defined by the enterprise.

Whereas both deontic and alethic rules are to be supported by systems, loci will differ: system boundaries for deontic rules (coupling between environment and systems), system components for alethic ones (continuity and consistency of symbolic representations). Given the architectural consequences, rules should be defined and organized depending on triggering (actual or symbolic) and scope (environment or enterprise):

• Actual deontic rules are triggered by actual external events that must be processed synchronously.
• Symbolic deontic rules are triggered by external events that may be processed asynchronously.
• Actual alethic rules are triggered by business processes and must be processed synchronously.
• Symbolic alethic rules are triggered by business processes and can be processed asynchronously.

That provides a sound framework for requirements analysis, with the classification of rules congruent with problem spaces (business requirements vs functional ones) and architecture layers. That can be achieved by mapping enterprise architectures to ontologies.

Semantics

Rules’ ubiquity and diversity often present a baffling challenge for business analysis tasked with sorting out mixed semantics: descriptive (integrity, business logic, prescriptive (regulations), and predictive (business intelligence).

As a consequence of the generalization of digital environments and the blurring of traditional boundaries, systems have to process heterogeneous flows of data, information, and knowledge. As a consequence, requirements may come with rules reflecting that heterogeneity.

Formats

The first thing to do is to identify their footprint, for conditions, consequences or both:

• Rules made only of conditions are used to enforce the consistency of persistent representations (integrity constraints) or activity execution (preconditions).
• Rules made only of consequences are functions used to compute the value of features, trigger actions, or maintain the consistency of persistent representations (post-conditions).
• Rules made of both conditions and consequences are used to set the path of objects processing or processes execution.

  

Since rules can apply simultaneously to actual and symbolic objects and activities, they may have a significant impact on architectural constraints. Yet, on the other hand, they are obviously the most pliable and volatile components of business requirements and therefore should be easily modifiable; in other words, set within a layered approach of traceability, rules management should bypass platform independent models and directly target platform specific ones.

If system architects were to decide, symbolic and actual rules should be set independently. Unfortunately that’s not always the case and, in order to manage this conundrum, logic operators should be used to decompose rules with heterogeneous footprints into homogeneous elements.

First, it is necessary to separate consequences that may affect actual objects or processes from symbolic ones, whose impact can be limited to symbolic representations.

Then, the scope of conditions and consequences should be layered depending on their footprint on architectures:

• Leafs will contain expressions targeting single features whose processing can be performed locally.
• Then one will find expressions that can be evaluated (or executed) locally by a single object or activity.
• Conditions targeting collections should be set one level up.
• Then one will find combined expressions whose footprint stand across domains, but remain within a single location.
• Finally the root will contain expressions with their scope distributed across different locations.

That should be the rationale behind the definition of rule patterns.

Modus Operandi

As far as architecture is concerned, local rules can be ignored since they can be managed by persistence or execution units without calling on system resources. The main challenge is therefore to classify rules with regard to their modus operandi:

• Footprint: Rules targeting persistence units, compared to from those targeting execution units.
• Execution: Backward rules activated from a known persistence or execution unit, compared to forward ones whose consequences cannot be known upfront.

From an architectural perspective, the modus operandi is to be the critical factor to be considered, hence, the benefit of disentangling requirements in order to get homogeneous clauses.

Example

Access to scythed chariots can be qualified at different levels, each with specific architectural consequences.

• Constraint on persistent representations: reservations of scythed chariots are only for officers.

• Constraint on processing: Before checking out a scythed chariot one must check the military status of the driver.

• Trigger on process: when driver’s military status doesn’t authorize scythed chariots, remove the scythes.

• Trigger on update: When a returned chariot is broken  his status is to be reset to “unfit”.

Further Reading

• Rules Patterns
• Actual Rules
• Symbolic Rules
• Derivations
• Making the Rules