ساختاربندی تعاملات قوانین کسب و کار

Motivation for arranging business rules is not confined to efficient processing of rules, as in case of traditional rule bases, but to aid in decision making as well. Efficient processing and ease of decision making, therefore, are the twin objectives behind arranging and grouping of business rules as envisaged by business rules approach to system development. This paper strives to make a beginning to realize these objectives. Six types of rule groupings have been proposed in this paper. Examples from industrial domain have been taken to elucidate the rule groupings.

Business rules approach to system development may not be a paradigm shift but it definitely undertakes a noticeable departure from the way information systems were developed traditionally. In traditional information system development writing software meant writing programs and generating code. Everything was put into code and a software system meant a body of code. In such a scenario a system was accessible and visible thorough its code only and in no other way. This approach overlooked the fact that a business decision-maker may not and need not be a software professional. Business rules could pop up almost at every business decision making process. Which customer should be treated as privileged customer, on what basis an insurance policy should be renewed, how to reimburse an insurance claim are some of the examples where business rules are needed to take decision. In the absence of any overt articulation of business rules, a decision-maker has to look into the code to know them. You know there is a problem if you have to ‘look at the code’, for there is no explicit statement about what business rules are [18]. If business rules are imbedded into the code, then the only way to get them out is by mining business rules through a kind of reverse engineering activity on software [16]. Mining business rules through reverse engineering has two problems. One, business rules might be scattered throughout the entire code and it may not be effective, in terms of cost and effort, to undertake this exercise. Two, reverse engineering for business rules may be based on the assumption that code was developed with business rules in mind. This assumption may not be tenable. Whether or not business rules may be viewed as expressing functional as well non-functional requirements could be debatable and much depends upon how one defines business rules. Requirements captured by business rules are, in principle, no different from other kind of requirements. However, business rules are characterized by their strategic importance to the business and deserve special attention [18]. If business rules are intended to facilitate business decision making, then there must be mechanisms to make rules accessible to business decision-makers. This further requires that business rules are expressed in terms of an enterprise level model and not in terms of programs and databases [5] and [13]. Business rules have received a lot of attention in the trade press and other literature as holding answers to many information technology problems. Sandifer and Halle [19] have even suggested that one can gather a list of English language statements describing the business rules informally as a first step towards taking a business rules approach. Other approaches are more structured, relying on the syntax of E–R diagram. Roland [17] has proposed a much more elaborate diagrammatic syntax. Still others propose a conceptual model approach for describing an enterprise with a notation for specifying rules that further specify the requirement on the enterprise [5] and [13]. Martin and Odell [14] limit the enterprise model to data and object rules. Some researchers treat non-functional requirements as goals that have to be met through a decision making process in which change is expected. Lamsveerde et al. [10] propose a goal directed requirements elaboration methodology which attempts to cope with the “deidelaization of unachievable goals” and also models assumptions attached to goals. Fickas and Feather [9] discuss requirement monitoring to instrument the running system to determine whether and to what extent requirements are being met by the system. Eventual aim of taking business rules approach to information system development is to automate the business processing through business rules. It is, in other words, aiming at compilable and executable specifications [7]. Not much literature is available with respect to arranging business rules with the purpose of ease of decision making and efficiency of rules processing. Rosca et al. [18] discuss three levels of business rules. Criteria level, argument level and assumption level and describe them as follows: The rules at criteria level are the highest level rules and they are the most general types of rules. These rules relate to high level decision-making and code criteria for decisions in IF and THEN form. Rules at argument level express the heuristics used in deciding how well an alternative satisfies the criterion when several arguments are presented for or against a solution. Rules at assumption level are the most detailed of rules where business objectives find their implementation level meaning. This classification of rules by Rosca et al. [18] is very helpful in business rules implementation, however, it does not tell how to model these rules and how to establish a relationship between the rules of the same class or type for the purpose of ease of decision making and for the efficient processing of rules. This paper will take up these issues in some detail. Anantaram [2] has studied formation of sets of rules from the possible interactions that can occur between rules such that these interactions are meaningful in the specified domain. In this study the following types of interactions between rules have been discussed: Rule chains, rules assertions and rule groups. In rule chain, this study considers intersection of “rule-attributes” in the antecedent of one rule with “rule-attributes” in the consequent of another rule. A rule chain is said to be created when the antecedent of a rule (say, Rule 1) refers to the consequent of another rule (say Rule 2). In rule assertions, the study examines intersection of “rule-attributes” in the consequents (or the then-part) of the rules. Rule groups in this study are defined based on some commonality in the condition (or antecedent). A similar approach for partitioning rulebase was taken by Brown and Pomykalski [4], where a rule base is partitioned into a set of chains (the horizontal partition) and a set of groups (vertical partitions). 1.1. Rule taxonomy versus rule grouping It is pertinent to differentiate business rules taxonomy from business rules grouping. While taxonomy classifies business rules into certain fundamental types, grouping is done based on interrelationship and interaction between rules. However, in some cases grouping has been done in this paper based on higher-level associations where business rules may not be related to each other but they come from the same source or they implement the same business policy. Business rules literature gives the following classification for business rules: (i) Definition business rules – rules that define a business term; (ii) fact business rules that assert a business fact by connecting a business object with another object or by connecting a business object with its attribute (s); (iii) constraint business rules that constrain the behavior of the system based on some condition and (iv) derivation business rules that derive new information from given information using induction, deduction or inference [8] and [20]. Strum [20] gives another class of business rules called requirement business rules which are expressed in terms of imperatives. 1.2. The motivation for grouping The motivation for grouping business rules is to organize rules in the rule base so that the user can study the interaction among rules and use this study in decision making as well as efficient processing of rules. Rules are not isolated from each other. They are related to some other rules. This relationship could be as simple as mere reference or could be as complex as causality. In the instance of change in one rule related rules are also affected. If related rules are grouped together impact of change in a given rule can be traced to affected rules in the rule base. Rules may also be attached to object model of a given business process. If the business process undergoes change, object model will also change accordingly and so will the set of rules attached to the object model. Object(s) may be added or deleted, some additional operations may be performed on the object(s). These changes will affect the set of rules attached to the objects. If the rules are grouped on the basis of their reference to objects, changes in the object could be tracked to the rule set attached to it and the rule set could be changed subsequently. Organization of rules also helps in combining the individual pieces of knowledge embedded in the rules into comprehensive knowledge of the rule base. If the rules are not organized, impact of change in the business model on business rules cannot be traced, redundant rules will be created, rules cannot be processed efficiently, and decision making with rules will not be expedient and new rules will not be identified. We produce an example to illustrate how grouping rules facilitates identifying new rules. Let us take the following rule for insurance policy renewal business process. R1• Renewal notice is sent 30 days prior to expiry date of the insurance policy. However, we need to know the expiry date of the policy in order to execute the above rule. So we must have a rule which specifies this. We can have the following rule to do this. R2• Each policy must have an expiry date. Let us further consider following rules in the same context. R3• Policyholder may or may not send an acceptance notice in response to renewal notice. R4• Policy must be renewed with the acceptance of the insured whenever applicable. How long would an insurer wait to receive an acceptance notice from the insured? The insurer must have a rule to address this problem as given in the following example. R5• IF acceptance of renewal notice from insured is not received within 14 days THEN send reminder. R6• IF within 21 days of sending reminder insured does not send acceptance notice for renewal THEN the policy will be considered ‘expired’ AND it will be made null and void. All the rules above are related with each other in the sense they are ‘prerequisite’ to each other in some order and therefore may be grouped together in that order as given in Box 0. Such a grouping helps in arranging rules in some order as well as discovering the missing rules. Box 0. An example of grouping rules along prerequisite relationship to discover missing rules R2. Each policy must have an expiry date. R1. Renewal notice is sent 30 days prior to expiry date of the insurance policy. R4. Policy must be renewed with the acceptance of the insured whenever applicable. R3. Policyholder may or may not send acceptance notice in response to renewal notice. R5. IF acceptance of renewal notice from insured is not received within 14 days THEN send reminder. R6. IF within 21 days of sending reminder insured does not send acceptance notice for renewal THEN the policy will be considered ‘expired’ AND it will be made null and void. The insurance organization may add more rules to deal with the decision of renewal of insurance policy as per the business policies of the organization, for the primary purpose of business rules is to implement business policies of the organizations.

