While models are statements about the categories of things that may exist in business domains, rules are statements about business facts, i.e instances of those categories. Yet, given that requirements usually don’t come with categories fully and consistently defined upfront, the way rules are expressed can only be settled through requirements analysis.
As a consequence, from requirements lumps to well-formed expressions of business logic, rules will get through some metamorphosis. That raises two questions: is it possible to map those transformations, and, if it’s the case, what kind of criteria should govern the making of the rules.
The footprint of a rule is made of the categories of facts to be considered (aka rule domain), and categories of facts possibly affected (aka rule co-domain).
As far as systems are concerned, the first thing to do is to distinguish between actual contexts and symbolic representations. A naive understanding would assume rules to belong to either actual or symbolic realms. Given that the objective of modeling is to decide how the former should be represented by the latter, the opposite is to be expected and dealt with using three categories of rules, one for each realm and the third set across the divide:
- Rules targeting actual contexts. They can be checked through sensors or applied by actuators. Since rules enforcement cannot be guaranteed on non symbolic artifacts, some rules will have to monitor infringements and proscribed configurations. Example: “Cars should be checked on return from each rental, and on transfer between branches.”
- Rules targeting symbolic representations. Their enforcement is supposedly under the full control of system components. Example: “A car with accumulated mileage greater than 5000 since its last service must be scheduled for service.”
- Rules defining how changes in actual contexts should impact symbolic representations: what is to be considered, where it should be observed, when it should be recorded, how it should be processed, who is to be authorized. Example: ” Customers’ requests at branches for cars of particular models should be consolidated every day.”
That classification should be applied as soon as possible because the third category will determine the impact of requirements on architecture capabilities.
Syntax and Semantics
Identifying footprints from requirements may be complex but the outcome isn’t contingent on modeling options. That’s not the case for syntactic constructs used to define observed and targeted facts.
Rules can be built along four basic constructs, depending on the way domains (categories of instances to be valued) and co-domains (categories of instances possibly affected) are considered:
- Partitions are expressions used to classify facts of a given category.
- Constraints (backward rules) are conditions to be checked on facts: [domain].
- Pull rules (static forward) are expressions used to modify facts: co-domain = [domain].
- Push rules (dynamic forward) are expressions used to trigger the modification of facts: [domain] > co-domain.
Domains and co-domains are defined by rule semantics; they can be homogeneous (single category) or heterogeneous (joint categories).
Homogeneous rules target single categories and are therefore easier to be anchored and documented in models:
- Physical objects: monitoring, computation rules, events triggering rules.
- Symbolic objects: integrity constraints, derivation rules, inference or cascading updates.
- Activities: local conditions on data, processing of data flows, sequencing of operations.
- Processes: local conditions on state values, derived states, stimulus or triggering of transitions.
Since homogeneous expressions are the rules’ building blocs, factoring them out should be the first step in the process of rules formulation.
In principle, rules targeting different categories of facts are nothing more than well-formed expressions combining homogeneous ones. In practice, because they mix different kinds of artifacts, the way they are built is bound to significantly bear on architecture capabilities.
Before combining simple expressions into complex ones, the first step is to circumscribe their scope depending on the anchor used to identify facts that have to be considered (domain) or possibly modified (co-domain):
- Features: domain and co-domain are limited to attributes or operations.
- Object footprint: domain and co-domain are set within the limit of a uniquely identified instance (#), including composites and aggregates.
- Connections: domain and co-domain are set by the connections between instances identified independently.
- Collections: domain and co-domain are set between sets of instances and individuals ones, including subsets defined by partitions.
- Containers: domain and co-domain are set for whole systems.
Those constructs are purely syntactic and can be used indifferently for all statements, actual or symbolic:
While minimizing the scope of simple (homogeneous) rules is arguably a straightforward routine, alternative options may have to be considered for the transformation of joint (heterogeneous) statements, e.g when rules about functional dependencies may be attached either to (1) persistent representation of objects and associations or, (2) business applications.
Heterogeneous (joint) Footprints
Footprints set across different categories will usually make room for alternative modeling options. As those options will determine the way rules will be executed, they will bear differently on architecture capabilities. Hence the need to organize joint rules depending on their impact.
A preliminary approach would be to try to regroup rules along requirements taxonomy:
- Business requirements: rules set at enterprise level that can be managed independently of the architecture.
- Functionalities: rules set at system level whose support depends on architecture capabilities.
- Quality of service: rules set at system level whose support depends on functional and technical architectures.
- Operational constraints: rules set at platform level whose support depends on technical capabilities.
While that classification may work fine for homogeneous rules (a), it may fall short for mixed ones, functional (b) or not (c). For instance:
- “Gold Customers with requests for cars of particular models should be given an immediate answer.”
- “Technical problems affecting security on checked cars must be notified immediately.”
Given that such rules interweave business, functional, and non functional requirements, their formulation should reflect how priorities are to be sorted out between different levels of requirements.
On a broader perspective, if rule transformation is to be carried out, there will be more than syntax and semantics to consider because almost every requirement can be expressed as a rule, often with alternative options. As a consequence, the modeling policies (aka pragmatic) governing the making of rules should be set explicitly.
Pragmatic: Sorting out mixed rules
Taking into account that functional requirements describe how systems are meant to support business processes, some rules are bound to mix functional and business concerns. When that’s the case, preferences will have to be set with regard to:
- Events vs Data (a): should system behavior be driven by changes in business context (as signaled by events from users, devices, or other systems), or by changes in symbolic representations (a).
- Activities vs Data: should system behavior be governed by planned activities, or by the states of business objects (b).
- Activities vs Events: should system behavior be governed by planned activities, or driven by changes in business context (c).
The same questions arise for rules mixing functional requirements, quality of service, and operational constraints (d), e.g:
- How to apportion response time constraints between endpoints, communication architecture, and applications.
- How to apportion reliability constraints between application software and resources at location .
- How to apportion confidentiality constraints between entry points, communication architecture, and locations.
How those questions are to be answered, in particular at what level, should be decided within a comprehensive and consistent enterprise architecture.
Decision Points, Architecture, and the Making of Rules
Beyond requirements specifics, rules should befit organizational and architectural options set at enterprise level. That should be the aim of requirements analysis and rules transformation.
While rules description combines syntactic constructs (constraints, computation, triggers, etc) and semantics (objects, events, activities, role, etc), their transformation is to be governed by pragmatic, more precisely the modeling options reflecting the architecture framework. For instance, aiming at a Model/View/Controller framework, rules would be organized along three layers:
- Model: constraints, derivations, inferences and cascading updates that can be applied on shared and persistent instances independently of applications.
- Views: constraints and processing rules that can be applied on non shared and transient instances executed at entry points.
- Controller: processing and control rules that can be applied on shared and transient instances independently of entry points.
Obviously, pragmatic can go further than simple MVC layers and take into account application life-cycle (e.g along MDA’s CIMs, PIMs, and PSMs), and collaboration mechanisms (e.g activity- vs event-driven). For that purpose the making of rules should follow three guidelines:
- Partitions and constraints should be used to anchor rules to decision points clearly set with regard to architecture (e.g MVC) and model layers (e.g MDA). For instance: the decision point for the type of reservation belongs to computation Independent business logic, and classifications of customers and cars belong to computation Independent business domains.
- Backward constructs should be used for rules pertaining to business logic independently of processes execution. For instance: how to process a reservation (a).
- Forward constructs should be used to compare alternative execution models. For instance: activity driven through control flows (b), or event-driven through event notification (c).
Not by chance, applying those guidelines will neatly map rules to standard diagrams: class diagrams (partitions and integrity constraints), use cases (extension points), activity diagrams (backward rules for branches and functions), business processes (backward rules for gateways) and state charts (forward rules for transitions).
- Enterprise architecture and Separation of Concerns
- Service Oriented Architectures
- Rules Patterns
- SBVR Case Study