Title: Rule warehouse system for knowledge sharing and business collaboration
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00100840/00001
 Material Information
Title: Rule warehouse system for knowledge sharing and business collaboration
Physical Description: Book
Language: English
Creator: Liu, Youzhong, 1971-
Publisher: University of Florida
Place of Publication: Gainesville Fla
Gainesville, Fla
Publication Date: 2001
Copyright Date: 2001
 Subjects
Subject: Rule-based programming   ( lcsh )
Electronic commerce -- Software   ( lcsh )
Electrical and Computer Engineering thesis, Ph. D   ( lcsh )
Dissertations, Academic -- Electrical and Computer Engineering -- UF   ( lcsh )
Genre: government publication (state, provincial, terriorial, dependent)   ( marcgt )
bibliography   ( marcgt )
theses   ( marcgt )
non-fiction   ( marcgt )
 Notes
Summary: ABSTRACT: In collaborative e-business, the business rules of different business partners need to be shared electronically and be used to solve business problems collaboratively. To achieve this, a neutral knowledge representation is needed to translate heterogeneous rules into the neutral representation so that: --Pair-wise translations between rule representations can be avoided --The collection of rules can be verified to identify inconsistencies, redundancies, and non-termination conditions. In this dissertation, we describe the design and implementation of a Rule Warehouse System (RWS), which allows heterogeneous business rules to be imported and transformed into the neutral knowledge representation, verified to eliminate rule anomalies, and exported for use by some existing rule systems to support collaborative e-business applications. An Active Object Model is used as the neutral knowledge representation for different types of rules commonly recognized in the literature, and several algorithms are developed and implemented for the detection of rule anomalies. The verification process first converts all types of rules into an event-and-action-oriented representation. An algorithm is then applied on the set of transformed rules to detect non-termination conditions. Next, the same set of rules is partitioned based on their associated events before applying algorithms on each partitioned subset to detect inconsistencies and redundancies. These algorithms take into consideration the side-effects of methods can be called in rules.
Summary: ABSTRACT (cont.): An important benefit of an RWS is to integrate the knowledge acquired from different sources to solve problems that cannot be solved by using the knowledge and the rule engine of an individual source. In this dissertation, we describe our work on the integration of a deductive rule engine with an event-and-action-oriented rule engine to demonstrate collaborative problem-solving by using both constraint-oriented and event-and-action-oriented rules.
Summary: KEYWORDS: rule verification, collaborative e-business, business rule, collaborative problem-solving, ECA rule
Thesis: Thesis (Ph. D.)--University of Florida, 2001.
Bibliography: Includes bibliographical references (p. 113-120).
System Details: System requirements: World Wide Web browser and PDF reader.
System Details: Mode of access: World Wide Web.
Statement of Responsibility: by Youzhong Liu.
General Note: Title from first page of PDF file.
General Note: Document formatted into pages; contains xi, 121 p.; also contains graphics.
General Note: Vita.
 Record Information
Bibliographic ID: UF00100840
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
Resource Identifier: oclc - 49261897
alephbibnum - 002765988
notis - ANP4027

Downloads

This item has the following downloads:

Youzhong_Liu_Dissertation ( PDF )


Full Text











RULE WAREHOUSE SYSTEM
FOR KNOWLEDGE SHARING AND BUSINESS COLLABORATION

















By

YOUZHONG LIU


A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA


2001




























Copyright 2001

by

Youzhong Liu

































To my dear parents and wife















ACKNOWLEDGMENTS

First and foremost, I would like to express my gratitude toward my advisor, Dr.

Stanley Y. W. Su, for giving me the opportunity to work with him in the Database

Systems Research and Development Center. His excellent advice and great guidance, and

fruitful discussions on many aspects of this dissertation are invaluable. My full

appreciation goes to Dr. Herman Lam, my co-advisor, for constantly providing me with

valuable comments and suggestions during my dissertation work. I also thank Dr.

Joachim Hammer, Dr. Sumi Helal, and Dr. Michael C. Nechyba for serving on my

supervisory committee and for taking the time to read and comment on my dissertation. I

also thank Dr. Antonio Arroyo for reading my dissertation proposal and attending my

proposal presentation.

I would also like to thank all the graduate students participating in the

implementation task of this research. They are Yuan Shi, Fahong Yu, Haifei Li, and

Seokwon Yang. I also thank Ruiqiang Zhuang and Yan Huang for their encouragement. I

also thank Steve Hardy and Jeffery Yu for their help in reading my dissertation and

correcting grammar errors. I extend special thank to Ms. Sharon Grant for her constant

willingness to help.

Finally, I would like to thank my wife, Weiying Zhao; my mother, Youfang

Liang; my father, Zhiwei Liu; and my sister, Lingqun Liu for their encouragement and

care during my graduate work.
















TABLE OF CONTENTS

page

A C K N O W L E D G M E N T S ................................................................................................. iv

LIST OF FIGURES ............................... ......... ............................ viii

CHAPTERS

1 IN TR O D U C TIO N ................. ................................ ........ ........ .................

2 SURVEY OF RELATED WORK ....................................................... ...............

2 .1 R ule System s..................................... .............. ...... 5
2.2 Business Rule M anagem ent........... ............................ ............... .............. 8
2.2.1 Business Rule D efinitions ...................................................... ........ .. .... 9
2.2.2 Business Rule M anagem ent .......................... .......................... .............. 10
2 .3 K n ow led g e S h arin g ............................ .......................... ................................... 1 1
2.4 Rule V erification. ......................... ...... ........... 14
2.4.1 L ogic R ule V erification ............................................ ........... .............. 14
2.4.2 Rule Verification in Active Databases........... .......... ..................... 15
2.5 Collaborative Problem Solving................................................................. .. 17

3 RULE WAREHOUSE SYSTEM .......................................................... ........... 18

3.1 Internet-based Knowledge Network .......................................... ............. 18
3.2 Rule Warehouse System Architecture .................................................. ........ 20
3.2.1 R ule Im port Service ........................................................ ......... ..... 21
3.2.2 Rule V erification Service............................... ................................ 21
3.2.3 Rule Export Service ........................................................ ......... ..... 22
3.2.4 R ule M anagem ent Service .................................. .................................... 22
3.3 Chapter Sum m ary .... ............................................... ....... ..... .............. 23

4 ACTIVE OBJECT MODEL: A NEUTRAL KNOWLEDGE REPRESENTATION..25

4 .1 A ctiv e O bject M o d el ............................................................................................. 2 6
4.2 Constraints .... ............................................ 28
4.2.1 A tribute Constraints......................................................... .............. 30
4.2.2 Inter-attribute C onstraints .................................... ............................. ....... 31
4 .2 .3 Inter-class C on straints.......................................................... .... ................ 32
4.3 Event-and-action-oriented Knowledge .............. ............................................ 33









4.3.1 Events ........................... ...... ...... ............. .......... 33
4.3.2 Event-and-action-oriented Rules ......................................... ..... ......... 35
4.3.3 T riggers ...................................................................... ........ 37
4.4 Chapter Sum m ary .... .................... ........................ ........ ..... .............. 39

5 INTEGRATED BUSINESS RULE VERIFICATION...........................................40

5.1 G general A approach ......... .. .... ....... .. ...... ........................ ......... ......... 4 1
5.2 Assumptions and Definitions................................................... .................... 43
5.2.1 Simplifying Assumptions................... ............................. 44
5.2.2 Definitions for Event-and-action-oriented Rules: ..................................... 44
5.2.3 Rule Execution M odel ........................ .......................... 45
5.2.4 Definitions for Objects and Object States:............................................... 45
5.2.5 Modeling the Side-effects of Methods........................................................ 46
5.3 Non-Termination Detection ............................. .. ............................................ 47
5.3.1 Algorithm for Non-Termination Detection................................................... 49
5.3.2 Completeness and Soundness of the Algorithm .......................................... 58
5.4 Inconsistency and R edundancy.................................... ............................. ...... 60
5.4.1 D definition of Inconsistency .................................... .......................... ........ 60
5.4.1.1 Definitions of Contradiction .............. ............................................ 61
5.4 .1.2 D definition of C onflict........................................................................ ... 62
5.4.2 D definition for R edundancy ................................................................. 62
5.4.3 Algorithm for Inconsistency and Redundancy Detection........................... 64
5.5 Extension to an Existing Logic Rule Verification Algorithm ........................... 68
5.5.1 Inconsistency D election .......................................................... .................... 68
5.5.1.1 Introduction to a Resolution-based Inconsistency Detection Algorithm 69
5.5.1.2 Inconsistency D election ................................ .................................. 73
5.5.1.3 C contradiction D election ................................................. ................. 74
5.5.1.4 M ethod Invocation Support .......................................... ..... ......... 75
5.5.1.5 Putting Them Together .................................... .................................... 79
5.5.2 R edundancy D election ............................................................... .............. 79

6 SYSTEM DESIGN AND IMPLEMENTATION.............................. .....................82

6.1 R ule W warehouse M anager........................................................... .................... 82
6.2 Rule V erifier ......................................... 85
6.2.1 N on-Term ination.......................................... 87
6.2.1.1 Triggering Graph Formation .................................. .............. 87
6.2.1.2 Preliminary Cycles and Triggering Cycles Detection ............................ 88
6.2.1.3 Activation and Deactivation Graph Formation...................................... 88
6.2.1.4 N on-term nation D election ..................................................................... 89
6.2.2 Partitioning A lgorithm ........................................................... ......... ..... 90
6.2.3 Inconsistency and Contradiction Detection ............................................ 91
6.2.4 R edundancy D etection........................................................ .............. 93

7 COLLABORATIVE PROBLEM-SOLVING.............. .........................................95









7 .1 Sam ple Scenario .................. ............................. .. ................ ......... ................... 96
7.2 Problem D definitions ................................................. .................................... 97
7.2.1 Incomplete Knowledge .......................... ................. .... .............. 98
7.2.2 Conflicting Knowledge........................ ................. .... .............. 99
7.2.3 Don't Care Condition............................. .............. 100
7.3 Interactions between Rule Engines............ ............. .................... 100
7.3.1 Interaction between PSM and CRS............................ 102
7.3.2 Interaction between CRS and ETR .......................................................... 104
7.4 Im plem entations....... .......................... .. ......... .......... ............ .. 106

8 SUMMARY AND FUTURE WORK ............................................. ............... 108

8 .1 S u m m a ry ...................... .. ............. .. ................................................ 1 0 8
8.2 Future Work ..................... ...... .............. 111

LIST O F R EFER EN CE S ......... ............................. .............................. ............... 113

BIOGRAPHICAL SKETCH ............................ .............................................. 121
















LIST OF FIGURES


Figure Page

3-1 O verview of IK N et [SU 0b] ..................................... ................................ ...............19

3-2 A n IKH ub [SUOOb] ...................... ................................ ... ........... 20

3-3 Rule W warehouse System Architecture................ ................... ............. .............. 20

4-1 Constructs of the Active Object Model ... ......................................................27

4-2 Attribute Constraints.................. ...... ...... .. ....... ......... ......30

4-3 Inter-A tribute C onstraints......... ................. ..................................... ............... 31

4-4 Inter-C lass C on straints.......................................................................... ................... 32

4-5 Event-and-action-oriented Knowledge Example: Class Definition ...........................34

4-6 Event-and-action-oriented Knowledge Specification..................... ...............36

5-1 Integrated V erification .......................................................................... ................... 42

5-2 Examples of TG, AG and DG .......................... ....... .................................... 51

5-3 E xam ples for L em m a 5.2 ................................................................... ...................... 53

5-4 Algorithm 5.1: Non-termination Detection Algorithm...............................................56

5-5 Revised Examples of TG, AG and DG................................ ...................57

5-6 A lgorithm 5.2: Partition A lgorithm .............. .............................. .....................67

5-7 Algorithm 5.3: Original Inconsistency Detection Algorithm .....................................70

5-8 Algorithm 5.4: Redundancy Detection Algorithm .............. ............ .....................80

6-1 Rule Warehouse System Component Diagram .................................. ...............83

6-2 Rule Verification Graphical User Interface..... .................. ...............84









6-3 Logic Rule Transformation Pseudo-code ........................................... ............... 86

6-4 Deactivated-termination Condition Detection Pseudo-code ......................................89

6-5 Rule Partitioning Pseudo-code ............................................. ............................. 90

6-6 Inconsistency D election Pseudo-code....................................... ......................... 91

6-7 Redundancy D election Pseudo-code ........................................ ........................ 93

7 -1 S cen ario X ........................................................................... . 9 7

7-2 Sample Rules for Collaborative Problem-solving .....................................................98

7-3 Collaborative Problem-solving System Architecture ...................................................101

7-4 Problem Solver M monitor (PSM ) .............................................................................. 106















Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy

RULE WAREHOUSE SYSTEM
FOR KNOWLEDGE SHARING AND BUSINESS COLLABORATION

by
Youzhong Liu

August 2001

Chairman: Dr. Stanley Y. W. Su
Cochairman: Dr. Herman Lam
Major Department: Electrical and Computer Engineering

In collaborative e-business, the business rules of different business partners need

to be shared electronically and be used to solve business problems collaboratively. To

achieve this, a neutral knowledge representation is needed to translate heterogeneous

rules into the neutral representation so that:

* Pair-wise translations between rule representations can be avoided.
* The collection of rules can be verified to identify inconsistencies, redundancies, and
non-termination conditions.

In this dissertation, we describe the design and implementation of a Rule

Warehouse System (RWS), which allows heterogeneous business rules to be imported

and transformed into the neutral knowledge representation, verified to eliminate rule

anomalies, and exported for use by some existing rule systems to support collaborative e-

business applications. An Active Object Model is used as the neutral knowledge

representation for different types of rules commonly recognized in the literature, and

several algorithms are developed and implemented for the detection of rule anomalies.









The verification process first converts all types of rules into an event-and-action-oriented

representation. An algorithm is then applied on the set of transformed rules to detect

non-termination conditions. Next, the same set of rules is partitioned based on their

associated events before applying algorithms on each partitioned subset to detect

inconsistencies and redundancies. These algorithms take into consideration the side-

effects of methods can be called in rules.

An important benefit of an RWS is to integrate the knowledge acquired from

different sources to solve problems that cannot be solved by using the knowledge and the

rule engine of an individual source. In this dissertation, we describe our work on the

integration of a deductive rule engine with an event-and-action-oriented rule engine to

demonstrate collaborative problem-solving by using both constraint-oriented and event-

and-action-oriented rules.














CHAPTER 1
INTRODUCTION

E-business is one of the fastest growing Internet-based distributed applications.

According to a white paper from Morgan Stanley Dean Witter [PHIOO], there have been

three major phases in the evolution of e-business technology: EDI (Electrical Data

Interchange), Basic E-commerce (e.g., online retail), and business exchange (e.g., the

marketplaces built by CommerceOne and Ariba). More and more information is shared

in the evolution of these stages; however, collaboration among business partners is still

limited. Most of the Business-to-Business (B2B) operations are still performed

manually. Telephone and fax are still the most important business tools. People spend

much time and effort in communicating and understanding business partners' business

rules and regulations. According to [PHIOO], the next stage in the evolution of e-business

is collaborative e-business, which is characterized by more knowledge sharing and

collaboration among businesses.

Collaborative e-business is attractive because of the tremendous benefits it offers.

Efficiency is the key to win or stay in contention in the e-business battle. Business

Process Reengineering (BPR) and workflow technology [WFM99] allow optimization of

the internal management of an enterprise to improve efficiency. However, inter-

enterprise collaboration, one of the most important factors that affect the efficiency of the

entire supply chain, is still in its infancy in e-business. Automated collaboration is very

limited in current e-businesses.









In order to automate e-business collaboration, the business knowledge of different

business partners needs to be shared electronically and used to solve business problems

collaboratively. The business knowledge of individual companies is commonly

expressed in terms of business events and rules and managed by some rule-processing

systems [BRO01, HAL99]. The event and/or rule representation and the rule-processing

system of one company may be different from those of others. It is important to have a

way of capturing and sharing these heterogeneous events and rules because they are

important resources just like data, application systems, hardware systems, etc., that

individual companies can contribute to the joint business.

We propose a business Rule Warehouse System (RWS) to support business event

and rule sharing. It integrates heterogeneous business events and rules and allows the

integrated events and rules to be deployed, which results in better intelligence and

collaboration among businesses. Also, rules managed by the RWS can be exported to

legacy rule systems to be used by individual companies, thus achieving business

knowledge sharing. An RWS consists of a Rule Warehouse and a Rule Warehouse

Management System (RWMS). The Rule Warehouse provides a persistent repository to

integrate and store heterogeneous business rules. The RWMS provides a set of e-services

for users and applications to extract, integrate, and deploy business rules.

There are two major obstacles to developing such an RWS. One is neutral rule

