ISO/IEC 15944-4 The constraint component of an OeBTO – 20071101

Business Rules and Open-edi Constraints

Business rules specifying computational procedures, approved sequences of actions, valid inferences, and effective control monitoring govern the day-to-day operations of business enterprises. A useful definition of a “business rule” from Eriksson and Penker is:

… a statement that can control or affect the execution of a business process as well as the structure of the resources in a business. The statement specifies a condition that must be upheld, or a condition that controls which activity should follow next. It can express a business goal, specify the way a process should execute, detail the conditions of a relationship, or constrain the behavior of a resource.

In the database world somewhat synonymously, “constraints” are defined as rules governing the integrity of data that prevent a database from moving from one representation state to another without proper validation, and in the most simple ontological case, their function is exactly congruous with the business rules definition given above. Database integrity constraints are also commonly referred to as assertions.

In ISO/IEC 15944-1, a constraint is defined as “a rule, explicitly stated, that prescribes, limits, governs, or specifies any aspect of a business transaction.” That same standard differentiates those constraints that are self imposed by the trading parties (internal) from those constraints created by law, regulation, orders, treaties, conventions, or similar instruments (external):

  1. internal constraint: a constraint which forms part of the commitment(s) mutually agreed to among the parties to a business transaction
  2. external constraint: a constraint which takes precedence over internal constraints in a business transaction,e., is external to those agreed upon by the parties to a business transaction.

Open-edi further divides the category of external constraints into:

  1. those that are common and horizontal in nature as introduced by the additional presence in a business transaction of a “regulator” as a third subtype of Person representing “public administration“, and
  2. those that are more sectorial in nature (involving standard rules, both across many sectors and across just one sector). Open-edi differentiates these classes of constraints in order to provide summaries of complex bundles of rules for scenario registration. For example, the simplest constraint bundle for a scenario could aggregate only internal constraints; the next most complex could add horizontal external constraints, etc.

In the OeBTO, constraints encapsulating business rules constitute the third major representation component. The first component was the declarative specification of domain classes and associations in Clause 5, while the second component was the procedural aspects associated with business transaction state machines and activity graphs as explained in Clause 6.

OeBTO Constraint Examples

Constraints may be expressed informally in natural language, such as the following accounting rule for separation of duties as applied to the class diagram of Figure 6:

“the Person who fills the participation role in an Economic Event that involves a certain Economic Resource should not be the same Person who has a custody relationship with that Economic Resource”

The need for this constraint to a business transaction could be derived for example from a sectorial application (an OeBTO external constraint) of the 2002 USA Sarbanes-Oxley internal control legislation.

Constraints may also be expressed more formally with the Object Constraint Language (OCL) of the UML. For example, a state sales tax rule for Michigan (another sectorial external constraint) on merchandise orders (a subtype of Economic Contract) could be specified as 6% of the gross amount of the order:

context Order inv michiganSalesTaxCalculation  salesTax = grossAmount × .06

Such a constraint could be placed in curly brackets on a UML class diagram next to the class definition for order (for example, a more specific form of Figure 16), and it then becomes an invariant (inv) or a condition that must be true for all objects of that class.

According to both Odell and Eriksson and Penker, constraints may be of two general behavioral kinds:

  1. Those that define how knowledge in one form may be inferred or derived from another form. Examples of this constraint category might be the Michigan sales tax calculation shown above. Another example might be a constraint that designates a scheduled shipment as “hazardous” if it exceeds a designated weight threshold of goods (economic resources) typed as “dangerous if unpackaged” shown in an inheritance taxonomy that would give domain level expansion to the three levels initially shown in Figure 4.
  2. Those that “constrain either the possible structure or the behavior of objects or processes, that is, the way objects are related to each other or the way objects or process state changes may occur.” An especially prominent illustration for the OeBTO of this class of constraints are rules that define preconditions and post-conditions for the types of state changes described in Clause 6. For example in Figure 26, the state machine diagram makes it clear that for Economic Resource Type to achieve its “proposed” state, it has a pre-condition of being in state “identified” and a post-condition of state “specified” and that these transitions are effected by the business events shown. These same types of rules can be specified as constraints in OCL and portrayed on UML class diagrams.

Both derivation business rules and constraint business rules are important to effective business operation in collaboration space, so their characterization in the Open-edi Business Transaction Ontology is an important third step in insuring interoperability and semantic integrity. To the extent that the declarative and procedural components of an ontology are specified correctly, the parties to a business transaction are given computable methods for ensuring compliance with both internal and external rules of business behavior.

7.3 Summary

There is certainly now a critical opportunity for developing coherence in worldwide standards for business level definitions of economic phenomena. Open-edi, especially in its prior work of ISO/IEC 15944-1, has standardized much of the technical and economic environment for economic exchanges, and the field of ontology provides an extended opportunity for unifying and coordinating that work. This part of ISO/IEC 15944 aims to provide that unity with an ontological analysis of the declarative, procedural, and constraint components of Open-edi. Certainly, the majority of the work in this document concentrates on the declarative components of the OeBTO – those data classes that model the fundamental categories of economic endeavors in collaboration space and the relationships that exist among those categories. This declarative emphasis is reasoned and deliberate. As noted by John Sowa, conceptual progress in a specialized domain is usually marked by an increasing percentage of the knowledge in that field being embedded in its declarative components. As ad hoc procedures and constraints become more structured and predictable, they lead naturally to better theoretical and conceptual structures.

In concert, the declarative, procedural, and constraint components of the Open-edi ontology provide a definitive specification that is formal, explicit, and conceptual. An ontological foundation is one of the key components of that coherence.

Previous: ISO/IEC 15944-4 The procedural component of an OeBTO – 20071101