This work is a part of business rules methodology being developed by the authors. This paper has reported the result of study done on some mechanisms for looking at business rules interactions and forming business rule groups based on them with twin purpose of efficiency of processing business rules and ease of decision making. In all, six types of business rules groupings have been proposed. Rule groups based on rules’ reference to definitions, rules’ reference to business objects, rules’ reference to facts, rule groups based on criteria, operations and assumptions and rules groups based on a given business policy. Grouping of business rules based on criteria, operational and assumption level is not unique. It is but one of the ways of forming rule sets for the aid of decision-maker. A decision-maker has the prerogative to group business rules as per his/her business needs. Eventually, what purpose does the grouping of business rules serve is the most important basis for grouping of business rules. The sixth set is based on logical relationship among rules. It contains interaction among the business rules in view of relations such as prerequisite, impact and inference. This study elucidated the impact of business rules grouping in the framework of semantic web. 3.1. Scope for further study As stated earlier, this work is part of business rules methodology under development where in the motive is to look at the issue of business rules comprehensively without getting into rigorous detail of each and every aspect of it. Though the proposed solution takes real life examples, it requires further experimentation to form a sound basis for formulating business rule groups. There is a need for looking at this problem comprehensively and to build a rule base, taking into account the rule groupings and test it with empirical results. Business rules grouping could be used for improving the business process. What impact does change in business process have on business rules and vice versa is a subject for further study. Results obtained in this study could be helpful in this regard. This study could be further extended to define the rule sets formally and working out a framework for studying the impact of rule sets in semantic web framework.