representation, which must be semantically rich enough to accept the importing requests

from any business rule source. Existing works [GRE96, OUS96] extend object models to

support a certain type of business rule, such as constraints and Event-Condition-Action

(ECA) rules; but none of them is semantically rich enough to accommodate all kinds of









business rule specifications. The other obstacle in building such an RWS is that rules

imported into the Rule Warehouse may contain anomalies, such as inconsistency,

redundancy, and cyclic conditions. They need to be verified by the RWS to detect and

take proper actions to remove or accommodate rule anomalies. Rule-base verification

has been an important area of research in the expert system community [CRA87,

NGU85, SUW82, WU93b, ZHA94]. Techniques for verifying expert system rules are

available; however, the verification of a rule base containing event-and-action-oriented

rules is a much more challenging problem because this type of rules contains method or

procedure calls, which can have side effects. Besides, this type of rules is triggered by

different events, and the execution of rules may post events to trigger other rules.

This dissertation focuses on providing solutions to the two major challenges. The

remainder of this paper is organized as follows. After a survey of the related works in

Chapter 2, the services and architecture of an RWS are given in Chapter 3. A set of key

technologies required to support the RWMS services is also outlined in Chapter 3. Then,

in the remainder of this dissertation, we will provide some details on the focused

technologies. In Chapter 4, an Active Object Model (AOM) is presented. It serves as a

common rule representation for capturing business objects and their associated business

rules. Heterogeneous rules are converted into this common representation. AOM is an

object-based knowledge model capable of defining objects in terms of attributes and

methods (just like traditional object models) as well as events, different types of rules,

and triggers. In Chapter 5, we present the results of our work on rule verification. We

introduce verification methods for detecting inconsistency, redundancy, and non-

termination anomalies that may exist in the knowledge specifications stored in the Rule






4


Warehouse. Implementation of the rule warehouse system is presented in Chapter 6. In

Chapter 7, we describe how a Deductive Rule Engine (DRE) and an Action-oriented Rule

Engine (ARE) can be integrated to perform collaborative problem-solving, as an example

of applying the integrated business rules to solve business problems. Finally, Chapter 8

gives a summary and future work.














CHAPTER 2
SURVEY OF RELATED WORK

Our work on the design and development of a rule warehouse system involves

several emerging fields of research and technology. The key technologies that have

motivated us to pursue this research are rule systems, business rule management,

knowledge sharing, rule verification, and collaborative problem-solving.


2.1 Rule Systems

Rules have long been a common knowledge representation in the artificial

intelligence (AI) area and, more recently, in other areas such as active database systems.

Four types of rules are commonly recognized and distinguished: logic rules [GON97],

production rules [GON97], constraints [KIM98], and event-and-action-oriented rules

[WID96].

Logic rules are expressed in the form, P- Q, which stands for "IfP is true, then

Q is true," where P and Q are logical expressions and P is the antecedence and Q is the

consequence. Logic rules can be processed by different types of logic-based rule engines

using different inference schemes (e.g., forward chaining and backward chaining) to

solve various types of problems in AI. A production rule system is one type of logic-

based rule system. It is also known as an expert system and is designed to solve complex

problems by using experts' knowledge captured in rules. In an expert system, data are

stated as facts in a fact base. A fact is inserted into the fact base if it is true, and removed

from the fact base if it becomes false. An example of commercial rule system of this type









is the expert-system-based products of the Haley Enterprise, Inc. They are designed to

support business rule processing in the eCRM (electrical Customer Relationship

Management) application area [HAL99]. Haley Enterprise's products use an extended

Rete Algorithm (Rete++) to provide better performance and scalability in rule processing.

Constraints are widely used in database and business areas for specifying many

types of data and business constraints. They are used in database systems to enforce

security and integrity constraints and in constraint satisfaction processors to verify if

some data conditions violate some specified constraints. For example, a data integrity

constraint states that the salary of an employee cannot exceed the salary of his manager.

If any operation that changes an employee's salary violates the constraint, the transaction

associated with the operation will be rolled back. In business, a product specification (in

terms of constraints) of a buyer can be matched against the capabilities (in terms of

constraints) of a supplier to determine if the supplier is a qualified one in a supplier

selection process. Constraints are often used in constraint satisfaction processing systems

for verifying if some input specification violates the constraints managed by these

systems. The University of Florida group (UF) uses a constraint language that is

modeled after the OMG's constraint language to express the requirements and constraints

associated with products and services that suppliers/buyers want to buy or sell. The

language and a constraint satisfaction processor are used in UF's automated negotiation

server [HAMOO, HUAOO, SUOOa] for evaluating the contents of a negotiation proposal

against some pre-registered constraints.









Event-and-action-oriented rules are commonly used in active database systems

[HAA90, HAN92, MCC89, STO88, WID96]. There are two general types of event-and-

action-oriented rules: triggers and event-condition-action (ECA) rules.

Triggers in active databases enforce business knowledge by automatically

invoking data operations when a predefined condition is satisfied. In a trigger definition,

a condition and some data operations are specified [HAN92]. A database operation such

as Delete, Insert or Update would trigger the evaluation of the condition part of a trigger.

If the condition is True, then the data operations of the trigger are performed

automatically. For example, a business rule specifies that, if a customer's address is

modified, then any unshipped orders for that customer should be shipped to his/her new

address. To support this business rule, a trigger is defined to update the shipping address

of the unshipped orders of that customer in an Order table whenever that customer's

address in the Customer table is modified.

ECA rules [HAA90, MCC89] are generalization of database triggers in that

events can be any events of interest, not just upon storage operations, and that triggered

actions can be any type of operations, not just database operations. The semantics of an

ECA rule is, "When an event is posted, the condition part is checked. If the condition is

true, then perform the action." Many active databases have been built using ECA rules.

Starburst [HAA90], POSTGRES [STO88], HiPAC [CHA89], and Sentinel [ANW93,

CHA92, CHA94] are good examples.

ECA rules have been applied in some commercial systems. In Blaze Advisor

[BRO01], which is the main product of Blaze Software, Inc., business rules and policies

specified in the ECA format are separated from the procedural logic in application









development so that an application system can easily adapt to changes in business by

modifying the rules. Vitria's Businessware is used to model business processes in a

supply chain environment [VITOO]. The system uses ECA rules to specify conditional

transitions between activities in process models.

In [LAM98], Lam and Su extended the ECA rule format into an Event-Trigger-

Rule (ETR) rule format, which differ from traditional ECA rules in three significant

ways:

* Events (E) and rules, which specify conditions (C), actions (A), and alternative
actions (Alt-A), are defined separately.
* Triggers (T) are specified to link posted events (or trigger events) to the evaluation of
an event history (or composite event) and to the execution of rules; this provides more
flexibility for linking events and rules, which can be defined by different individuals
or organizations.
* Linear, tree, or network structures of rules can be triggered by one or more triggering
events instead of isolated or prioritized rules. The trigger specifications in ETR
provide a very flexible way of linking events with potentially complex structures of
rules to capture semantically rich and useful knowledge.

An event-and-action-oriented rule engine, called the ETR Server [LEEOO], has

been implemented to process ETR rules in the Database Research and Development

Center at the University of Florida. The ETR server has been used in several research

projects for different purposes, such as processing decision rules that implement

negotiation strategies in [HUAOO, SUOOa] and Internet-based Knowledge Network

[LEEOO].


2.2 Business Rule Management

Business rules are high-level specifications of logic and control that are needed to

conduct and manage intra- and inter-enterprise operations [EEC99]. High-level

specification and management of business rules is more effective than implementing

rules in programs using traditional programming languages. By separating the business









logic from the programming logic in an application, business rules can be changed

without modifying the rest of the application [BRO01]. An additional benefit of

specifying business rules in a high-level rule specification language is that it is easier for

non-programmers, such as business executives, to understand.

2.2.1 Business Rule Definitions

In 1993, an IBM User Group, GUIDE, established a project to articulate the

requirements and possible approaches to specify business rules. The group published a

final report in 1997 [GUI97]. The definition of a business rule given by the GUIDE

project is widely referenced in the literature. It defines a business rule as "... a statement

that defines or constrains some aspect of the business. This must be either a term or fact

(described as a structural assertion), a constraint (described as an action assertion), or a

derivation." A fact or structural assertion states an item of importance to the business,

which either exists as a concept of interest, or exists in relationships to other items of

interest. An example of fact is "In 1999, a specific car model was involved in 23,456

accidents nationwide." An action assertion is a statement about some dynamic aspect of

business. It specifies constraints on the results that actions can produce. For instance,

"Any change to the inventory of a given model of cars (the action) is subject to the

constraint that the number of doors on hand for that model must not fall below some

threshold." A derived fact is created by a derivation, which is an inference or a

mathematical calculation from terms, facts, other derivations, or action assertions. For

example, "The number of doors to be replaced for a given car model can be obtained by

multiplying the number of accidents which involve this particular car model by the

probability that one or more doors will be damaged in an accident."









In 1999, the Meta Data Coalition proposed a Business Rule Model (BRM)

[MDC99] by adopting GUIDE's business rule definition. Business rules are classified

(as for GUIDE) into term rules, fact rules, action rules, and inference rules. Term rules

and fact rules are very much the same as the facts or structural assertions in GUIDE. In

BRM, action rules are statements concerned with the invocation of actions, such as

events, pre-conditions, and post-conditions. BRM differs from GUIDE in that an event is

considered as a part of the condition. Inference rules in BRM describe the inference or

derivation of a business rule from other rules or by mathematical calculations. They

capture knowledge that is dynamically derived instead of explicitly stored.

Later, in Chapter 4, we show our support for the above business rule definition

and classification. We use an Active Object Model (AOM) to incorporate business rules

in the definition of a business object. In AOM, term and fact rules are represented by

structural information of an object, whereas constraint-oriented and event-and-action-

oriented rules are used to represent inference rules and action rules, respectively, as

defined in BRM.

2.2.2 Business Rule Management

In recent years, management of business rules has attracted much attention. John

Zachman [ZAC87] provided a useful context for discussing the architecture of an

information system. Much of the research work on business rules is based on the

"Zachman Framework." In [GOT97, HAY99, PL099], the authors pointed out the

necessity and importance of better management of business rules. Seiler [SEI99]

proposes a repository-based approach to manage business rules. Ronald Ross wrote a

comprehensive book on this subject [ROS97b], and Barbara von Halle published a

number of articles in Database Programming and Design [HAL97a, HAL97b], in which









the importance and the use of business rules is stressed. A family of cooperative

protocols is introduced in [GRE96] to maintain global constraints in a federated database

environment.

Some existing works extend the traditional object model to manage business

rules. Oussalah et al [OUS96] proposed a CHIC (Constraints in HIerarchical Composite

objects) model to integrate the description and management of constraints in a composite

object model. These constraints allow the system to maintain a coherent composite

object and confer on it an improved semantics capacity. Rouvellou et al [ROUOO]

presented an ABR (Accessible Business Rule) framework to extend business objects with

business rules. Business rules are externalized and can be fired through trigger points

that represent the specific places from which externalized rules will be fired. The code in

a trigger point interacts with the ABR runtime to locate the required ruless, to gather the

information required as input, to fire rules locally or remotely in the desired language

regime, and to deal with the results of rule firing. The work presented in [OUS96] dealt

with constraints, whereas the idea presented in [ROUOO] is analogous to the ECA rules in

active database systems.


2.3 Knowledge Sharing

To remain competitive in world markets, companies explore new ways to put

enterprise knowledge in the hands of customers, suppliers, and partners; and share

intellectual capital with them [AP099]. It has become very important for advanced

organizations to make the best use of information gathered from various document

sources inside the company and from external sources such as the Internet and business

partners [DZBOO].









Knowledge sharing has attracted much attention from various fields in both

academia and industry [AP099, DIS01, KANOO, PEROO, SHA99, SWA01]. Social

science focuses on the factors that prevent people from sharing their expertise [DIS01].

Business management emphasizes the characteristics of different types of knowledge and

knowledge sharing [APO00, KANOO] whereas information scientists provide the basic

infrastructure for knowledge sharing [SHA99].

Knowledge sharing requires different approaches and is more dependent on

community building than information technology because various factors prevent people

from sharing their knowledge. Disterer [DIS01] discussed individual and social barriers

that hinder people from sharing and transferring their knowledge. It is often stated that

people use knowledge for their own benefit and that they share it grudgingly. This may

be true because our culture tends to discourage knowledge sharing. From an individual

point of view, employees are not willing to share their knowledge with their colleagues

because they may not realize the benefits resulting from sharing their own knowledge

with others. Instead, their concerns are loss of power and increase of byproduct

uncertainty. Social barriers include lack of common knowledge representation language,

bureaucracy, and the hierarchy of enterprises.

Knowledge is generally classified into two categories: explicit and tacit. Explicit

knowledge is formal and systematic and, thus, it is easy to communicate and share. It can

be transmitted in a formal language and stored in databases, libraries, etc. Tacit

knowledge is personal knowledge that is hard to transmit. It consists of mental models,

beliefs and perspectives that cannot be easily articulated and shared. Since we are









interested in sharing knowledge electronically, our work is to integrate and share explicit

knowledge instead of tacit knowledge.

The authors of [KANOO] describe a multi-method approach for studying the

tension between explicit and tacit knowledge. The project examines knowledge

processes and technology in distributed, multidisciplinary scientific teams in the National

Computational Science Alliance, a prototypical next generation enterprise. First, they

review evidence for the tension between explicit and tacit knowledge. Then they present

their three-factor conceptualization that considers how the interrelationships among

characteristics of the knowledge shared, group context, and communications technology

contribute to the tension between explicit and tacit knowledge. Based on this

conceptualization, they suggest that this dichotomy does not fully explain distributed

multi-disciplinary knowledge processes. Therefore, they propose some alternate models

of how knowledge is shared. They introduce the setting in which they are studying

distributed knowledge processes.

Apostolou et al [APO00] classified knowledge sharing into four modes:

knowledge socialization, knowledge externalization, knowledge internalization, and

knowledge combination. Knowledge socialization generates new tacit knowledge by

sharing and exchanging know-how and past experiences. Knowledge externalization

involves structuring knowledge and making it available to other users. Knowledge

internalization maps explicit knowledge into internal knowledge. Internalization occurs

when individuals exposed to other people's knowledge make it their own. Knowledge

combination generates new knowledge by combining pre-existing explicit knowledge and









bringing it together to produce new insight. Decision support systems and workflow

applications are typical supporting tools for knowledge combination.

To provide the basic infrastructure for electronic knowledge sharing, Sharda et al

[SHA99] presented a knowledge network. Focusing on knowledge sharing in a group of

people who are working toward the same purpose, it is defined as a co-operation of

individuals who produce, share, or use a common repository of knowledge, to support

group work. IBM Watson Common Rules group uses Courteous Logic Programs (CLP)

[GRO99a, GRO99b] as the rule interlingua for exchanging heterogeneous logic-based

rules in XML documents. Apostolou et al [AP099] presented a three-tier architecture of

knowledge sharing for supply chain management in the wood/furniture sector.


2.4 Rule Verification

2.4.1 Logic Rule Verification

Existing works on rule verification deal mostly with verification of logic rules.

Early works [CRA87, NGU85, SUW82] detected simple manifestations of redundant,

contradictory, and missing rules. Detection is based on rule connectivity and pair-wise

checking, with time complexities of O(n) and O(n2), respectively. Pioneering systems

include the RCP [SUW82] and CHECK [NGU85]. More recent works [GIN88, PRE92,

ROU88, STA87] extend the definitions of anomalies beyond simple pairs of rules.

Redundancies and contradictions arising over chains of rules can be detected, as well as

the detection of more subtle cases of missing rules. The time complexity for detection is

usually O(bd), where b is the breadth of the rule base, defined as the average number of

literal in-rule antecedents; and d is the depth of the rule base, defined as the average

number of rules in an inference chain. There is no correlation between the number of









rules of declarations in the system and the cost of verification [PRE94]. Three other rule

base verification systems are worth noting: COVER [PRE92], PREPARE [ZHA94] and

EHLPN [WU97]. In COVER, only relevant combinations of data items are considered.

Smaller environments are tested first, and any larger environments that are subsumed by

the smaller ones are not detected. PREPARE uses Petri-net models to study rule

verification; however, it assumes that no variables appear in the rule bodies, and it does

not deal with relationships involving negative information in rules. EHLPN uses an

enhanced high-level Petri-net. It requires the closed-world assumption, conservation of

known and unknown facts, and refraction.

Other work performs anomaly detection based on rule semantics instead of their

syntactic representations alone [ROS97a, WU93a, WU93b]. Wu and Su [WU93b]

formally defined the problem of inconsistency and redundancy of a knowledge base

based on rule semantics and related it to the concept of unsatisfiability in formal logic in

order to make use of the solid theoretical foundation established in logic for rule

verification. A unified framework was developed for both rule verification and rule

refinement. Also, a reversed subsumption deletion strategy is used to improve the

verification efficiency.

2.4.2 Rule Verification in Active Databases

Some work has been done to address the termination and confluence problem of a

rule set in active databases. However, this work is limited in that the conditions and

actions of the rules are restricted to database operations. Termination means that the rule

processing is guaranteed to terminate for any user-defined application [BAR98].

Confluence means that the execution of a rule set will reach the same final database states

for an application regardless of the order of rule execution [BAR98]. Karadimce et al









[KAR94] reduced rules into term-rewriting problems and applied known algorithms to

attack the termination problem; however, the approach is very complicated even for a

small rule set. Weik et al [WEI95] presented techniques for the termination analysis of

rules with delta relations in the context of OSCAR, an object-oriented active database

system. The concept of Triggering Graph was introduced in [BAR93] to detect the

termination of a database rule set. The work was further extended in [BAR94] to support

both termination and confluence by limiting the rule set to Condition-Action rules. Aiken

et al [AIK95] tried to determine the termination and confluence of a database production

rule set statically for both CA and ECA rules. Baralis et al [BAR95] proposed a

technique to deploy the complementary information provided by Triggering Graphs and

Activation Graphs to analyze the termination of ECA rule sets; however, techniques for

constructing the graphs are assumed. In [BAROO], an extended relational algebra was

presented and applied by a "propagation" algorithm to form the graphs. The static

analysis of a rule set and the detection of endless loops during rule processing at runtime

were combined in [BAR98].

Although some important research results have been achieved in the above works

on the verification of database rules, all of them require that the conditions and actions of

rules be database operations, i.e., insertion, update, deletion and selection. Moreover,

most of the works only handle CA rules. Even in those that can handle ECA rules, either

the solution is very restrictive (e.g., [BAR95] requires that there is no cycle in a

Triggering Graph), or some limitations are put on the ECA rules to reduce them to CA

rules (e.g., the Quasi-CA rules introduced in [BAROO]). Finally, none of the work

addresses the invocation of methods in the condition part and the action part of a rule.









2.5 Collaborative Problem Solving

Research on collaborative problem-solving focuses on providing an infrastructure

to allow team members to exchange information and solve problems collaboratively,

especially in a collaborative design environment. Most of the available work [SHA99,

DIS01] focuses on enabling human collaborative problem-solving by integrating

knowledge across disparate communities and providing more assistance to the decision

makers. We are interested in solving problems using knowledge from disparate

communities by automatically or semi-automatically using rule engines.

There are some existing works on the collaboration between different types of

rule engines. In the EECOMS project, the rule engines used by the University of North

Carolina at Charlotte (UNCC) and UF have been integrated to demonstrate the interaction

between supplier selection and negotiation in EECOMS's Scenario 1 [EEC99]. The UF

group developed a translator for converting UF's constraint language into IBM's CLP to

demonstrate the use of the rule interlingua [EEC99]. UF's ETR Server has been

integrated with Vitria's Businessware to demonstrate the interaction between business

rules and business processes in EECOMS's Scenario 5 [EEC99].














CHAPTER 3
RULE WAREHOUSE SYSTEM

The Rule Warehouse System (RWS) is a part of the larger effort to build an

Internet-based Knowledge Network (IKNet) technology for knowledge-based

collaborative business being developed at the Database Systems R&D Center of the

University of Florida. IKNet is a network of IKHubs, each of which consists of a number

of cooperative servers to provide e-services to applications and users. One of the servers

is the Rule Warehouse Server, which provides e-services to the other servers. In this

chapter, we introduce the basic concept of IKNet in Section 3.1 and identity the services

and present the architecture of the Rule Warehouse System (RWS) in Section 3.2. The

conclusion of this Chapter is given in Section 3.3.


3.1 Internet-based Knowledge Network

The Internet and Web technologies have brought about rapid and significant

changes in the way business enterprises operate, and the technologies have altered the

nature of business competition. They, together with the distributed object technology,

provide the basic information infrastructure to enable the sharing of heterogeneous data

resources and the interoperation of application systems across the Internet; however, this

basic infrastructure is not sufficient to fully support Internet-based e-business enterprises

because, in addition to sharing data and application systems over the Internet, e-business

enterprises require an effective way to manage and share business knowledge. Thus, a










more powerful, integrated and scalable information infrastructure is needed to support e-

business management.

Su and Lam [SUOOb] extended the current basic information infrastructure and

introduced the concept and architecture of an IKNet. Business participants would

register with and make use of the e-services provided by a network of IKHubs. The

proposed infrastructure and its relationship with existing application systems, distributed

objects (DO), active distributed objects (ADO), agents, and Web browsers are shown in

Figure 3-1. A number of IKHubs are installed at some selected sites in the Internet.

Each IKHub consists of a set of e-business servers in addition to a Web server, as shown

in Figure 3-2. Each e-business server provides a set of e-services, much the same way as

a Web server provides Web services. Internet users can still use the existing Internet and

Web services as they are, but the IKNet members can have access to additional services.

Browser ADO DO Agent Browser



C[t n IKnet Infrastructure
IKhub J ... IKhub


Figure 3-1 Overview of IKNet [SUOOb]



As shown in Figure 3-2, the servers in an IKHub work collaboratively to provide

a set of e-services. The IKHub can be expanded with the addition of more servers. The

rule warehouse server in the IKHub is responsible for business rule integration and

sharing. The integrated business rules can either be dispatched to other servers in the

IKHub or be stored in a centralized warehouse, to be checked out by the applications or

other servers when needed.

















S'i I- 11 11P I 11 II


Scijcc


\V'r k f'lu. A
____ Scr I\ II. c. ___


II pp R Il .c i c l. i. II
,S1 I C IC C L'


Si li.' r


Figure 3-2 An IKHub [SUOOb]


3.2 Rule Warehouse System Architecture

Figure 3-3 shows the architecture of the Rule Warehouse System (RWS). There


are three major components:


External
Application


External
Application


Figure 3-3 Rule Warehouse System Architecture




*Rule Warehouse (RW). The RW is a repository of the rules. Additionally, it
contains catalog information about the rules (e.g., types of rules, sources of the rules,
security information, etc.).









* Rule Warehouse Manager (RWM). RWM provides functions to support rule
management services, such as browsing; directory functions; and event and rule
definitions, modifications, and deletions. The other components of the RWS use the
RWM services to read from and write to RW. It also assists in the import and export
services.
* Rule Verifier (RV). The Rule Verifier is used to verify if the rules in the RW contain
rule anomalies such as inconsistencies, redundancies and non-termination conditions.
RV can be used to verify the entire rule set in RW, or a part of the rules.

RWS provides a set of services to the clients of RWS: rule import, rule

verification, rule export, and rule management.

3.2.1 Rule Import Service

The rule import service facilitates the importing of dissimilar rules from

heterogeneous sources into RW. For rule importing, each rule source (shown at the

bottom of Figure 3-3) makes use of a source-specific translator to convert rules from its

native format into the neutral rule representation supported by RWS. This is essentially a

schema as well as a syntactic translation of rules. The translator needs to have some

knowledge about the schema (i.e., object entities, attributes, and their inter-relationships)

assumed by these native rules.

The neutral representation is an Active Object Model (AOM) representation.

AOM is an extended object model capable of representing objects in terms of

attributes/properties and methods (just like the traditional object model) as well as events,

rules, constraints, and triggers. We will describe AOM in more detail in Chapter 4.

3.2.2 Rule Verification Service

Newly imported rules need to be combined with the rules that have been imported

into the RW, and they need to be verified to detect possible rule anomalies in the

combined rule set. Upon receiving the import request, the Rule Warehouse Manager

combines the imported rules with the rules already stored in the Rule Warehouse and









invokes the Rule Verifier to verify the rules for inconsistency, redundancy, and non-

termination. If no anomaly is found, the imported rules are deposited into the Rule

Warehouse by the RWM. The catalog of the Rule Warehouse is updated accordingly. If

the Rule Verifier finds some anomalies or possible anomalies, proper messages will

prompt the user or the Rule Warehouse Administrator to examine the imported rules.

The user or the Rule Warehouse Administrator may then correct the rules to remove the

identified anomalies.

3.2.3 Rule Export Service

Rules in RWS can be exported to applications and rule systems to support

collaborative e-business applications. In [LIUOO], a deductive rule engine interacts with

an event-and-action-oriented rule engine to perform collaborative problem solving. In

[SUOOa], a replicable, rule-based, negotiation server is used to support automated

negotiation in an e-business environment. Both of them can use the rules exported from

the warehouse to aid decision-making.

Rule exporting works in a similar way as rule importing. The rules to be exported

to an existing rule system are converted by an adapter from the AOM representation to

the native representation of the target rule system. It is the rule system's responsibility to

verify if the imported rules (exported from the Rule Warehouse) conflict with its own

rules. It should be noted that not all the rules of the Rule Warehouse can be exported to

an existing rule system because of the semantic mismatch between the rule

representations of the warehouse and the native rule system.

3.2.4 Rule Management Service

This service is necessary to support an effective sharing of rules. Before a user

can make a proper request to export rules from the Rule Warehouse into his/her rule









system, he/she needs to know what rules are available in the Rule Warehouse and how

they may meet his/her needs. The rule management service provides browsing and

directory functions for users to browse the contents of the Rule Warehouse and to retrieve

events, rules, and catalog information associated with events and rules (e.g., the types of

rules, the sources of the rules, the authorization information, etc.). After browsing, a user

can issue a retrieval request for rules. The retrieval request is forwarded to the Rule

Warehouse Manager (RWM), which performs the retrieval operation and presents the

result to the user.

Additionally, RWM provides functions to define new events and rules and to edit

and delete existing events and rules. For the convenience of human users, business

events and rules need to be specified at a high-level of abstraction, using an easy-to-

understand representation, and a user-friendly graphical interface. Rule definition and

editing can be performed using the GUI facility provided by the RWM. After receiving

new rules or modified rules, the RWM will activate the Rule Verifier to verify if the new

or modified rules will introduce rule anomalies to the entire rule base. If no anomaly is

found, the RWM will deposit these rules into the RW.


3.3 Chapter Summary

In this Chapter, we have described the concept of IKNet and the architecture of

the Rule Warehouse System. The services provided by a Rule Warehouse System have

been described as well.

Two key technologies are required to realize a rule warehouse system:

* Neutral rule representation for the rule warehouse.
* Rule verification to detect the anomalies in the imported rules.









In the following two chapters, we will provide some details on these technologies.

In Chapter 4, an Active Object Model (AOM) is presented. This model is used to

provide a neutral representation for objects, events, and rules imported into the Rule

Warehouse. The neutral representation is needed to translate heterogeneous rules into the

neutral representation so that:

* Pair-wise translations between rule representations can be avoided.
* The collection of rules can be verified to identify inconsistencies, redundancies, and
non-termination conditions.

AOM is an object model capable of modeling objects in terms of attributes and

methods (just like the traditional object model), and events, constraints, rules, and

triggers. In Chapter 5, we will present our work on rule verification. Verification

methods and algorithms for detecting inconsistency, redundancy, and non-termination

anomalies in the Rule Warehouse will be presented.














CHAPTER 4
ACTIVE OBJECT MODEL: A NEUTRAL KNOWLEDGE REPRESENTATION

The distributed object technology, exemplified by OMG's CORBA, Microsoft's

COM and DCOM, and Java's RMI, is very powerful for modeling all things of interest to

companies that form a virtual enterprise as business objects; however, the underlying

object model of this technology only captures the structural properties of a business

object in terms of attributes/properties and its behavioral properties in terms of methods.

It is not able to capture business events and business rules associated with individual

business objects nor events and rules associated with the interrelationships among

business objects. For a Rule Warehouse System, we extend the traditional object model

into an Active Object Model (AOM). Like traditional object models, AOM can be used

to define individual business objects in terms of attributes and methods. In addition,

events, constraints, rules, and triggers applicable to a number of business objects can also

be defined. Both constraint-oriented and event-and-action-oriented rules can be

explicitly specified. The model is active in the sense that rules, which capture business

policies, regulations, constraints, strategies, etc., can be automatically triggered to

perform some meaningful operations upon the occurrences of events. The object model

provides a neutral knowledge representation for all types of business objects and rules to

be imported into the warehouse. Such a neutral representation is needed so that:

* Pair-wise translations between rule representations can be avoided.
* The collection of rules can be verified to identify inconsistencies, redundancies, and
non-termination conditions.









As described in Chapter 2, the Meta Data Coalition's Business Rule Model

(BRM) classifies business rules into term rule, fact rule, action rule, and inference rule.

This classification is consistent with that of GUIDE. In this Chapter, we will point out

that different types of constraints can be expressed in the form of logic rules (P--Q). In

AOM, we divide a rule specification into two parts: a constraint specification to capture

term rules, fact rules, and inference rules associated with business objects and an ETR

specification to capture action rules.


4.1 Active Object Model

Figure 4-1 gives an overview of the modeling constructs of AOM. The basic

building block of AOM is object class. An AOM class specification consists of the

conventional object specification of attributes and methods. Also included in an AOM

class specification are class-level knowledge specification (CKS) and instance-level

knowledge specification (IKS). Class-level knowledge specification specifies the

common knowledge that all instances of that class share. Instance-level knowledge

specification specifies the knowledge that applies to a particular object instance.

Knowledge specification (KS) is optional and consists of constraint-oriented and event-

and-action-oriented KS. Constraints specified in a class can be attribute constraints

(constraints on individual attributes) or inter-attribute constraints (constraints among

multiple attributes). Event-and-action-oriented KS consists of events, action-oriented

rules, and triggers that relate events to rules.

Classes are contained in a schema. An AOM schema contains a set of classes,

other (sub-) schemas, and schema-level knowledge specification (SKS). For example, a

schema can be used to capture the structural and behavioral properties, and knowledge











specifications of a component in a component architecture. Thus, sub-schemas represent

sub-components of a component. AOM allows the nesting of schemas to any number of

levels. Schema-level knowledge specification consists of inter-class constraints or inter-

class event-and-action-oriented rules.


Schema-level KS
Scem
Schema
Class
Schema Class-level KS
Schema-level KS



Instance-level KS
Class


Instance-level KS
Class-level KS Event-and-action-action-oriented KS





Figure 4-1 Constructs of the Active Object Model




Inheritance in AOM is defined in the same way as inheritance is defined in the

traditional object model. Thus, in addition to attribute and method inheritance, objects of

a subclass can inherit the knowledge specifications) of its superclass(es). For example,

if class c is a subclass of sc, both belonging to schema s, then an object instance i of class

c has the following knowledge specification:


* The instance-level knowledge specification of instance i.
* The class-level knowledge specification of class c.
* The schema-level knowledge specification of schema s and its upper level schemas if
this knowledge specification is related to class c.
* The public class-level knowledge specification inherited from the superclass sc and
sc's superclasses.









We have already pointed out in Chapter 2 that three types of rules are commonly

recognized and distinguished: logic rules (including production rules), constraints, or

event-and-action-oriented rules. Among these three types, the semantics of logic rules

and constraints are the same as will be explained in Section 4.2. Consequently, we only

have two major types of rules to be used for knowledge specification in AOM:

constraints-oriented and event-and-action-oriented rules.

The semantics of an event-and-action-oriented rule is different from that of a

constraint in two ways. An event-and-action-oriented rule has an explicit event

specification, and the evaluation of the Condition and Action parts is triggered by the

occurrence of an event. For a constraint, the concept of a triggering event is implicit.

The second difference is that constraints are more declarative; whereas, event-and-action-

oriented rules are more procedural. In other words, an event-and-action-oriented rule

explicitly specifies the operations to be performed in order to enforce a business rule;

whereas, a constraint simply states the business rule, without specifying how to enforce

it. In the remainder of this chapter, we will describe the knowledge specification part of

AOM.


4.2 Constraints

Logic rules can be processed by different types of logic-based rule engines using

different inferencing schemes (e.g., forward chaining vs. backward chaining) to solve

various types of problems in AI. Although the rule engines work in a different way, the

rules are the same. The general form for logic rules is P-Q, which stands for "IfP is

true, then Q is true," where P and Q are logical expressions and P is the antecedence and

Q is the consequence.









The semantics expressed by logic rules and constraints are the same. Like logic

rules, constraints can be expressed in the form P-Q, also, with the semantics "If P is

true, then Q is true." Two examples are given below:

1. True Delivery_day > 15

2. Quantity > 100 Delivery_day > 10


The first constraint is called an attribute constraint and the second one is inter-

attribute constraint. The antecedent of the first expression is True, specifying the

constraint must be unconditionally enforced. Because of their unified form and

semantics, constraints and logic rules can be used interchangeably. To be consistent with

the literature, we will use constraints when we talk about AOM, whereas, we will use

logic rules in the verification chapter.

Since the semantics captured by constraints can be expressed as logic rules, we

can treat constraints as logic rules and convert them into the same representation. This is

important because when we do rule base verification (to be discussed in Chapter 5), we

need to have a uniform rule representation so that theorem proving techniques can be

applied on logic rules to perform rule base verification. A set of verified logic rules can

be used in a logic-based rule engine for inferencing purposes or in a constraint

satisfaction processing system for constraint checking.

Constraints in AOM can be categorized into Attribute Constraint (AC), Inter-

Attribute Constraint (IAC), and Inter-Class Constraint (ICC). The first two are part of a

class-level knowledge specification; whereas, constraints of the third type are given in the

schema-level knowledge specification.

The syntax for constraints is:

Constraint name: Antecedence(P) Consequence(Q)









The semantics of a constraint is, "ifP is true, Q is true," where P and Q are logical

expressions. Unlike the logic expressions used in expert systems, P and Q in the AOM

may include method invocations. Sometimes constraints can be unconditional, i.e., P is

always "true." For an unconditional constraint, the Consequence can be specified

without the Antecedence. The syntax is:


Constraint name: Consequence(Q)


4.2.1 Attribute Constraints

An attribute constraint specifies the legitimate values of an attribute of a class or

of an object instance. Attribute constraints can have the following three forms:


Figure 4-2 Attribute Constraints



* A simple predicate. For example, in an Order object, if attribute delivery_day has to
be greater than 2, then the predicate (delivery_day > 2) is used to specify the
constraint.
* A complex logical expression with AND, OR and NOT operators. For example, if
we want to specify the constraint that delivery_day must be an even number and be
less than 10, the logical expression ((delivery_day % 2 == 0) && (delivery < 10)) can
be used. Attribute constraints are usually unconditional; however, in some cases,
they can be conditional. For example, a business rule may say, "if the delivery_day is


Class RequestForQuote{

int price;
int delivery_day;
String payment_method;

Attribute Constraint:
C1: price = RANGE [300, 400];
C2: (delivery_day < 10) ( delivery_day % 2 == 0);
C3: payment_method = ENUM ["credit card", "cash"];
}









less than 10, it has to be a multiple of 2." We can specify this rule as, "(delivery_day
< 10) (delivery_day % 2 == 0)," which is shown as constraint C2 in Figure 4-2.
*Two keywords, ENUMERATION and RANGE, can be used in attribute
constraint specifications. ENUMERATION lists all the possible values of an
attribute, and RANGE gives the range of values that an attribute may have. For
example, a business rule may specify that the payment method can be either credit
card or cash (i.e., paymentmethod = ENUMERATION ["credit card", "cash"]
shown as C3 above). Another business rule may state that price must be between
$300 and $400 (i.e., price=RANGE[300, 400]). In a range specification, '[' or ']' can
be used to mean a closed scope and '(' or ')' means an open scope.

4.2.2 Inter-attribute Constraints

An inter-attribute constraint describes the relationship between two or more

attributes. An example constraint of this type is, "model == ModelX && partname ==

DOOR damage_probability = 0.2." It specifies that the damage probability of the

door of a ModelX is 0.2 (based on some existing statistics), if this type of car is

involved in an accident.

The attributes referenced in an inter-attribute constraint specification can be

primitive data type or object reference. Attributes in the above example are primitive

data types. The following example in Figure 4-3 shows an attribute with an object

reference.


Class Employee{

int salary;
Employee manager;

Inter-Attribute Constraint:
C1: salary < manager.salary;
}


Figure 4-3 Inter-Attribute Constraints









In the class definition for class Employee, we use "salary < manager.salary" to

specify the business rule that every employee's salary has to be lower than his/her

manager's salary.

4.2.3 Inter-class Constraints

An inter-class constraint specifies the relationship between the attributes of two or

more classes or the existential relationship between objects in some classes. For

example, in Figure 4-4, the inter-class constraint, "Classl.Al+Class2.B1 > 100 -

Classl.A2 + Class2.B2 < 100," specifies that if the sum of attribute Al of Classl and

attribute B of Class2 is greater than 100, then the sum of A2 of Class and B2 of Class2

has to be less than 100. As shown in the sample schema given below, inter-class

constraints are specified at the schema level, outside of a class definition, because

multiple classes in a schema are involved.

Schema Sample {
Class Class1{

int Al;
int A2;

}
Class Class2{

int B1;
int B2;

}
Inter-class Constraint:
Classl.Al+Class2.B1 > 100 Classl.A2 + Class2.B2 < 100;

Figure 4-4 Inter-Class Constraints









Existential relationship between objects can also be specified as an inter-class

constraint. For example, a business rule specifies, "Whenever there is an Order object for

a buyer, there must be a Credit object to describe the credit of buyer." In AOM, the

above constraint will be specified as an inter-class constraint using the keyword EXIST:

EXIST Order (EXIST Credit A (Credit.buyerName = Order.buyerName))


4.3 Event-and-action-oriented Knowledge

Event-and-action-oriented knowledge can also be specified at the instance level,

class level, or schema level. Event-and-action-oriented knowledge specification consists

of definitions of events, event-and-action-oriented rules, and triggers. In this section, we

give an overview of the event-and-action-oriented knowledge specification in AOM.

Detailed specification can be found in [LEEOO].

4.3.1 Events

AOM distinguishes two types of events: events associated with methods and

explicitly posted events. A method-associated event is related to a method execution.

Depending on the "coupling mode," such an event can be posted "before" or "after" a

method is executed. Shown in Figure 4-5 is a definition of the class Supplier. Shown in

Figure 4-6 is the event-and-action-oriented knowledge specification associated with that

class. The event OrderShipped is an example of a method-associated event (i.e., type

"method") defined in the class Supplier, which is in the schema SCSchema. Method-

associated events are posted synchronously. Thus, trigger and rule are processed and

executed in the same "thread" as the method execution. In this example, the event

OrderShipped is posted right after the method shipOrder is executed (i.e., the coupling









mode is "after"). After the rules are triggered (if any), the control is returned to the

program that made the call to the method shipOrder.

An event can have parameters. For method-associated events, the parameters are

the parameters defined for the called method. When an event is posted, parameter values

will be passed to rules that are triggered by the event. This allows data from the called

method to be passed for use in rule processing. Also, an event that is posted

synchronously needs a return type. For a method-associated event, the return type is the

return type of the called method.

Class Supplier
{
//Attributes...
int credit;
boolean platinum;

//Methods ...
public void shipOrder(int orderlD, ...) {
II ...
}

public void specialService(string orderlD, string type, int flag) {

}

Figure 4-5 Event-and-action-oriented Knowledge Example: Class Definition



An explicitly posted event can be defined at the class level or schema level. The

event OrderException in Figure 4-6 is an example of an explicitly posted event (i.e., type

"explicit") defined in the class Supplier of the schema SCSchema. The posting of an

event would create an instance of the event type. An explicit event can be posted

synchronously or asynchronously. If the event is posted asynchronously, a separate









thread is created and the posting program will not wait for the return of the control. Also,

data is not expected to return and the return type is ignored. If it is posted synchronously,

the posting program is "blocked" to wait for the return of the control and data (if any).

The return type is defined in the event specification.

An explicitly posted event can also have parameters, which are defined in the

event specification. Parameters for this type of events provide a way for a program to

pass data to rules for use in rule processing. When an event is posted, parameter values

will be passed to rules that are triggered by the event.

4.3.2 Event-and-action-oriented Rules

An event-and-action-oriented rule in AOM has a condition-action-

alternativeAction (CAA) structure. When a CAA rule is triggered, the expression

specified in the CONDITION clause is evaluated. If it evaluates to true, the operations in

the ACTION clause are executed. Otherwise, the operations in the ALTACTION clause

are executed. AOM allows a "guarded expression" to be specified in the CONDITION

clause. A guarded expression is a sequence of logical expressions as "guards" to a final

expression. If any one of the guards is evaluated to False, the rest of the rule is skipped

(i.e., not applicable). If all the guards are evaluated to true and the final expression is

also true, the ACTION clause is executed. Otherwise, the ALTACTION clause is

executed. In a rule specification, the CONDITION clause can be omitted. In that case,

the ACTION clause must be given and will be unconditionally processed. If the

CONDITION clause is given, either the ACTION clause or the ALTACTION clause may

be omitted, but not both.

CAA rules provide a very general way for specifying conditional enforcement of

integrity and security constraints, business policies, and regulations, which are relevant to










the operation of a real or virtual enterprise. Each CAA rule represents a small granule of

control and logic. A number of these rules, when executed in a certain order or structure,

can represent a large granule of control and logic needed to enforce a composite business

rule.


IN
EVENT
DESCRIPTION
TYPE
COUPLING MODE
OPERATION

IN
EVENT
DESCRIPTION
TYPE

IN
RULE
DESCRIPTION
CONDITION
ACTION

IN
RULE
DESCRIPTION
CONDITION
ACTION
ALTACTION

IN
TRIGGER
TRIGGEREVENT
EVENTHISTORY
RULESTRUC


SCSchema::Supplier
OrderShipped
The credit of the customer is modified.
METHOD
AFTER
shipOrder //Associated method name.

SCSchema::Supplier
OrderException (string orderlD, string exceptionType)
An exception has occurred for an order.
EXPLICIT

SCSchema::Supplier
DowngradeCustomer
Downgrade a platinum customer.
(platinum == true) && (credit < 0);
{platinum = false;}

SCSchema::Supplier
OrderExceptionRule (string orderlD, string type)
Handles order exceptions.
(type == 's') && (platinum == true);
{specialService(string orderlD, string type,l); }
{specialService(string orderlD, string type,2); }

SCSchema::Supplier
OrderExceptionTrigger (string orderlD, string type)
OrderException
OrderShipped AND OrderException
DowngradeCustomer > OrderExceptionRule


Figure 4-6 Event-and-action-oriented Knowledge Specification


Figure 4-6 shows two examples of event-and-action-oriented rules,

DowngradeCustomer and OrderExceptionRule. DowngradeCustomer specifies that if the

customer is a platinum member and his/her credit is less than 0, he/she will be

downgraded to a non-platinum member. OrderExceptionRule handles an order exception









by calling the specialService method. Depending on the type of exception and the

platinum membership, different parameter values are sent to this method by this rule.

The ACTION and ALTACTION clauses specify the operations that should be carried

out, which can be assignments to some object attributes and/or method invocations.

These clauses may also contain statements that post events to trigger other rules.

The above described the basic capabilities of an AOM rule. For details on some

other capabilities (e.g., guarded condition, rule variables, exception handling, rule return

type, etc.), interested readers should consult the reference [LEEOO].

4.3.3 Triggers

Triggers tie events to rules. A trigger specifies an event structure and a rule

structure. An event structure has two parts: TRIGGEREVENT and EVENTHISTORY.

The TRIGGEREVENT part specifies a number of events called triggering events, each of

which, when posted, would trigger the evaluation of the event history specified in the

EVENTHISTORY part. If the event history is evaluated to true, the structure of rules

specified in the RULESTRUC clause is processed. Otherwise, the structure of rules will

not be processed. EVENTHISTORY is used to specify the relationship between some

events that have already occurred or posted. An event history expression given in this

clause is called a "composite event" in the active database literature. It can contain a

number of simple predicate expressions with logical or sequence operators. For example,

in the trigger OrderExceptionTrigger given in Figure 4-6, the EVENTHISTORY

expression specifies that both events, OrderShipped and OrderException, must have been

posted if the rules specified in RULESTRUC are to be fired. An example of an

EVENTHISTORY expression that contains a sequence operator is (E3 > E2 > El 1),

which specifies that these three events should have occurred in the given sequence.









The TRIGGEREVENT part is purposely kept very simple. Only the occurrence

of any one of the triggering events would trigger the evaluation of a more complex event

history expression. The separation of TRIGGEREVENT and EVENTHISTORY allows

a more explicit specification of what events would trigger the evaluation of event history

and rules. This is different from the event specification of some existing ECA rule

systems in which, when a composite event is specified, all the events mentioned in the

composite event implicitly become the triggering events. In some applications, one may

want to specify that only the posting of E2 should trigger the evaluation of "El and E2,

but not E3." Note, in Figure 4-6, although the events OrderShipped and OrderException

are defined in the EVENTHISTORY, the event OrderShipped is not a triggering event.

The posting of OrderShipped will not trigger the evaluation of the event history. Only

the posting of OrderException would trigger the evaluation. If the TRIGGEREVENT is

omitted, the default mode is ORing all of the events in the EVENTHISTORY.

The RULESTRUC clause of a trigger specification allows a structure of CAA

rules to be triggered when the event specification is satisfied. It specifies the rule

execution order and maps the parameters of the event to the individual rules.

There are two operators for specifying the execution order: the operator '>' is

used to specify a sequential order of rule execution, and the operator ',' is used to specify

a parallel execution. For example, the following expression means that rules R1, R2, R3,

and R4 are to be executed sequentially following the specified order:

R1 > R2 > R3 > R4

The following example shows that rules R1, R2, R3, and R4 are to be executed in

parallel:









(R1, R2, R3, R4)

In Figure 4-6, the RULESTRUC of OrderExceptionTrigger specifies that rule

DowngradeCustomer is fired first, followed by the firing of rule OrderExceptionRule.


4.4 Chapter Summary

In this chapter, we have described the key features of the Action Object Model

(AOM). We extended the traditional object model by incorporating a knowledge

specification component. Knowledge specification can be given at the schema, class, and

instance levels. Knowledge specification is optional and consists of two types:

constraint-oriented knowledge specification and event-and-action-oriented knowledge

specification. Constraints are used as a neutral representation for rules imported from

logic-based and constraint-based systems. Event-and-action-oriented knowledge

specification in AOM is used as a neutral representation for rules imported from sources

that use event-and-action-oriented rules (e.g., ECA systems). Event-and-action-oriented

knowledge specification consists of definitions of events, action-oriented rules, and

triggers. By incorporating these two types of knowledge specifications in the traditional

object model, we are able to have a neutral knowledge representation in the Rule

Warehouse that enables the verification of business knowledge contributed by

heterogeneous sources.














CHAPTER 5
INTEGRATED BUSINESS RULE VERIFICATION

In a Rule Warehouse System (RWS), rules from heterogeneous sources are

imported into the Rule Warehouse to support knowledge sharing and business

collaboration. As explained in Chapter 4, these rules can be broadly classified into two

categories: logic (or constraint-oriented) rules and event-and-action-oriented rules. In

RWS, the different types of rules will be translated into the common AOM representation

so that they can be verified along with the rules that are already verified and stored in the

Rule Warehouse (RW).

Much has been done on the verification of logic rules, and there has been some

work done on the verification of event-and-action-oriented rules; but none of them has

addressed methods' side-effects, and none of them verifies constraints and event-and-

action-oriented rules together. Since these two types of business rules are widely used in

business, it is necessary for us to verify them together. We shall abstract methods' side-

effects, define rule anomalies formally based on rule semantics, and present an integrated

approach to verify the two types of business rules. Our general approach is presented in

Section 5.1. In Section 5.2, we state the assumptions and basic definitions on which our

rule verification work is based. Sections 5.3 and 5.4 present our work on the detection of

the three types of anomalies that may exist in the rules stored in a Rule Warehouse: non-

termination, inconsistency, and redundancy. In Section 5.3, the non-termination problem

for event-and-action-oriented rules is defined formally, and an algorithm for detecting

non-termination is given. The algorithm will make use of Triggering Graphs (TG),









Activation Graphs (AG), and Deactivation Graphs (DG). In Section 5.4, the

inconsistency and redundancy problems are defined formally based on rule semantics,

and our approaches and algorithms for detecting these anomalies are presented. In

Section 5.5, we present the extension to an existing logic rule verification algorithm to

support the new requirements of method invocation in inconsistency, contradiction, and

redundancy detection.


5.1 General Approach

In an RWS, we have both logic (or constraint-oriented) and event-and-action-

oriented rules. These two types of rules may be used independently in some applications;

however, for collaborative problem solving, they may have to be used together. Thus,

there is a need for an integrated verification of logic and event-and-event-and-action-

oriented rules. Two approaches are possible:

* Rewrite event-and-action-oriented rules into logic rules
* Rewrite logic rules to event-and-action-oriented rules.

In the first approach, events can be considered as additional conditions of the

rules; whereas, in the latter approach, explicit events for each logic rule can be

introduced. The latter approach is used in our work because, as we shall point out in

Section 5.4, events can be used to partition the rule set into several related small groups

and apply verification algorithms to those small groups individually to achieve better

performance.

The rewriting process is as follows: We assume in the class definition, the only

way to change the value of an attribute is through a corresponding Set function. We shall

introduce explicit method-associated events to some attributes. Each attribute X involved










in r is considered. We will introduce an event afterSetX, which is associated with the

method setX(, if the event does not already exist. We introduce a trigger to allow this

method-associated event to trigger the rule. In the trigger definition,

TRIGGERINGEVENT is afterSetX; EVENTHISTORY is always true; and

RULESTRUCT contains a single rule r ', whose condition is the LHS ofr and its action is

the RHS of r. This process guarantees that whenever an attribute Xis changed by the Set

method, the afterSetX event will be posted to trigger rule r'. For example, for the logic

rule "A=3- B=4," we will introduce an event afterSetA, if it does not already exist. This

event will be posted after the activation of method SetA(. We also introduce a trigger

afterSetATrigger to trigger rule Y. The condition of Y is "A=3" and its action is "B=4."


Constraint-oriented Event-and-action-
Rules oriented Rules

COR
Rewriter
Event-and-action-oriented Rules


Partition
Non-termination Partition
te tn Algorithm
Detection
Partioned Rul Groups


Inconsistency or
Contradiction Redundancy
Detection Detection
Detection


Figure 5-1 Integrated Verification



Figure 5-1 illustrates our general approach to the integrated verification of the

rules in an RWS. The verification process first converts all types of rules into the event-

and-action-oriented representation. An algorithm is then applied on the set of









transformed rules to detect non-termination conditions. Next, the same set of rules is

partitioned, based on their associated events before applying algorithms on each

partitioned subset to detect inconsistencies and redundancies. By rewriting logic rules

into event-and-action-oriented rules, the verification of rules in a rule warehouse becomes

the verification of event-and-action-oriented rules, which is the emphasis of the

remaining part of this chapter.


5.2 Assumptions and Definitions

Several types of anomalies have been identified in the existing works on the

verification of logic rules in expert systems: inconsistency, redundancy, subsumption,

unnecessary if, dead end, unreachable rules, etc [GON97]. In this work, we focus on the

verification of knowledge specifications in an RWS. Consequently, some of the

anomalies defined for expert systems in the literature are not applicable to this work. For

example, anomalies such as dead end and unreachable rules can cause problems for

expert systems; however, in an RWS, rules can be exported from the Rule Warehouse to

a legacy rule system and be applied together with some other rules. Thus, even if the

rules are unreachable inside the Rule Warehouse, they may become reachable in

conjunction with other rules in the legacy rule system. Consequently, from the RWS

point's of view, it is not regarded as an anomaly.

In the context of the RWS, we will consider three types of anomalies: namely,

non-termination, inconsistency and redundancy. Before we formally define and present

the algorithms for detecting these anomalies, we shall define the terms and concepts that

will be used in the remainder of this chapter.









5.2.1 Simplifying Assumptions

In order to make the verification of event-and-action-oriented rules a tractable

problem, we will first make some simplifying assumptions about this type of rules.

Recall from Chapter 4, the event-and-action-oriented rules defined in the AOM model are

represented in the ETR (event-trigger-rule) constructs. The trigger specification has a set

of triggering events, an optional event history specification, and a structure of triggered

rules. For the current work on verification, we will assume the following:

* There is a single rule in a rule structure.
* The triggered rules are CA (condition-action) rules, not CAA (condition-action-
alternativeAction) rules. Note that a CAA rule can be expressed by two CA rules.

Based on the above assumptions, we have the following definitions for event-and-

action-oriented rules.

5.2.2 Definitions for Event-and-action-oriented Rules:

Definition 5.2.1: A rule set R is a set of event-and-action-oriented rule

specifications under consideration.

Definition 5.2.2: An event-and-action-oriented rule r (from here on, we shall

call it rule for short) is a "condition-action" (CA) rule.

Definition 5.2.3: A rule r is activated if the condition part of the rule evaluates to

true. If the condition evaluates to false, r is deactivated.

Definition 5.2.4 A trigger t specifies a triggering event e and the rule r it

triggers. The rule r is triggered when the event e has been posted.

Definition 5.2.5: A rule r is fired if it is activated and triggered.










5.2.3 Rule Execution Model

When an event el is posted, it will cause all the triggers, which have el as a

triggering event to trigger the corresponding rules. Each triggered rule r is a CA rule. If

the condition part of r is true (i.e., activated), then the action part of the rule is executed

(i.e., fired). In the execution of the action part of a rule, two types of actions can have

impact on rule verification:

* An action may post another event e2, initiating another rule triggering cycle.

* An action may change the state of some objects, which may affect the condition part
of another rule (i.e., activate or de-activate a rule).


5.2.4 Definitions for Objects and Object States:

Example 5.1:
Class Accidentstatistics{
String model;
int accident_probability;
Rulel {
Condition: model= "Model X";
Action: accidentprobability = 0.2;

Rule2 {
Condition: model= "Model X";
Action: accidentprobability = 0.15;

Rule3 {
Condition: model= "Model X";
Action: accidentprobability = 0.1;
}


Definition 5.2.6: The property set P of an object O is a set containing all the

attributes defined in the class c to which O belongs. For example, in Example 5.1 shown

above, the property set of the object Oas of class Accident statistics is P= {model,

accidentprobability}.

Definition 5.2.7: An object state So of object O is an instantiation of the property

setP of object 0. An example object state of object Oas is {"Model X", 0.1}.









Definition 5.2.8: An object execution state SE is a pair (So, RA), where So is the

object state and RA R is a set of activated rules of So. An example object execution

state is ({"ModelX ", 0.1}, {R1, R2, R3}), where Ri, R2 and R3 are activated rules.

5.2.5 Modeling the Side-effects of Methods

One important issue concerning the event-and-action-oriented rule verification is

the invocation of methods in both the condition part and the action part of a rule. The

execution of a method may have side-effects that can cause rule execution anomalies.

For example, events may be posted within a method, operations in a method may change

the states of some objects, or the result of an evaluation of the condition part of a rule

may depend on the data read by a method invoked in the condition part. Thus, for rule

verification purposes, it is important to capture the side-effects of methods that are

invoked by the condition or action of a rule.

Definition 5.2.9: The side-effect of a method m in a class is a tuple {RS, WS, ES,

CS, QS}, where

RS stands for Read Set, the set of attributes in this class or related classes that are

read by m;

WS stands for Write Set, the set of attributes in this or related classes whose

values are changed by m;

ES stands for Event Set, the set of events that are posted by m;

CS stands for Contradictory Set, the set of methods that perform semantically

opposite operations as m. Logically, contradiction is equivalent to ml = NOT(m2) and

m2 = NOT(ml);

QS stands for eQuivalent Set, the set of methods that perform semantically

equivalent operations to m. A method ml is said to be equivalent to method m2 if their









executions will bring an initial object state to the same final object state. We shall use ml

= m2 to denote their semantic equivalence.

We note here that a method of a class may make reference to an object of some

other class. It may read and write some attributes of that object, and/or post events

defined in that class. Our definition of a method side-effect includes the full path of

attributes, methods, and events that may be affected by the method execution. For

example, if method ml in class A reads attribute X in class B, which is in schema S,

S.B.X is included in the read set of method ml.

Method side-effects can be derived automatically by analyzing the method

implementation in a reverse engineering process or defined manually by using a high-

level specification language. Our work is independent of the method used to obtain this

side-effect information. The side-effect information is assumed to be available.


5.3 Non-Termination Detection

Rules may interact in a complex and sometimes unpredictable way. In particular,

there may be cycles in the rule set in which rules trigger and fire each other indefinitely,

causing a non-termination problem [BAR98]. In this section, we will first give the

definition of the non-termination anomaly in the context of an event-and-action-oriented

rule set, followed by an algorithm to detect this type of anomaly.

Definition 5.3.1: An externally-generated event is an event posted by a source

outside of a rule set. For example, an event can be posted by an application program or

within the implementation of a method.









Definition 5.3.2: A rule-generated event is an event posted by rules in a rule set.

For example, an event can be posted in the action part of a rule or in a method invoked in

the condition or action part of a rule.

Definition 5.3.3: A rule set R is non-terminating if there exists a rule r E RA

such that r is fired repeatedly and indefinitely with or without an externally generated

event e being posted.

Recall from Definitions 5.2.5 that a rule is fired only if it is triggered and

activated (i.e., condition part of the rule is true). Thus, in order for a rule to be fired

repeatedly and indefinitely after an event is posted from outside a rule set (e.g., from an

application program), the rule must be triggered repeatedly and indefinitely by some

action within the rule set. Furthermore, the rule must be activated when it is triggered.


Example 5.2:
Class A {
//attribute and methods definitions are omitted.
Event el, e2;
Trigger tl {TriggeringEvent el; RuleStruct: rl;}
Trigger t2{TriggeringEvent e2; RuleStruct: r2;}

Rule rl {Condition: true; Action: post e2;}
Rule r2 {Condition: true; Action: post el;}
}


For example, the rule set in Example 5.2 will not terminate. If el is posted by an

application, trigger tl will trigger the firing of rule rl, which posts event e2. Event e2

will cause trigger t2 to fire rule r2, which in turn posts event el to repeat the entire

triggering process again. Thus, rules rl and r2 will be fired repeated and indefinitely

after el is initially posted. This is also true if e2 is posted by an application.









5.3.1 Algorithm for Non-Termination Detection

In this section, we will present an algorithm to determine whether a given event-

and-action-oriented rule set can terminate. The algorithm is based on the detection of

triggering cycles within a rule set. A triggering cycle may or may not cause a termination

problem. Upon the detection of a triggering cycle, the algorithm determines under what

conditions the trigger cycle may (but not necessarily) cause the non-termination anomaly.

Baralis et al [BAR95, BAR98] proposed the use of Triggering Graphs (TG) and

Activation Graphs (AG) to detect the non-termination anomaly in active databases. We

will extend the idea to support the detection of non-termination for general event-and-

action-oriented rule sets. The basic idea is as follows. Triggering Graphs will be used to

determine triggering cycles in a rule set. Upon the detection of a triggering cycle, we will

use Activation Graphs and De-activation Graphs (DG) to determine if the triggering cycle

may cause the non-termination problem. In particular, if there exists one rule in the

triggering cycle whose condition is false (i.e., de-activated) when triggered, then the

triggering cycle will be broken and thus will not cause the non-termination problem. The

triggering cycle will cause the non-termination problem only if, for every rule in the

cycle, its condition is true (i.e., activated) when triggered.

Definition 5.3.4: Let R be the rule set under consideration, the Triggering Graph

(TG) of R is a directed graph {V, E}, where each node v, E V corresponds to a rule r, E R.

A directed edge E E means that rule r, generates an event that triggers rule rk.

The corresponding trigger is associated with each edge.

Please be noted that the concatenation of the path (including the schema names

and the class name) and the rule name is used to identify a rule. This is also true for










events and triggers. This is because rules across multiple classes or schemas may trigger

each other.


Example 5.3:
Class Supplier{
//Attributes... Methods ...
int credit;
boolean platinum;
booolean discountable;


Knowledge Specification:
EVENT creditPenalty

EVENT untrustableSupplier

EVENT specialService


RULE
CONDITION
ACTION

RULE
CONDITION
ACTION


RULE
CONDITION
ACTION

TRIGGER
TRIGGEREVENT
RULESTRUC

TRIGGER
TRIGGEREVENT
RULESTRUC

TRIGGER
TRIGGEREVENT
EVENTHISTORY
RULESTRUC


R1
credit < 0
discountable:


TYPE EXPLICIT;

TYPE EXPLICIT;

TYPE EXPLICIT;



=false; post untrustableSupplier event; ...


R2
platinum == false;
...; post specialService; ...;


R3
true
...; post creditPenalty; ...;

T1
creditPenalty
R1

T2
untrustableSupplier
R2

T3
specialService
{creditPenalty, untrustableSupplier, specialService}
R3


Definition 5.3.5: A preliminary cycle PC is a sub-graph of TG, which forms a

cycle in TG. A triggering cycle TC is a preliminary cycle, such that the event history of

every trigger associated with the rules in a preliminary cycle PC is satisfied by the events


posted within PC.









Definition 5.3.6: Let R be a rule set, the Activation Graph (AG) of R is a directed

graph { V, E}, where each node v, V corresponds to a rule r, E R. A directed edge
rk> E means that the action of rule r, makes the condition of rule rk true.

Definition 5.3.7: Let R be a rule set, the Deactivation Graph (DG) of R is a

directed graph { V, E}, where each node v, V corresponds to a rule r, E R. A directed

edge E E means that the action of rule r, makes the condition of rule rk false.

Example 5.3 shows several sample events, triggers, and rules. If we use the

pessimistic approach by which we count every possible activation but only those

guaranteed deactivations, the corresponding TG, AG, and DG are shown in Figure 5-2.

We shall explain the pessimistic approach and the optimistic approach in details in

Section 5.3.2. As Figure 5-2 shows, R2 may be triggered by R1 through Trigger T2.

Similarly, R3 by R2 through T3, and R1 by R3 through T1. R3 may be activated by R1,

R2, and R3 because its condition is always true. No rule can guarantee to deactivate

another rule in this rule set.

TG AG DG






Figure 5-2 Examples of TG, AG and DG



Lemma 5.1: A rule set R may not terminate if there is a triggering cycle in the

Triggering Graph. If there is no triggering cycle in the Triggering Graph, the rule set R

will terminate.









[Proof] If there is a cycle in the TG, then the rule set will not terminate if the

action part of every rule in the cycle is executed; i.e., each rule in the cycle is activated

when it is triggered (and thus fired). If there exists one rule such that the condition is not

true (deactivated) when it is triggered, then the triggering cycle will be broken and the

rule set will terminate. Thus, a rule set R may or may not terminate if there is a triggering

cycle in the Triggering Graph.

Next, we will show that if there is no cycle in the TG, the rule set will terminate.

Let us assume, on the contrary, that the rule set will not terminate even without a cycle in

the TG. Let us consider a subgraph SG that is formed of the rules that are involved in the

repeated firing. Note that the in-degree for each node in SG must be at least 1.

Otherwise, any node with an in-degree 0 will not be fired again without another

externally generated event being posted from outside the rule set. Let us start from any

node i in SG and another nodej such that there is an edge from i toj in SG. We trace

backward against the direction of directed edges to a node h, which has an edge from h to

node i. The node h cannot be nodej (i.e., the node(s) that has been traversed before);

otherwise there is a cycle in SG. We repeat this process to reach a new node every time.

Since the number of rules in the rule set is finite, the number of nodes in SG is also finite.

Eventually, the last node I will be reached in this process. If rules in SG are repeatedly

fired, there must be a directed edge from some node n to 1, where n is a node that we have

considered before, thus forming a cycle in SG. This contradicts with the assumption that

"there is no cycle in the TG."









Definition 5.3.8: A rule r is in a triggering cycle tc if it corresponds to a node in

tc.

Definition 5.3.9: When a rule r, is triggered before r, in a triggering cycle, then we

denote the order by r, < r,.

Lemma 5.2: A rule set will terminate if, for each triggering cycle in the TG,

3 r,, rk in DG such that there is an edge from r; to rk and
NOT 3 rj, rk in AG such that there is an edge from r, to rk
where r,, r,, and rk are in the triggering cycle and r, < r, < rk.

In other words, a rule set that contains a triggering cycle will terminate if some

rule (e.g., rk) in the triggering cycle is deactivated by the action of another rule (r1) in the

cycle and no other rule (r,) in the cycle activates it again after the deactivation.

[Proof] If there is an edge in DG from r; to rk, it means that the action of rule r,

will deactivate rule rk. In this case, when rule rk is triggered in the cycle, it will not fire,

thus breaking the triggering cycle. However, the cycle will not be broken if rk is re-

activated by another rule r,, fired after r, but before rk is triggered. But, if there is no such

r, in AG, rk will not be re-activated. Thus, the rule set will terminate.

TG AG DG






Figure 5-3 Examples for Lemma 5.2



The example in Figure 5-3 illustrates Lemma 5.2. In the triggering cycle

consisting of(R1, R2, R3), rule R2 is deactivated by rule R3, as shown in DG. AG









shows that R2 is activated by R1. Since R1 is triggered and fired after R3 in the cycle, its

effect will overwrite the effect of R3. Thus, R2 is activated every time it is triggered.

Consequently, the rule set will not terminate.

Lemma 5.3: A rule set will terminate if, for each triggering cycle TC in a TG,

3 a rule set S, which is a subset of the rules in TC, such that the conjunction of
the conditions of the rules in S is unsatisfiable, and
each of the nodes that correspond to the rules in S has no incoming edge in
AG.
[Proof] If Condition (1) is true, then at least one of the rules in S will not be

activated (i.e., its condition is false) unless some other rule in S activates it (the negation

of Condition (2)). For example, if the condition of r, is "A and the condition of r, is

"NOTA", then one of these rules will be deactivated during the triggering cycle if the

value of A does not change. However, if some rule rk changes the value of A to true

before r, is triggered and another rule rm changes the value of A back to false before r, is

triggered, then the trigger cycle is not broken. Thus, Condition (2) is used to eliminate

that situation. Condition (2) says that none of rules in S will be activated (or re-activated)

by the action of any of the rules in the triggering cycle.



Theorem 5.1: A rule set is guaranteed to terminate if

1. There is no triggering cycle in TG of the rule set. Otherwise, for each triggering
cycle in TG, either
2. 3 r,, rk in DG such that there is an edge from r, to rk and NOT 3 rj, rk in AG such
that there is an edge from rj to rk, where ri, rj, and rk are in the triggering cycle
and ri < rj < rk; or
3. 3 a rule set S, which is a subset of the rules in TC, such that the conjunction of the
conditions of the rules in S is unsatisfiable, and each of the nodes that correspond
to the rules in S has no incoming edge in AG.
is satisfied.









[Proof]

Condition (1): We have shown in Lemma 5.1 that if there is no cycle in TG, then

the rule set will terminate.

Condition (2): We have shown in Lemma 5.2 that under the conditions stated in

Condition (2), the triggering cycle will be broken and the rule set will terminate.

Condition (3): We have shown in Lemma 5.3 that under the conditions stated in

Condition (3), the triggering cycle will be broken and the rule set will terminate.

Since Condition (2) in Theorem 5.1 determines the termination of a rule set by

detecting whether a rule is deactivated by the other rules in a triggering cycle, we call it

Deactivated-Termination Condition (DTC). On the other hand, condition (3) in Theorem

5.1 uses the unsatisfiability of the conditions of rules to decide the termination of a rule

set, we call it Contradictory-Condition-Termination Condition (CCTC).

Based on Theorem 5.1, an algorithm for non-termination detection in a rule set is

given in Algorithm 5.1 (see Figure 5-4). In Step 1, the Triggering Graph for the rule set

is formed based on the event posting relationships among the rules in the rule set under

verification. The event set given in the side-effect description (see Definition 5.2.9) of

each method invoked in the rules will also be used to determine the triggering

relationships. In Step 2 and 3, all the preliminary cycles and triggering cycles in the TG

are determined. If there is no triggering cycle in the TG, the rule set will terminate and

the algorithm ends. Otherwise, it is possible that the rule set will not terminate. The

algorithm continues to Step 4 to form the AG and DG for the rule set. The read and write

sets of the side-effect description of each method invoked in the rules will also be used to

determine the AG and DG. Step 5 tests termination conditions (2) and (3) presented in










Theorem 5.1 to determine whether a particular triggering cycle will cause a problem. If

neither condition can be satisfied, the algorithm will report that the rule set may not

terminate and identify the specific triggering cycle. If all the triggering cycles can satisfy

either condition, the algorithm will report that the rule set will terminate.


Algorithm 5.1:
1. Form the TG based on the event posting relationships among the rules in
the rule set under verification. The side-effect descriptions of the
methods invoked within the rules will also be used to determine the
relationships.
2. Determine all the preliminary cycles in the TG.
3. Determine all the triggering cycles by checking the event history of the
triggers involved in preliminary cycles. If there is no triggering cycle,
report that the rule set will terminate and exit. Otherwise, continue.
4. Form the AG and DG based on the relationships among the conditions
and actions of the rules. Again, the side-effect descriptions of the
methods invoked in the rules will also be used to determine the
relationships.
5. For each cycle in the TG,
Determine whether condition (2) or condition (3) in Theorem 5.1 is
satisfied. If neither condition is satisfied, report that the rule set may
not terminate because of this triggering cycle and quit.
Continue to examine the next cycle.
6. Report that the rule set will terminate.

Figure 5-4 Algorithm 5.1: Non-termination Detection Algorithm



If the event posting relationship is known, the time complexity of forming TG in

Step 1 is O(u+v), where u is the number of rules in the rule set and v is the number of

edges in TG. In Step 2, the time complexity for the triggering cycle detection is O(u+v).

If there are cycles in the rule set, we need to identify all the cycles. The time complexity









for identifying cycles is O(u2)1. The time complexity for Step 3, Step 4, and Step 5 is

O(u+v'), where v' is the number of edges in AG or DG. Thus, if there is no cycle in TG,

the total complexity of this algorithm is O(u+v); otherwise, O(u2).

Let us apply the algorithm to Example 5.3. From the TG, AG and DG shown in

Figure 5-2, we can see that there is a cycle (R1, R2, R3) in the TG. In this case,

Condition (2) in Theorem 5.1 is not satisfied because there is no edge between any of the

three nodes (R1, R2, R3) in DG. Let us assume that the conjunction of the conditions of

the rules (R1, R2, R3) is not unsatisfiable, then Condition (3) is not satisfied. Thus, the

rule set may not terminate.

Let us change the rules in the example by letting the condition of rule R3 to be

"discountable==true." The corresponding TG, AG, and DG are shown in Figure 5-5.

The change results in an edge from node R1 to node R3 in the DG. This means that the

execution of R1 deactivates R3. In this case, Condition (2) in Theorem 5.1 is satisfied.

Thus, the rule set can terminate.

TG AG DG



e' *

Figure 5-5 Revised Examples of TG, AG and DG


If we change the condition of rule R3 to "platinum==true", the TG, AG and DG

will still be similar to the original example, as shown in Figure 5-2. The only difference

is that all the links to R3 in AG are gone. It seems that the rule set is still unable to


SThe time complexity of the identification is O(|u|2) because one rule may be involved in









terminate. However, R2 and R3 have contradictory conditions (i.e., the conjunction of

the conditions ofR2 and R3 is unsatisfiable) and there is no action in the cycle to activate

the rules explicitly (i.e., no incoming edge in AG for R2 or R3). Thus, Condition (3) in

Theorem 5.1 is satisfied. Consequently, the rule set can terminate.

5.3.2 Completeness and Soundness of the Algorithm

As we have shown in Theorem 5.1, the TG, AG and DG can be used to detect the

termination of a rule set. In this section, we will discuss some issues concerning the

construction of these graphs. To construct these graphs, we need to analyze the rule set

under verification to capture the triggering, activation, and deactivation information. In

addition, since our work aims to verify general event-and-action-oriented rules, and the

conditions and actions of the rules may include method invocations, the side-effects of

the methods need to be taken into consideration in the construction of these graphs.

However, in general, the triggering, activation, and deactivation information cannot be

captured deterministically. For example, a rule rl may conditionally post an event el,

which is the triggering event of rule r2. Since the triggering relationship is conditional

and can only be known at runtime, we cannot construct TG without making some

assumptions. This is also true for AG and DG. For example, some action in rule rl may

conditionally change the state of an object, which in turn activates or deactivates the

condition of rule r2. Again, because it is conditional, we cannot construct AG or DG

without making some assumptions.

Two approaches can be taken to deal with the above problem: optimistic approach

andpessimistic approach. In the optimistic approach, we assume the best case and

choose the assumptions that will bias the verification toward termination. In other words,


multiple cycles. The justification is straightforward.









we will ignore all conditional event postings when we form TG. In forming DG, if the

action of one rule conditionally deactivates another rule, we will assume it will. In

forming AG, we ignore all conditional activations.

On the other hand, in the pessimistic approach, we assume the worst case and

choose assumptions that will bias the verification toward non-termination. In forming

TG, we will assume that all the conditional event postings will indeed post the events. In

forming DG, the conditional deactivations are ignored. In forming AG, we assume all

conditional activations.

Definition 5.3.10: The algorithm for non-termination detection is complete if it

detects all the non-termination anomalies in a rule set.

Definition 5.3.11: The algorithm for non-termination detection is sound if every

reported non-termination anomaly turns out to be an anomaly.

The optimistic approach is sound, but not complete. In other words, since the

optimistic approach is a "best case" analysis, it will miss some non-termination

anomalies; however, there will not be any "false positives" in which non-anomalies are

reported as anomalies. The pessimistic approach is complete, but not sound. Since the

pessimistic approach is a "worst case" analysis, it will detect all the non-termination

anomalies; however, the algorithm may return some "false positives".

In conclusion, since the triggering, activation, and deactivation relationships may

be conditional, it is not possible to have a sound and complete detection algorithm. Even

if we model all the conditions in the graphs to determine whether the action of one rule

will activate or deactivate the condition of another rule, there is still a satisfiability

problem; a well-known NP-complete problem.









The practical result of this discussion is that we can bias Algorithm 5.1 to take the

optimistic or pessimistic approach. This allows a Rule Warehouse Administrator (RWA)

to select a proper approach based on the requirement of a specific application. In

Algorithm 5.1, the decision of the RWA will determine what assumptions are made in

forming the TG in Step 1 and the AG and DG in Step 4.


5.4 Inconsistency and Redundancy

5.4.1 Definition of Inconsistency

Informally, a rule base is inconsistent if different activated rules intend to set an

object to different states. Inconsistency can be either conflicting or contradictory.

Conflicting rules will set an object to different object states that are not contradictory;

whereas, contradictory rules will set an object to different object states and these states

are contradictory. Rules 1, 2 and 3 in Example 5.1 are conflicting rules because they

share the same condition; however, their actions set the object to different (but not

contradictory) object states. Rules 1 and 2 in Example 5.4 are contradictory rules. Most

of the current works do not distinguish conflicting and contradictory rules; however, it is

useful to distinguish whether two rules are conflicting or contradictory.

In the context of using the Rule Warehouse System for collaborative problem-

solving, conflicting rules represent different experts' opinions. They are useful

information and should be stored in the Rule Warehouse. If we can define a proper

resolution rule to resolve the conflict, we can realize a resolution scheme "on demand" to

take different experts' opinions into consideration. This concept will be illustrated in

Chapter 6 to demonstrate collaborative problem-solving. On the other hand, it is not

possible to resolve contradictory rules. They must be reconciled at the verification time.









We aim to detect both conflicting and contradictory rules. Before we consider the

algorithms to detect them, let us first define conflicting and contradictory formally.

Definition 5.4.1: A rule set R is inconsistent if and only if there exist object

execution states S, such that the action al of rl and the action a2 of r2 set an object O to

different states Sol and S02, where rl E RA and r2 E RA; RA E R is the set of activated rules

of S; Soi and So2 are object states of O.

Example 5.4:
Class Supplier
{
boolean platinum;
int credit;

Rulel {
Condition: credit > 100;
Action: platinum = true;
}

Rule2{
Condition: credit > 100;
Action: platinum = false;
}


5.4.1.1 Definitions of Contradiction

Definition 5.4.2: The domain D of an attribute A EP is all the legitimate values of

A where P is a set of properties (or attributes) of O.

Definition 5.4.3: A value set Vof an attribute AEP is a subset of D, where D is

the domain of A.

Definition 5.4.4: A value set VI is contradictory with value set V2 if their set

intersection is empty and the union of VI and V2 is the domain D. For example, if VI has

all the integers that are larger than 2 and V2 has all the integers that are less than or equal

to 2, VI and V2 are contradictory. If V2 is changed to be less than or equal to 1, VI and

V2 not contradictory. For a Boolean attribute, if VI is true and V2 is false, then VI and









V2 are contradictory. For an enumerated attribute type, if VI is "male" and V2 is

"female," then VI and V2 are contradictory if the domain is {"male", "female"}.

Definition 5.4.5: Two object states Sol and So2 of an object O are contradictory

if 3 A E P, such that VI and V2 are contradictory. P is the property set of O. VI and V2

are the value sets of attribute A in object states Sol and S02, respectively. For example,

for an object of class Employee, if an object state Sol says that the gender of an employee

is male and S02 says that the gender of the same employee is female, then the two states

are contradictory.

Definition 5.4.6: A rule set R is contradictory if and only if there exist object

execution states S, such that the action al of rl and the action a2 of r2 set an object O to

contradictory states Sol and S02, where rl E RA and r2 E RA.;RA E R is the set of activated

rules of S; Sol and S02 are object states of O.

5.4.1.2 Definition of Conflict

Definition 5.4.7: A rule set R is said to be in conflict if it is inconsistent but not

contradictory.

5.4.2 Definition for Redundancy

There are many types of redundancy anomalies defined in the existing works on

logic rules [WU93a], including subsumed rules, unnecessary-if, syntactical redundancy,

semantic redundancy, etc.

For example, the unnecessary IF anomaly can be defined as follows [NGU87]:

Definition 5.4.8: Two rules contain unnecessary IF conditions if (1) the rules have

the same conclusion, (2) one of the IF conditions in one rule contradicts with an IF

condition of another rule, and (3) all the other IF conditions in the two rules are

equivalent.


















In Example 5.5, the IF condition "B" in RI and "-B" in R2 are unnecessary, and

in a sense, redundant.

The following definition of the subsumption anomaly is taken from [WU93a].

Definition 5.4.9: If two rules have the same consequence but one contains more

restrictive conditions to fire the rule, then it is said that the rule with more restrictive

conditions is subsumed by the rule with less restrictive conditions.

In Example 5.6, rule RI is subsumed by rule R2. Intuitively, if a more restrictive

rule succeeds, the less restrictive rule must also succeed, but not vice versa. The

subsumed rule is not necessary and is redundant.

Although there are many types of redundancy anomalies defined in the existing

work, Wu [WU93a] argued that a more general semantics-based definition is necessary in

order to detect a variety of redundancies. Wu [WU93a] gave a definition of redundancy

based on the semantic properties of logic rules. We will adopt and extend the definition

to incorporate event-and-action-oriented rules.


Example 5.6:
R1: Condition: A B
Action: C

R2: Condition: B
Action: C


Definition 5.4.10: The execution behavior of a set of consistent rules is the

transformation of some objects from their initial object states S, to their final object states


Example 5.5:
R1: Condition: AA B
Action: C
R2: Condition: A A fB
Action: C









Sfby applying these rules. Two sets of rules have the same execution behavior if, given

the same initial object states of some objects, they reach the same final object states of

the same objects.

Definition 5.4.11: A rule set R is redundant if the removal of a rule and/or part of

a rule from the set will not change its execution behavior.

Rule set redundancies can be generally divided into two categories. The first

category of redundancies can be removed by reducing the number of rules in the rule set

without changing its execution behavior. In Example 5.6, if we remove R1, the execution

behavior of the rule set will not be changed. In Example 5.5, we can rewrite the two

rules into one rule (Condition: A, Action: C) without changing the execution behavior.

The second category of redundancies can be eliminated by removing a part of a rule in

the rule set without changing its execution behavior. In Example 5.7, it is easy to show

that if we refine RI to be (Condition: A, Action: C), the execution behavior of the

resulting rule set will not be changed.


Example 5.7:
R1: Condition: A B
Action: C
R2: Condition: -B
Action: C


5.4.3 Algorithm for Inconsistency and Redundancy Detection

In this section, we will discuss our objective for detecting rule set inconsistency

and redundancy for event-and-action-oriented rules in a Rule Warehouse System and

present our investigation results.

Our objective for detecting inconsistency (or redundancy) is to answer the

following three questions concerning a rule set: (1) Is the rule set inconsistent (or









redundant)? (2) If the rule set is inconsistent (or redundant), which portion of the rule set

is causing the problem? (3) If the rule set is inconsistent (or redundant), under what

situation (i.e., what object state) will the rule set cause a problem? The answer to

Question (1) will inform the Rule Warehouse Administrator (RWA) whether such

anomalies exist in the Rule Warehouse. If so, the answer to Question (2) will help the

RWA locate and eliminate the problem. If the problem cannot be eliminated, the answer

to Question (3) will give the RWA the information concerning what object state can

potentially lead to the anomaly.

Our approach to detect both inconsistency and redundancy anomalies is the same.

Thus, we will describe them together. There are many existing works (i.e., good

algorithms) for the detection of inconsistency and redundancy in a set of logic rules

[ROS97a, WU93b, WU93a]. We observe that both inconsistency and redundancy

problems for event-and-action-oriented rules can be reduced to their corresponding

problems for logic rules. Thus, the existing results obtained for logic rules can be applied

with some modifications to account for the added features of event-and-action-oriented

rules: i.e., the existence of events and the invocation of methods in the condition and

action parts of a rule.

Recall from Section 5.2 the execution semantics of an event-and-action-oriented

rule. If an event el is posted, and if el is one of the triggering events of a rule rl, then

the condition of the rule rl will be evaluated. If the condition evaluates to true, the action

of rl will be performed. Note that only those rules that may be triggered by the same

event (either directly or indirectly) need to be verified for inconsistency and redundancy.

In Example 5.8, Rule] and Rule2 are contradictory if they are put in the context of logic









rule verification; however, in the context of event-and-action-oriented rule verification,

Rule] can only be triggered by el, whereas Rule2 only by e2. In this case it is not

possible for Rule 1 and Rule 2 to be triggered together. Thus, they are not inconsistent in

the context of event-and-action-oriented rule verification.


Example 5.8:
Class Accidentstatistics
String model;
int accidentprobability;
Event el, e2;

Trigger tl {
TRIGGERINGEVENT el;
RULESTRUCT: Rule 1;
}

Trigger t2 {
TRIGGERINGEVENT e2;
RULESTRUCT: Rule2;
}

Rulel {
Condition: model = Ml;
Action: accidentprobability = 0.2;


Rule2 {
Condition: model = Ml;
Action: accidentprobability != 0.2;




Since only those rules that can be triggered by the same event need to be verified

for inconsistency and redundancy, we can partition the rule set based on the triggering

events for the purpose of verification. Each partition contains rules that can be triggered

by the same event either directly or indirectly. Also, each rule in a partition is a CA

(condition-action) rule, which can be represented by the logic expression C-A (reads "C









implies A"). Both C and A may contain method invocations. Most of the existing logic

rule verification algorithms cannot handle methods in C and A. They need to be

extended to deal with the side-effects of methods. We shall revisit this issue in Section

5.5.

Definition 5.4.12: If a rule rl is triggered by an event es, we say rl is triggered by

es directly. We say r2 is triggered by es indirectly if r2 is triggered by an event e, which

is posted by a rule triggered directly or indirectly by es.


Algorithm 5.2:
1. Get the list of triggering events in the rule set.
2. Partition the rules into groups based on the triggering events. If one rule
has multiple triggering events, it will be put into multiple groups.
3. Rewrite the conditions and actions of the rules to include the side effect of
methods.
4. Combine the groups g and g if the action of a rule in g, may post the event
requiredfor group g1. This is to take care of the indirect triggering.
5. Verify the CA rule sets in each group using the available logic-based
inconsistency detection algmritlhi EF


Figure 5-6 Algorithm 5.2: Partition Algorithm



Algorithm 5.2 (see Figure 5-6) performs two main functions: (1) it uses triggering

events (direct and indirect) to partition the rule set so that rules associated with a

triggering event are verified together, and (2) it reduces an inconsistency or redundancy

problem for event-and-action-oriented rules into the corresponding problem for logic

rules so that some existing algorithm Tcan be used. Step 1 gets a list of all the triggering

events in the rule set. Step 2 partitions the rules based on triggering events (direct

triggering). Step 3 considers the side-effects of methods if methods are involved. Step 4

combines the rules that may be indirectly triggered into the same group. Step 5 applies









the existing algorithm for logic rules to finish the detection of inconsistency/contradiction

and redundancy. After the partition and reduction process, the rules in each group are

verified for the appropriate type of anomalies using F. Note that F is some existing

algorithm for detecting inconsistency or redundancy anomalies for logic rules; however,

none of the existing algorithms can (1) distinguish inconsistency and contradiction and

(2) handle method invocations in the condition and consequence part of a rule. We need

to tailor the existing algorithm to serve the new requirements of a rule warehouse system.


5.5 Extension to an Existing Logic Rule Verification Algorithm

In the previous section, we assume that F in Algorithm 5.2 is an existing

algorithm for detecting inconsistency or redundancy anomalies for logic rules. The

algorithm presented in [WU93a] is an example of such an algorithm. The algorithm

detects inconsistencies and redundancies in a set of logic rules by using a mechanical

theorem-proving technique. In the algorithm, a level-saturation resolution is performed if

a certain condition is satisfied. The results of resolution are used to determine the

redundancy and inconsistency in a rule set. In the previous subsection, we have

introduced a reduction algorithm to partition rules into groups based on events. In each

group, there are many CA rules. In this subsection, we will show how to tailor [WU93a]

to verify the CA rules in each group.

5.5.1 Inconsistency Detection

For our research, we face two additional challenges in the development of an

inconsistency detection algorithm. One is to distinguish two types of anomalies:

contradictory rules and conflicting rules. The other is the possible use of method

invocations in CA rules, both on the left hand side (LHS) and the right hand side (RHS).









We have pointed out the importance of distinguishing inconsistency and contradiction

and defined them formally in Section 5.4.1. We will review the resolution-based

inconsistency detection algorithm presented in [WU93a] in Section 5.5.1.1. Following

that, we will present our extension to the existing algorithm to detect contradictions and

inconsistencies in Sections 5.5.1.2 and 5.5.1.3, respectively. Please note that it is not

necessary for us to present a separate algorithm for detecting conflicting rules because,

under a condition C, if the rule set is inconsistent but not contradictory, the rule set is

considered to be conflicting under condition C. In Section 5.5.1.4, we will show our

solution to method invocation in rules. In Section 5.5.1.5, we will give our comments on

considering these two challenges together.

5.5.1.1 Introduction to a Resolution-based Inconsistency Detection Algorithm

The resolution principle [ROB65] is an inference rule that is suitable for machine-

oriented deductions. We assume that the reader has some basic understanding of

automatic theorem-proving [CHA73, MAN74]. [CHA73] provides details about the

resolution principle and the linear resolution (including input resolution and unit

resolution); and [LL087] elaborates SLD-resolution.

To detect inconsistency, [WU93a] proves a theorem about the relationship

between the inconsistency of a rule base and the unsatisfiability in formal logic. The

definition of inconsistency given in [WU93a] is slightly different than ours because it

does not distinguish between conflict and contradiction. A rule base is inconsistent with

respect to some input facts {a} if and only if this set of rules together with the input facts

{a} comprise an unsatisfiable set of clauses. Based on the theorem presented in

[WU93a], Algorithm 5.3 (see Figure 5-7) is proposed to detect the inconsistency in a rule

set in [WU93a].









Using this algorithm, a PDS and a potentially contradiction-causing input set can

be obtained. If an empty clause is generated in step 3, the rule set is inconsistent by

itself; otherwise, if the potentially contradiction-causing set is empty, the rule base is

consistent. Each clause in the PDS represents a potential contradiction which can be

deduced from the set of rules {r}. The resolution complement formula corresponding to

a clause in the PDS represents the input fact combination that will cause the

contradiction. By looking into the list of parent clauses that derives a clause in the PDS,

we can determine which rules in the {rj contribute to the contradiction.


Algorithm 5.3: Original Inconsistency Detection Algorithm
The input rules are written into clausal form.
A partial detection set (PDS) is a set of clauses which are the deduced intermediate
results, i.e., the resolvents of other parent clauses. The rule verification
algriitiin for detecting the inconsistency of a set of rules {r} is as follows:
1. PDS = .
2. Perform level-saturation resolution to the set of rules {r} using the tautology-
and subsumption deletion strategy until no further resolvent can be generated;
at the same time, record the list of the parent clauses for each resolvent.
3. If an empty clause is generated, then {r} is inconsistent by itself even without
input, stop; ohl rl i / do the next step.
4. Put all the unit clauses whose literals appear in the LHS of some rules in {r}
into the PDS.
5. Put every multi-literal clause that satisfies the following conditions into the PDS
as well:
a. all literals in the clause appear in the LHS of some rules in {r};
b. the clause is not subsumed by any clause kept in the PDS.
6. For each clause in the PDS, construct a "resolution complement formula, "
which is a formula in conjunctive form and can resolve to an empty clause with
the clause selected from the PDS. Put all the resolution complement formulas
into a set called "potentially inconsistency-causing input set. "


Figure 5-7 Algorithm 5.3: Original Inconsistency Detection Algorithm









The conditions that the algorithm performs resolution can be abstracted and

justified as follows. To simplify the explanation, w.l.o.g., we assume that there is one

predicate in both LHS and RHS of each rule.

* The two LHSs are contradictory predicates. That is to say, one and only one of the
two conditions is true. Consequently, either RHSri or RHSr2 is correct; i.e., RHSri u
RHSr2 is true, which is exactly the result of performing a resolution between rl and
r2.
* The two RHSs are contradictory predicates. That is to say, one and only one of
the RHSs is true. Since RHS is the logic result of LHSs, we know that one LHS is
true; i.e., -LHSri u -LHSr2 is true, which is exactly the result of performing a
resolution between rl and r2.
* The LHS of one rule and the RHS of another rule are the same. W.l.o.g, we
consider the case that the LHS of rule rl and the RHS of rule r2 are the same.
Consequently, we have LHSr2 RHSr2 LHSri RHSri. Written in a clausal
form, -LHSr2 u RHSri, which is exactly the result of performing a resolution.

Example 5.9 is given in [WU93a] to illustrate the procedure to check the

inconsistency in a rule base consisting of propositions.

From the potentially contradiction-causing input set, we know that when the input

fact A or B is given, some contradiction will be deduced from the set of rules. We can

trace back to see which rules are involved to deduce the contradiction. The first clause in

PDS is -A, i.e., resolvent (7) in the partial deduction. Tracing back the partial deduction,

we know that

(7) <- (1) + (6) <- (1) + (2) + (3)

where "*-" is read as "resolved from." Thus, we see that when fact A is given, a

contradiction can be deduced using all these rules in the rule base. Let us verify this

result: when the fact A is given, the following facts will be deduced.

-A given input fact

-4B from (1)









4-C from (2)

4-,B from (3)

Therefore, we have deduced the contradiction B and -,B.

Examples 5.9:
(1). A B
(2). B C
(3). C- -B

1. PDS = 0
2. Perform level-saturation resolution
(1). -A uB
(2). -B uC
(3). -Cu -,B SO

(4). -A uC (1)+(2)
(5). -A u-,C (1)+(3)
(6). -B (2) +(3) S'

(7). -A (1)+(6)
-A -B (2) + (5), subsumed by (7)
u -B (3) + (4), subsumed by (7)
-A (4) + (5), subsumed by (7) S2

Terminated (Here, Si represents the ith level of the resolutions.).

3. No empty clause is generated, so go to next step.
4. PDS = {~A, B}
5. No multi-literal clause can be put into PDS; therefore, PDS = {~A, ~B}
6. Potentially contradiction-causing input set = {A, B}


The second clause in the PDS is -,B, i.e., resolvent (6) in the partial deduction.

Tracing back the partial deduction, we have

(6) (2) + (3)

It shows that when the fact B is given, a contradiction can be deduced from only

the last two rules of the rule base. This result is verified as follows:

B given input fact









C from (2)

-,B from (3)

Therefore, the contradiction, B and --B, has been deduced. In summary, we have

proven that the rule base {A4-B, B-1 C, C -*-B} is inconsistent with respect to the fact

A; moreover, its subset {B-4C, C- --B} is inconsistent with respect to the fact B.

5.5.1.2 Inconsistency Detection

Inconsistency includes both conflicting and contradiction. To detect

inconsistency, a resolution should be performed for any two predicates if they are

unsatisfiable. We will perform a resolution for "Y = 9" and "Y = 7" because they are

unsatisfiable, whereas, we do not perform a resolution for them in contradiction

detection, which we will explain later. This can be justified as follows. In a

contradiction detection, whenever two predicates are contradictory, there is a chance for

us to get contradictory facts through derivation. In the inconsistency detection, whenever

two predicates are unsatisfiable, there is a chance for us to get conflicting facts through

derivation.

We perform a subsumption simplification if two predicates are on the same

attribute and they are in the same clause generated by the resolution, given that one

subsumed another. For example, we can simplify -(Y = 9) u(Y = 7) to -(Y = 9)

because for any predicate p, if p and (-(Y=9) u(Y=7)) are unsatisfiable, p is

unsatisfiable with (-(Y=9)) also. The simplification will not change the condition to

perform a resolution, thus the verification result will not be changed.

Example 5.10 shows an example by applying our extensions to Algorithm 5.3.

The conclusion is that the rule set may be inconsistent with the input set {Y=9} or









{X=3}. This can be verified as follows: Given {Y=9}, rule (2) and (3) will derive

{Y=7}, which is inconsistent with the input fact {Y=9}. Given {X=3}, rule (1) will get

{Y=9}; whereas, rule (2) and (3) will derive {Y=7}, which is inconsistent with the

derivation of rule (1).


Example 5.10:
(1). X 3 -Y =9
(2). Y 9->C 5
(3). C 5 --> Y = 7

1. PDS =
2. Perform level-saturation resolution.
(1). -(X 3) u (Y 9)
(2). -(Y 9) (C 5)
(3).-(C = 5) u(Y 7)

(4). -,(X 3) u(C 5) (1)
(5). -(X 3) u-,(C 5) (1)
(6). -(Y = 9) u (Y 7) (2)
-(Y =9)

(7). -(X 3) (1)
(8). -(Y 9) u -(X 3) (2)
(9). (Y 7) -(X = 3) (3)
(10). -,(X 3) (4)


(sumsumption simplification)
S1


subsumed by (7)
subsumed by (7)
subsumed by (7) S2


Terminated

3. No empty clause is generated, so go to next step.
4. PDS = --(Y 9), -(X 3)}.
5. No multi-literal clause can be put into PDS; therefore, PDS = {-,(Y 9), -(X = 3)}.
6. Potentially inconsistency-causing input set Y 9, X 3}.


5.5.1.3 Contradiction Detection

We will extend the existing inconsistency detection algorithm in two ways to

detect contradiction in a rule set as defined in Definition 5.4.6. First of all, we perform a









resolution only when two predicates are contradictory. For example, we will perform a

resolution for predicates "Y = 9" and "Y != 9" whereas we will not perform a resolution

for predicates "Y = 9" and "Y = 7." Recall that we perform a resolution for these

predicates in the inconsistency detection. Meanwhile, if one predicate subsumes another

predicate, we will not perform subsumption simplification to keep every possibility of

performing a resolution in the process of resolution. If we simplified AuB to A where A

subsumes B, if -B is available in a further resolution, we will not perform a resolution

because A is not the compliment of- B. On the other hand, if we keep it to AuB, when

we see -B, we know we should perform a resolution because of B and --B. For example,

if we have -(Y=9) u(Y=7), in the existing work, it will be simplified to -(Y=9). In our

work, we leave it unchanged because we do not know whether "Y=9" or "-(Y=7)" will

be used in the future resolution. As shown in Example 5.11, the rules are not

contradictory. However, as we have shown in example 5 10, these rules are inconsistent

when {Y=9} or {X=3} is given. Consequently, they are in conflict when {Y=9} or

{X=3} is given.

5.5.1.4 Method Invocation Support

In a P-Q logic rule, LHS (P part) specifies that we will check the specified

condition against the current object state; whereas, RHS (Q part) specifies that the values

of the attributes involved in Q should be reset to the values specified in Q. That is to say,

we need to read the attributes in P and write the attributes in Q. Because a method may

have its read set and write set if method invocation is involved, it is possible for both

LHS and RHS to have read and write operations. With the use of method invocation in a

predicate, it is very difficult, if possible, to determine whether a predicate is contradictory









with another predicate. However, if the read or write operations of the predicates satisfy

certain conditions, we know that the predicates may be contradictory. To deal with this

problem, we define a read set (RS) and a write set (WS) for each rule. Then, we will

extend Algorithm 5.3 by changing the conditions to perform a resolution based on the

intersection of the RSs and WSs of the rules in a rule set.


Example 5.11:
(1). X 3 -Y =9
(2). Y 9->C 5
(3).C 5- Y =7

1. PDS =
2. Perform level-saturation resolution.
(1). -(X 3) u (Y 9)
(2). -(Y = 9) u (C 5)
(3).-(C = 5) u(Y 7)

(4). -(X = 3) u (C 5)
(5). -(Y 9) u(Y 7)

(6). -(X = 3) u (Y 7)
(7).(Y 7) u-(X = 3)
Terminated


(2)
(3)

(5)
(4), subsumed by (6)


No empty clause is generated
No clause to be put into PDS.
No multi-literal clause can be put into PDS; therefore, PDS = 0
So the rule set is not contradictory.


Definition 5.5.1: The read set (RS) for a predicate a is the set of attributes read by

a, denoted by RS (a). The read set (RS) of rule r, denoted by RS(r), is defined as RS

(r.LHS); i.e., the read set of the LHS of rule r.

Definition 5.5.2: The write set (WS) for a predicate a is the set of attributes

written by a, denoted by WS (a). The write set (WS) of rule r, denoted by WS(r), is









defined as WS (r.LHS) u WS (r.RHS); i.e., the union of the write sets of the LHS and

RHS of rule r.

With the above definitions, we can further extend Algorithm 5.3 (see Figure 5-7)

to verify a rule set that contains rules with methods in their conditions and actions. We

can again apply the theorem proofing approach used in Algorithm 5.3 to attack the

problem by changing the condition of performing a resolution. As we have shown before

in contradiction detection, a rule verifier would perform a resolution when two predicates

are contradictory. Whereas, in the inconsistency detection, the verifier would perform a

resolution when two predicates are unsatisfiable. In this case, the intersection of the RSs

and WSs of rules will be used to decide whether we should perform a resolution.

Specifically, we perform a resolution on rule RI and R2 when

1. RS (R1) n RS (R2) 0 or

2. WS (R1) n WS (R2) 0 or

3. RS (R1) n WS (R2) 0 or

4. RS (R2) n WS (R1) 0

The given conditions can be justified as follows. For condition (1), if RS (R1) n

RS (R2) # 0, based on Definition 5.5.1, we have RS(R1.LHS) n RS (R2.LHS) # 0. That

is to say, the LHSs of R1 and R2 may be evaluated based on some common attributes. It

is possible that these two LHSs are contradictory. If that is the case, at least one of the

RHSs of these two rules will be true. We therefore should perform a resolution because

of this nonempty intersection. The other three cases can be justified in the same manner.

Cases 1-3 in Example 5.12 show the above four conditions. In Case 1, since RS

(R1 ) n RS (R2) = {A} # 0, it is possible for both conditions to be true. Consequently, it










is possible for both consequences to be true. In Case 2, since WS (R1) n WS (R2) = {B}

# 0, it is possible for the two consequences to be contradictory, which leads us to say

that at least one of the conditions is false. In Case 3, WS (R1) n RS (R2) = {B} 0, the

consequence of R1 makes the condition of R2 true. This makes a derivation possible.

Thus, we should perform a resolution for these two rules.


Example 5.12:
Assume the following read set and write set informationfor the following methods:
For methodml O, RS= [A), WS = {B)
For method m2), RS={C), WS = {B)
For method m3O, RS = {B), WS = {E)


Case 1:
Rule R1: ml() > 0 consequences
Rule R2: A < 5 consequence
Since RS (R1) n RS (R2) = {A} 0 we willperform a resolution because ofR1 andR2.


Case 2:
Rule R:X 0 ml)O;
Rule R2: y < 0 m2);
Since WS (Ri) n WS (R2) = {B} 0 we willperform a resolution because ofR1 andR2.


Case 3:
RuleRl:X> 0 ml)O;
Rule R2: m3 ()> 0 Y 5;
Since WS (RI) nRS (R2) ={B} 0, we willperform a resolution because of them.


Case 4:
Rule R1: A = 5 -X= 9;
RuleR2: Y = 7 ml);
A lii, ,gih RS (RHSR) n RS (RI) = {A} # 0, we will not perform a resolution because the
read operation in the RHS ofa rule will not contribute to any derivation.









The reader may have noticed that the read set of a rule is defined as the read set of

its LHS. We leave out the read set of its RHS intentionally because when the RS of the

RHS intersects with the RS or WS of another rule, we cannot draw any conclusion from

it. This is shown in Case 4 in Example 5.12. Although RS (RHSm) n RS (R1) = {A}

0, we only know that the RHS of rule R2 reads A and generates a new result for B,

which does not affect the condition of rule R1. No derivation is possible because of these

two rules. For this reason, we should not perform a resolution for them.

5.5.1.5 Putting Them Together

We call a predicate without methods to be a primitive predicate. For primitive

predicates, an automated rule verifier will have enough information to judge the

contradiction and unsatisfiability relationship between two predicates. In the

inconsistency detection, it will check the unsatisfiability of predicates to decide whether

to perform a resolution or not; whereas, in the contradiction detection, the contradiction

of predicates are used. If methods are involved, it cannot achieve such a fine

determination. It will have to make the decision based on the identified four types of

intersections of the RSs and WSs of the rules being considered. Given an intersection,

the verifier can only say that it is possible for the corresponding rules to produce a

contradiction or an inconsistency; however, it does not know for sure. The best it can do

is to report the potential problem in both contradiction and inconsistency detections.

5.5.2 Redundancy Detection

[WU93a] also proves that the deductive behavior of a set of rules will not change

if(1) a subsumed rule is removed from the set, or (2) a rule in the set is replaced by its

subsuming rule that is derivable from the set of rules. Case (1) describes the situation









when some redundancy exists in a set of rules: a rule in the set is subsumed by another

rule in the same set. Whereas, case (2) says that the redundancy exists when a rule in the

set can be subsumed by a derived rule. Algorithm 5.4 (see Figure 5-8) is presented to

detect these two cases.


Algorithm 5.4: Redundancy Detection

1. Perform deductions based on the level-saturation resolution on a given set of
rules S.

2. If a clause r' in S is subsumed by another clause ri in S, delete the subsumed
clause r'.

3. If a clause r' in S is subsumed by a clause deducedfrom a subset S' of S, and S'
includes r', then replace r' with the deduced clause. If a clause r' in S in subsumed
by a clause deduced from a subset S' of S, and S' does not include r', then delete r'
(i.e., delete derivable clauses).


Figure 5-8 Algorithm 5.4: Redundancy Detection Algorithm



This algorithm handles different types of redundancies in the literature uniformly.

[WU93a] has several examples to show how "Subsumed rules," "Unnecessary IF

conditions" and other forms of redundancy are handled by this algorithm. The readers

are referred to [WU93a].


5.6 Chapter Summary

In this chapter, we have formally defined three types of anomalies and presented

an integrated approach to detect them in a rule set. The verification process first converts

all types of rules into an event-and-action-oriented representation. An algorithm is then

applied on the set of transformed rules to detect non-termination conditions. Next, the









same set of rules is partitioned based on their associated events before applying

algorithms on each partitioned subset to detect inconsistencies and redundancies. These

algorithms take into consideration the side-effects of methods that can be called in rules.

We need to point out that the resolution-based detection algorithms used to detect

inconsistencies, contradictions, and redundancies are conservative algorithms. In our

verification process, rules are partitioned into different groups based on their triggering

relationship. After the partitioning, the triggering relationship among these rules in the

same partitioned group is ignored in the resolution-based detection algorithms, which

regard rules are unordered. For that reason, more resolutions may be performed than

necessary if the order of rules is taken into consideration. Consequently, the verification

algorithms may report some possible anomalies that do not really exist.














CHAPTER 6
SYSTEM DESIGN AND IMPLEMENTATION

This chapter presents the design and implementation of the Rule Warehouse

System (RWS) using the methodologies and algorithms presented in the previous

chapters. To increase the system's portability, Java is used as the programming language.

In addition, to render the RWS services accessible through the Internet without client

software installation and configuration, Web programming techniques (e.g., Applet and

Servlet) are used in our implementation. This chapter proceeds as follows. Section 6.1

focuses on the implementation of the Rule Warehouse Manager. Section 6.2 describes

the implementation of the rule verifier.


6.1 Rule Warehouse Manager

Figure 6-1 shows the component structure of RWS. At the front-end, we have a

Rule Warehouse Interface (RWI), a Knowledge Definer (KD), and a Rule Verifier

Interface (RVI). The Rule Warehouse Manager (RWM), Rule Verifier, a MetaData

Manager (MDM), and a Persistent Object Manager (POM) are at the back end.

Logically, RWI, KD, RVI, RWM, MDM, and POM work together to provide the

functions that are defined for the Rule Warehouse Manager in Chapter 3. We shall

explain the components in Figure 6-1 from bottom to top.

MDM is responsible for the management of the integrated schema and the

knowledge specification associated with each of them. It is also responsible for the

persistence of the metadata and the knowledge. MDM interacts with the database using









JDBC. In our implementation, a free relational database provided by Cloudscape

[CLO01] is used for storage. A Persistent Object Manager (POM) is implemented to

provide JDBC libraries for Cloudscape. Shenoy explained the design and

implementation of MDM and POM in detail in her thesis [SHE01].


Us r User






Rule Warehouse ReIuest
System esult






Figure 6-1 Rule Warehouse System Component Diagram



RWM is a set of servlets. It accepts requests from RWI, KD, and RVI; and

interacts with RV and MDM to serve the requests. The Rule Verifier verifies the input

rules and returns the verification result to RWM. This will be explained in detail in

Section 6.2.

RWI is implemented as an RMI server. It provides a set of APIs to allow the

applications to access the services provided by the warehouse. It allows the adapters to

import rules into or export from the warehouse. The applications can also use the rule

verification service by passing a rule set or a schema name. If a rule set is passed, the

verifier will be invoked to verify the rules, and it returns the results. If a schema name is









84




given, the verifier first retrieves the knowledge specification associated with the given



schema name instead, followed by the same actions as the first approach.


* pIl ,illhl'fll,"
OI 111:11C1 ic


:i 1 (l






:,.,(I." [ 1 1,













,r: ** .l I I 1 [I .l


~~~~ ~~)~


;~I~~~~ ~ ~
.~. ~~.~~.Y.~ i.
~~ ~

~~,





I ~ ; ~ ~I~


~II


Ir'~~ "*'~~ '"v
:" '
'"'r' II~rl.
~.~




~'i'i~'~' '~''''~'' ~' ~'~:

~r ~ "' "'~


Figure 6-2 Rule Verification Graphical User Interface






KD offers a graphical user interface (GUI) for the user to monitor the rules in the


warehouse, define new rules, and invoke an interactive verification interface. KD


retrieves the metadata information from MDM through RWM and attaches the defined


events, triggers, rules, and constraints to the specified class or schema, and stores them


back to the database. All the defined knowledge can be viewed through the browser. KD


comes with an administration application that permits the user to manipulate constraints


and event-and-action-oriented rules using a web-based GUI. It is implemented as a Java


applet that runs in a Java-enabled web browser. KD is an extension to a thesis by Uttam









K. Parui [PAR99]. Since side effects of methods are required for verification purposes,

the GUIs presented in [PAR99] are extended to allow the definition of these side effects.

RVI, an interactive user interface, is provided for the user or warehouse manager

to verify the knowledge stored in the warehouse. It is implemented as an Applet (see

Figure 6-2). A list of authorized classes is obtained from MDM and listed for selection

after a user logs in. The knowledge specification for the selected class can be retrieved

from the database through MDM and RWM. It is displayed on the left pane in the applet.

Four buttons are provided to trigger the detection of non-termination, inconsistency,

contradiction, and redundancy anomalies. The verification results and some key

information about the verification procedures are displayed on the right pane.


6.2 Rule Verifier

The Rule Verifier (RV) is implemented as a class named Verifier. It verifies the

given rule set and returns the result. It receives two parameters. One is an object of

KnowledgeSpec, which contains the rules to be verified. The other is a flag, which

indicates whether the optimistic or pessimistic approach will be used in the non-

termination detection.

A KnowledgeSpec object consists of the lists of attributes, methods, events,

triggers, event-and-action-oriented rules, and constraints associated with the given class.

The side effects of methods; the read set and write set of event-and-action-oriented rules;

and constraints are included as well.

Upon receiving the input KnowledgeSpec object, the Verifier converts all types of

rules into an event-and-action-oriented representation using the pseudo-code shown in

Figure 6-3. An algorithm is then applied on the set of transformed rules to detect non-










termination conditions. Next, the same set of rules is partitioned based on their

associated events before applying algorithms on each partitioned subset to detect

inconsistencies and redundancies.


//Purpose: Transform constraints into event-and-action-oriented rules.
//Input: A knowledge specification
//Output: A transformed knowledge specification

for each constraint c in the knowledge specification{
//Find the attributes to work on.
define an attrList al to contain the attributes to work on for c;
put every attribute involved in c into al;

//Introduce the explicit events if needed.
for (each attribute Xin al)
if ( NOT exists afterSetX event)
add event afterSetX into the event set for the object being evaluated;

//Transform the constraints into event-and-action-oriented rules.
Transform c into an event-and-action-oriented rule newC by letting the
LHS as the condition of the new rule and the RHS as the action;

Define a trigger to link the events and the rule newC by setting the
triggering event to be the combination of all the events associated with the
attributes in al, event history to be true, and the rule structure to be a
single rule newC;



Figure 6-3 Logic Rule Transformation Pseudo-code



A parser is used to parse the condition and action of an event-and-action-oriented

rule, mainly for the unsatisfaction checking of two predicates, which is needed for both

non-termination and contradiction/inconsistency detections. Arbitrary constraint

unsatisfaction checking is an NP-complete problem. We detect unsatisfaction of two

predicates by detecting conflicts on the same attribute. For example, predicates "salary >

50K" and "salary < 40K" are unsatisfiable. The parser is used to parse rules' conditions









and/or actions. If two predicates are on the same attribute and each of them is in the form

of A B, where A and B are variables, which have integer or boolean values, and

presents =, !=, ==, >, >= < -, -, +, or +=

6.2.1 Non-Termination

Based on Algorithm 5.1, there are four key steps in the non-termination detection

algorithm:

* Form the Triggering Graph (TG) of a rule set
* Detect the Preliminary Cycles (PCs) and Triggering Cycles(TCs) in the TG
* Form the Activation Graph (AG) and De-activation Graph (DG) for the rule set
* Detect the conditions under which the rule set may not terminate

We shall explain the implementation for these four steps in detail in this section.

6.2.1.1 Triggering Graph Formation

To form TG, first of all, the condition and action of each rule r are analyzed to

identify all the events, which may be posted by r. The side effects of the methods

invoked by the condition or action of r are considered as well. Since a method may

invoke another method, this process runs recursively until all the methods that may be

invoked are considered.

As we pointed out in Chapter 5, the events to be posted by the condition and

action of a rule cannot be determined statically. A pessimistic or optimistic approach can

be applied. In the pessimistic approach, all the events that may be posted are considered;

whereas, in the optimistic approach, only those guaranteed postings are assumed.

This list of events is compared with the triggering events of the triggers. If one of

them is among the triggering events of a trigger t, rule r may trigger t. Then r is

associated with t. The combination of r and t becomes a node n in the triggering graph.









If there exists a node m, such that the rule associated with m belongs to the rules defined

in the rule structure of t, there is an edge from n to m in TG.

6.2.1.2 Preliminary Cycles and Triggering Cycles Detection

It is straightforward to detect the preliminary cycles in a TG by using a Depth

First Search (DFS) algorithm. All the preliminary cycles are identified first. Then they

are checked one by one to identify the triggering cycles in the TG by considering the

event history (EH) specifications of the triggers in each preliminary cycle. The following

steps are used to determine whether a given preliminary cycle pc is a triggering cycle.

* Start from any element inpc; get the list of events posted by the rules in the PC.
* Verify whether the EH requirements for each trigger inpc is satisfied by comparing
the EH requirement and the list of events obtained in step 1. If the EH of every
trigger inpc is satisfied, thenpc is a TC.

6.2.1.3 Activation and Deactivation Graph Formation

If there are triggering cycles in the TG, we need to consider the AG and DG to

determine if the input rule set can terminate. When forming the AG and DG, the

relationship between the action of one rule and the condition of another rule is

considered. Pair wise comparison is performed for each pair of rules; and corresponding

activation or deactivation relationship is determined and added to the AG and DG.

Again, depending on the approach (optimistic or pessimistic) being used, the

same condition and action can lead to a different conclusion. For example, if the

condition of rule rl is "price > 500" and the action of rule r2 is "price-=10" in the

pessimistic approach, we will consider there is an activation relationship from r2 to rl;

whereas, in the optimistic approach, a deactivation relationship from r2 to rl is assumed

because it is possible for rl to be deactivated by the action of r2.










6.2.1.4 Non-termination Detection


//Purpose: To check if deactivated-terminate condition holds for
// a triggering cycle.
//Input: A triggering cycle
//Output: A flag indicates if DTC holds or not.

//assume the rules involved in this cycle are in a Vector ruleList.

boolean flag[]; //indicating the (de)activation status for the rules.
Initialize every elements in flag[] to be true.

//Keep tracking of the last (de)activation to each rule.
for (int i=0; i < ruleList.size0; i++)
{
if (there is an edge in AG from the current rule to another rule j)
flag[j] = true;
if (there is an edge in DG from the current rule to another rule j)
flag[j] = false;
I

for (int i=0; i < ruleList.size0; i++)

if (! flag[i] ) return true;
I

Return false;


Figure 6-4 Deactivated-termination Condition Detection Pseudo-code



As stated in Theorem 5.1, if there are no triggering cycles in TG, the rule set will

terminate. Otherwise, AG and DG are considered. Condition 2 in Theorem 5.1,

Deactivated-Termination Condition (DTC), considers the effect of AG and DG. The

pseudo-code shown in Figure 6-4 is used to check if the DTC holds for a triggering cycle.

IfDTC is not satisfied, we will move on to check Condition 3 in Theorem 5.1, the

Contradictory-Condition-Terminate Condition (CCTC), which checks the unsatisfiability

of the conditions of the rules in a triggering cycle. Some heuristics are used in our

implementation. Two conditions are considered to be unsatisfiable when they are on the

same attribute, and it is impossible for both of them to be true.




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs